Engañando al Firewall

Si queremos explicar la ejecución de un ejercicio de emulación de adversarios o emulación de amenazas, podríamos decir que es como un simulacro de incendio en el que se ponen a prueba los procedimientos y protocolos de seguridad de un edificio para garantizar que estén preparados en caso de un incendio real. En el caso de un ejercicio de emulación de adversarios o amenazas, se evalúa la capacidad de una organización para detectar y responder a un ataque informático simulado en un entorno seguro, lo que permite mejorar la seguridad y reducir los riesgos en caso de un ataque real.

El contenido de este artículo tiene como finalidad única la demostración de técnicas y herramientas utilizadas en actividades de emulación de adversarios debidamente autorizadas, y se proporciona únicamente con fines educativos y de divulgación. Se hace expresa mención que cualquier uso indebido, ilegal o no autorizado de las técnicas y herramientas descritas en este artículo queda bajo la responsabilidad exclusiva de su ejecutor.

Se recomienda enfáticamente que estas técnicas y herramientas se utilicen únicamente con fines legales y éticos en cumplimiento de las leyes y regulaciones aplicables. El autor de este artículo no se hace responsable por el uso inadecuado de las técnicas y herramientas descritas.

Como ya lo he dicho en otros artículos, es necesario realizar el ejercicio con todas las defensas habilitadas, y siempre habrá que entender como funcionan estas defensas para buscar opciones de omitir el control, detección o bloqueo.

En este camino he encontrado que en muchos de los casos la entrega de payloads, artefactos que uso en campañas de #awareness o incluso conexiones a un Comando y Control (C2) a través de HTTPS es limitada o bloqueada por los filtros de URL de las organizaciones. Por lo que depende de que tan estricta es la organización respecto a los perfiles de navegación para poder hacer que el usuario acceda a los recursos del adversario.

Cuando entregamos estos recursos a los usuarios, es necesario hacerlo rompiendo los mitos que usan desde hace 20 años, me refiero a:

• Los sitios con dirección IP no son confiables.

Tenemos entonces que registrar un dominio similar al de la organización donde vamos a hacer la emulación de adversarios.

• Los sitios sin el “candadito” o sin https no son confiables.

Tenemos que instalar un certificado válido.

Entonces si tenemos un sitio con un dominio, un certificado y el usuario accede a él por https, es probable que confíe más en nosotros, porque es lo que le han dicho desde hace mucho tiempo, que es así como se ven los sitios legítimos.

Ahora, que hemos ganado la confianza del usuario, se deberá pensar en que mecanismos de detección se podrían haber implementado para evitar que los artefactos sean entregados o las conexiones sean establecidas.

• Antivirus y antimalware en el equipo de seguridad perimetral:

No voy a entrar en detalles, pero existe muchas formas de evitar la detección de un antivirus perimetral, en este artículo explico una, y en este video hago un demo de otra.

• Sandbox:

Tampoco voy a entrar en detalle pero es similar a lo anterior.

• Filtrado URL:

En este punto si me voy a centrar, el filtrado web es básicamente una base de datos donde la mayoría de sitio del internet superficial está categorizado, lo que permite a las organizaciones establecer reglas de navegación en función de estas categorías. Por ejemplo si vemos la imagen a continuación, podemos ver que en la base de datos de la funcionalidad de filtrado de URL del fabricante #checkpoint el sitio www.linkedin.com está categorizado como “Social Networking” entonces si a los usuarios de un perfil determinado de navegación les bloquean el acceso a los sitios de la categoría de “Social Networking” no podrán entrar a este sitio.

En la imagen a continuación se puede ver como categoriza el fabricante #PaloAlto al sitio www.ironcybersec.com.

Entonces si es que nuestro sitio donde vamos a entregar los artefactos, o el subdominio que especificamos en el implante para que este se conecte al Comando Control (C2) no tiene categoría, o está categorizado como riesgoso es muy probable que la conexión sea bloqueada. Por ejemplo el sitio que se puede ver en la imagen a continuación es categorizado como “hacking” y por esto, es muy probable que esté restringido en la mayoría de organizaciones.

Entonces ¿Cómo garantizamos que a nuestro sitio se le asigne una categoría que parezca segura?

Varios de los fabricantes que he podido ver tienen un sitio web para solicitar recategorización, aquí algunos:

• Palo Alto

https://urlfiltering[dot]paloaltonetworks[dot]com/query/

• Checkpoint

https://urlcat[dot]checkpoint[dot]com/urlcat/main.htm

• Fortinet

https://www[dot]fortiguard[dot]com/webfilter

He podido comprobar que una vez que se solicita la recategorización, el análisis para determinar el contenido del sitio y confirmar si la categoría solicitada es la que debería corresponderle al sitio es casi nula o al menos no es efectiva.

Por ejemplo en la siguiente imagen se puede la ver categoría asignada a un dominio que registre en https://www[dot]freenom[dot]com de manera gratuita. De acuerdo a la base de datos de checkpoint en ese momento, el sitio estaba como “no categorizado”.

Haciendo un procedimiento bastante simple, que inicia dando clic en el botón “Request a Category Change”, se puede cambiar de categoría de manera bastante simple, como se ve en la imagen a continuación se muestra un formulario para especificar los datos de la categoría a la que deseamos que nuestro sitio se cambiado.

Una vez que se ha enviado el formulario anterior y han transcurrido aproximadamente 12 horas, se puede ver que nuestro sitio ya pertenece a otra categoría. Ahora el sitio es de “Financial Services”. Esta categoría podría ser conveniente si es que el ejercicio está siendo ejecutado en en una entidad financiera ya que es muy probable que sea una categoría permitida para un gran número de su personal.

¿Porqué digo que el control es insuficiente?

He probado la funcionalidad de recategorización en tres fabricantes, y he podido ver que incluso con sitios que son publicados a través del servicio web del comando control admite el cambio a una categoría segura, lo único que he hecho es agregar un index.html en la raíz del sitio con contenido relativo a la categoría. Por ejemplo el sitio a continuación fue generado por ChatGPT, le pedí código html con contenido de economía y seguros.

Otra opción es clonar un sitio relacionado con la categoría con el uso de wget.

wget https://www.sitio-clonado.com -o index.html

Este procedimiento fue probado en #Paloalto, #Checkpoint y #Fortinet con total éxito.

Conclusión

En ocasiones, es necesario modificar la categoría de un subdominio utilizado para actividades de emulación de adversarios, con el objetivo de evitar su bloqueo por el equipo de seguridad perimetral que controla la navegación en la organización objetivo del ejercicio. Esta modificación permite un acceso continuo y sin restricciones al subdominio, lo que resulta esencial para garantizar la efectividad de su ejecución.

Es importante destacar que esta acción debe llevarse a cabo únicamente en el contexto de actividades legítimas de emulación de adversarios, y siempre en cumplimiento de las leyes y regulaciones aplicables.