Dificultando la vida al Blue Team

Después de leer el artículo de Adam Ziaja sobre técnicas antiforense para engañar al Blue Team, me gustaría que profundicemos un poco en este asunto.

En el pasado ya hablamos largo y tendido sobre los ejercicios de Red Team. Como recordaréis, uno de los enfoques que consideramos más productivos para este tipo de ejercicios es el de preparar al equipo defensor para enfrentarse a las Tácticas, Técnicas y Procedimientos (TTP) utilizados por los adversarios reales a lo largo de la red. Es importante no perder en ningún momento la función didáctica, debiendo tener en cuenta las capacidades de dicho equipo, para así poder aumentar o reducir el nivel de dificultad del ataque. De este modo, el Blue Team aprenderá en vez de sentirse completamente arrollado... 

En primer lugar, Adam nos propone ocultar nuestros payloads del equipo defensor a través de la cabecera User-Agent. Como muchos sabréis, la cabecera user-agent es una cadena de texto enviada por casi cualquier cliente web con el objetivo de identificar el software que realiza la petición. Por ejemplo:

Existen páginas que nos permiten conocer el user-agent de nuestro navegador, y nos ofrecen el tipo de información que se puede inferir de dicha cadena de texto. Si cogemos alguna de las de arriba de ejemplo, podríamos ver cómo detecta el uso de Firefox 47 en Windows 7 de 64 bits.

Aunque no sea motivo de discusión en este post, os imaginaréis que a veces esta información es más que suficiente para meter a la víctima un exploit entre pecho y espalda. Sin embargo, en este caso lo que se propone es utilizar esta información para proteger nuestros payloads.

Si levantamos tcpdump en un servidor de pruebas, y vemos lo que sucede al descargar el payload desde powershell, obtenemos una petición de este tipo:

Y sin embargo, si lo hacemos desde un navegador normal la petición incluiría el user-agent.

En el caso de Adam, el filtrado lo hace a través de código PHP, aunque en alguna de nuestras charlas hemos comentado que una de las formas que más nos gusta de hacer esto mismo es a través del uso de Apache + mod_rewrite, como recomienda bluescreenofjeff.

En el ejemplo de arriba, siempre que el user-agent contenga las palabras Firefox, Chrome, wget, curl, HTTrack o simplemente esté vacío, se redirige automáticamente al usuario a Google sin pasar por la página real. Esta sería una aproximación, por tanto, si nuestro objetivo a atacar fuesen los usuarios de Internet Explorer.

En ocasiones lo que buscaremos es reenviar al equipo defensor a una página de error, para que dejen de investigar la URL encontrada. Sin embargo, y como bien propone Adam, puede ser buena idea redirigir este tipo de peticiones a información falsa. Por ejemplo, un script no malicioso, una página benigna, u otro tipo de contenido que pueda engañar a los que investiguen el incidente.

El siguiente mecanismo para proteger nuestra infraestructura de ataque frente a los posibles investigadores es el uso de listas blancas y/o negras de acceso. Si conocemos el direccionamiento de acceso a Internet de la compañía, podremos hacer que únicamente desde ese rango se pueda acceder a los payloads que tenemos preparados. Si el cliente cuenta con un SOC externalizado que tiene su propio direccionamiento, no podrán investigar fácilmente el ataque.

A través de esta medida, además, conseguimos un segundo cometido relacionado con la protección legal, y es que evitaremos que por error podamos llegar a lanzar ataques fuera del scope definido. Existen otros mecanismos para evitar escenarios como este, como por ejemplo, validar el dominio al que está unido el equipo antes de continuar una infección, pero el bloqueo por rangos de direcciones IP también es una aproximación a tener en cuenta.

Adam también nos propone analizar los crawlers de los diferentes fabricantes antivirus, para descubrir los ASN que utilizan, como es el caso de ESET (AS50881) o VirusTotal (AS15169). En los casos en los que el whitelisting no se pueda aplicar, puede ser una forma de dificultar la detección. Podemos, incluso, utilizar la base de datos de GeoIP para restringir el acceso por países concretos.

De nuevo, la aproximación de Bluescreenofjeff es la que habitualmente utilizamos, creando reglas de filtrado IP a través de Apache + mod_rewrite.

En este caso, cualquier usuario que conecte desde los rangos 100.0.0.0/24 y 100.0.1.0/24 podrá alcanzar el servidor de ataque, mientras que cualquier otro usuario será redirigido a companydomain.com/404.html

Por otro lado, si lo que queremos es aplicar listas negras podremos utilizar esa misma configuración, pero intercambiando las dos últimas líneas. De ese modo, la configuración se leería como "Si la petición llega desde estos rangos, reenvía la petición a companydomain.comm/404.html, si no, deja que lleguen al servidor de ataque."

Finalmente, queda otra opción interesante a tener en cuenta que nos propone Jeff Dimmock (@bluscreenofjeff), y es el bloqueo por horarios. Por ejemplo, podríamos permitir el acceso únicamente dentro de una jornada laboral concreta:

 

En este caso, sólo se podrá acceder desde las 06:00 hasta las 20:00, siempre siguiendo el horario local del servidor. En este caso, no sólo podremos controlar más los accesos, sino que se podrán dificultar los accesos a los equipos de respuesta a incidentes internacionales que estén en otras franjas horarias.

Para los bloqueos temporales también existe la variable %{TIME_WDAY} para bloquear por día de la semana, que acepta los valores 0 a 6 para representar del domingo al sábado

Ya sabéis, a proteger vuestras campañas, ¡y a disfrutar! ;-)