Wiki para recopilar recursos de endurecimiento de infraestructura de Red Team
Esta wiki está pensada para proporcionar un recurso para configurar una infraestructura de Red Team resiliente. Fue creada para complementar la charla de Steve Borosh (@424f424f) y Jeff Dimmock (@bluscreenofjeff) en BSides NoVa 2017, "Doomsday Preppers: Fortifying Your Red Team Infrastructure" (diapositivas)
Si tienes una adición que te gustaría hacer, por favor envía un Pull Request o reporta un problema en el repositorio.
GRACIAS a todos los autores del contenido referenciado en esta wiki y a todos los que contribuyeron!
Al diseñar una infraestructura de Red Team que necesite resistir una respuesta activa o durar para un compromiso a largo plazo (semanas, meses, años), es importante segregar cada activo según su función. Esto proporciona resiliencia y agilidad contra el Blue Team cuando los activos de la campaña comienzan a ser detectados. Por ejemplo, si se identifica el correo de phishing de una evaluación, el Red Team solo necesitaría crear un nuevo servidor SMTP y un servidor de alojamiento de payloads, en lugar de toda una configuración de servidor de equipo.
Considera segregar estas funciones en diferentes activos:
Cada una de estas funciones probablemente será necesaria para cada campaña de ingeniería social. Dado que la respuesta activa a incidentes es típica en una evaluación de Red Team, se debe implementar un nuevo conjunto de infraestructura para cada campaña.
Para aumentar la resiliencia y el ocultamiento, cada activo de back-end (es decir, servidor de equipo) debe tener un redirector colocado delante de él. El objetivo es tener siempre un host entre nuestro objetivo y nuestros servidores de back-end. Configurar la infraestructura de esta manera hace que rotar infraestructura fresca sea mucho más rápido y fácil: no es necesario levantar un nuevo servidor de equipo, migrar sesiones y reconectar activos no quemados en el back-end.
Tipos comunes de redirectores:
Cada tipo de redirector tiene múltiples opciones de implementación que se adaptan mejor a diferentes escenarios. Estas opciones se discuten en detalle en la sección de Redirectores de la wiki. Los redirectores pueden ser hosts VPS, servidores dedicados o incluso aplicaciones que se ejecutan en una instancia de Platform-as-a-Service.
Aquí hay un diseño de ejemplo, teniendo en cuenta la segregación funcional y el uso de redirectores:
A Vision for Distributed Red Team Operations - Raphael Mudge (@armitagehacker)
Infrastructure for Ongoing Red Team Operations - Raphael Mudge
Advanced Threat Tactics (2 of 9): Infrastructure - Raphael Mudge
Cloud-based Redirectors for Distributed Hacking - Raphael Mudge
How to Build a C2 Infrastructure with Digital Ocean – Part 1 - Lee Kagan (@invokethreatguy)
Automated Red Team Infrastructure Deployment with Terraform - Part 1 - Rasta Mouse (@_RastaMouse)
La reputación percibida de un dominio variará enormemente dependiendo de los productos que esté utilizando tu objetivo, así como de su configuración. Como tal, elegir un dominio que funcione en tu objetivo no es una ciencia exacta. La recopilación de inteligencia de fuentes abiertas (OSINT) será crítica para ayudar a hacer una mejor suposición sobre el estado de los controles y contra qué recursos verificar los dominios. Afortunadamente, los anunciantes en línea enfrentan los mismos problemas y han creado algunas soluciones que podemos aprovechar.
expireddomains.net es un motor de búsqueda para dominios recientemente expirados o eliminados. Proporciona búsqueda y filtrado avanzado, como la antigüedad de la expiración, el número de backlinks, el número de instantáneas de Archive.org y la puntuación de SimilarWeb. Usando el sitio, podemos registrar dominios previamente utilizados, que vendrán con antigüedad de dominio, que se parezcan a nuestro objetivo, que se parezcan a nuestra suplantación, o simplemente que sea probable que pasen desapercibidos en la red de nuestro objetivo.
Al elegir un dominio para C2 o exfiltración de datos, considera elegir un dominio categorizado como Finanzas o Salud. Muchas organizaciones no realizarán SSL middling en esas categorías debido a la posibilidad de problemas legales o de sensibilidad de datos. También es importante asegurarse de que tu dominio elegido no esté asociado con campañas anteriores de malware o phishing.
La herramienta CatMyFish de Charles Hamilton(@MrUn1k0d3r) automatiza búsquedas y verificación de categorización web con expireddomains.net y BlueCoat. Se puede modificar para aplicar más filtros a las búsquedas o incluso realizar un monitoreo a largo plazo de los activos que registres.
Otra herramienta, DomainHunter de Joe Vest (@joevest) y Andrew Chiles (@andrewchiles), devuelve la categorización de BlueCoat/WebPulse, IBM X-Force y Cisco Talos, la antigüedad del dominio, TLDs alternativos disponibles, enlaces de Archive.org y un informe HTML. Además, realiza comprobaciones de uso en campañas conocidas de malware y phishing utilizando Malwaredomains.com y MXToolBox. Esta herramienta también incluye soporte OCR para evitar los captchas de BlueCoat/WebPulse. Consulta la publicación del blog sobre el lanzamiento inicial de la herramienta para más detalles.
Otra herramienta más, AIRMASTER de Max Harley (@Max_68) utiliza expireddomains.net y Bluecoat para encontrar dominios categorizados. Esta herramienta utiliza OCR para evitar el captcha de BlueCoat, aumentando la velocidad de búsqueda.
Si un dominio previamente registrado no está disponible o prefieres un dominio auto-registrado, es posible categorizar dominios tú mismo. Usando los enlaces directos a continuación o una herramienta como Chameleon de Dominic Chell (@domchell). La mayoría de los productos de categorización pasarán por alto las redirecciones o el contenido clonado al determinar la categorización del dominio. Para más información sobre el uso de Chameleon, consulta la publicación de Dominic Categorisation is not a security boundary.
Finalmente, asegúrate de que tu configuración de DNS se haya propagado correctamente.
Las palabras fácil y phishing nunca parecen ir realmente juntas. Configurar una infraestructura de phishing adecuada puede ser un verdadero dolor. El siguiente tutorial te proporcionará el conocimiento y las herramientas para configurar rápidamente un servidor de phishing que pase "la mayoría" de los filtros de spam hasta la fecha y te proporcione una interfaz RoundCube para una experiencia de phishing fácil, incluyendo comunicaciones bidireccionales con tu objetivo. Hay muchas configuraciones y publicaciones sobre phishing. Este es solo un método.
Una vez que tengas un dominio que pase las verificaciones adecuadas enumeradas en la sección anterior y tengas tu servidor de phishing en funcionamiento, necesitarás crear un par de registros "A" para tu dominio como se muestra.
A continuación, conéctate por ssh a tu servidor de phishing y asegúrate de tener un nombre de host FQDN adecuado en tu /etc/hosts. Ejemplo "127.0.0.1 email.yourphishingserver.com email localhost"
Ahora, vas a instalar el front-end web para hacer phishing en unos pocos pasos sencillos. Comienza descargando la última versión "BETA" de iRedMail en tu servidor de phishing. La forma fácil es hacer clic derecho en el botón de descarga, copiar la dirección del enlace, usar wget para descargar directamente en tu servidor de phishing. A continuación, descomprímelo "tar -xvf iRedMail-0.9.8-beta2.tar.bz2". Navega a la carpeta descomprimida y haz ejecutable el script iRedMail.sh (chmod +x iRedMail.sh). Ejecuta el script como root, sigue las indicaciones, y necesitarás reiniciar para terminar todo.
Querrás asegurarte de tener todos los registros DNS adecuados apuntando a tu servidor de correo. (https://docs.iredmail.org/setup.dns.html). Para DKIM, el nuevo comando debería ser "amavisd-new showkeys" para listar tu clave DKIM.
Para DMARC podemos usar (https://www.unlocktheinbox.com/dmarcwizard/) para generar nuestra entrada dmarc.
Ahora, crea un usuario para hacer phishing.
Inicia sesión en la interfaz RoundCube con tu nuevo usuario y ¡haz phishing de manera responsable!
Cobalt Strike proporciona funcionalidad de spearphishing personalizable para soportar phishing por correo electrónico en pruebas de penetración o Red Team. Soporta plantillas en formato HTML y/o texto plano, adjuntos, una dirección de rebote, incrustación de URL, uso de servidores SMTP remotos y retrasos de envío por mensaje. Otra característica interesante es la capacidad de agregar un token único a la URL incrustada de cada usuario para el seguimiento de clics.
Para información más detallada, consulta estos recursos:
Para ejercicios de Red Team y phishing donde la confianza del cliente y la OPSEC importan, mantener los datos de clientes capturados y la infraestructura principal en los propios servidores del cliente (on-premises) proporciona ventajas significativas sobre las soluciones solo en la nube. Este enfoque utiliza activos en la nube solo para redirectores y frentes delgados mientras mantiene las operaciones sensibles internamente.
Una configuración robusta de Evilginx on-premises típicamente consiste en:
El filtrado por cookies reduce los hits de bots y el escaneo automatizado al requerir una cookie específica para acceder al portal de phishing:``` (http.host eq "portal.example.com") and (not http.cookie contains "session_token=abc123def456") and not (http.host eq "landing.example.com" and http.request.uri.path eq "/favicon.ico")
Esta regla redirige las solicitudes al dominio del portal que no contienen la cookie requerida, mientras exime las solicitudes de favicon para evitar bucles de redirección.
### Configuración de ejemplo de Caddy```caddyfile
# Redirect direct IP access to prevent fingerprinting
1.2.3.4 {
redir https://legitimate-site.com{uri} permanent
}
landing.example.com {
log {
output file /var/log/caddy/landing_access.log
format console
}
tls internal
encode gzip
reverse_proxy http://127.0.0.1:8000
}
portal.example.com {
log {
output file /var/log/caddy/portal_access.log
format console
}
tls internal
encode gzip
reverse_proxy https://evilginx:443 {
transport http {
versions 1.1
tls_insecure_skip_verify
tls_server_name portal.example.com
}
header_up Host portal.example.com
header_up X-Forwarded-Proto https
}
}
Ejecuta Evilginx en el nodo interno con las banderas adecuadas:```bash ./evilginx2 -p ./phishlets -t ./redirectors -developer -debug
**Importante:** Evilginx solo debe ser accesible desde la red privada; nunca publiques su IP en el DNS público.
### Lista de verificación de OPSEC y endurecimiento
1. **Nunca expongas las IP de Evilginx en el DNS público** - Usa solo redes privadas
2. **Mantén los datos sensibles únicamente en los servidores del cliente** - Los redirectors no deben almacenar credenciales capturadas
3. **Endurece los redirectors** - Rota los dominios, usa TTL cortos, despliega múltiples redirectors efímeros
4. **Implementa reglas de WAF/firewall** - Usa comprobaciones de cookies, listas de permitidos por IP o validación de UA
5. **Separa el registro y la retención** - Mantén los registros de acceso en Caddy y los registros de captura en el host de Evilginx
6. **Evita huellas digitales** - No uses patrones predecibles ni huellas TLS idénticas
Este enfoque híbrido (redirector público/captura privada) proporciona la resiliencia del cloud fronting mientras mantiene las ventajas de seguridad y legales de mantener las operaciones sensibles en las instalaciones.
## Frameworks de phishing
Más allá de montar tu propio sistema de phishing o usar un framework de pentest o red teaming, como Cobalt Strike, existen numerosas herramientas y frameworks dedicados al phishing por correo electrónico. Aunque esta wiki no entrará en detalle sobre cada framework, a continuación se recopilan algunos recursos para cada uno:
### Gophish
* [Sitio oficial de Gophish](https://getgophish.com/)
* [Repositorio de GitHub de Gophish](https://github.com/gophish/gophish)
* [Guía de usuario de Gophish](https://www.gitbook.com/book/gophish/user-guide/details)
### Phishing Frenzy
* [Sitio oficial de Phishing Frenzy](https://www.phishingfrenzy.com/)
* [Repositorio de GitHub de Phishing Frenzy](https://github.com/pentestgeek/phishing-frenzy)
* [Presentando Phishing Frenzy - Brandon McCann (@zeknox)](https://www.pentestgeek.com/phishing/introducing-phishing-frenzy)
### The Social-Engineer Toolkit
* [Repositorio de GitHub de The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit)
* [Manual de usuario de The Social-Engineer Toolkit](https://github.com/trustedsec/social-engineer-toolkit/raw/master/readme/User_Manual.pdf)
### FiercePhish (anteriormente FirePhish)
* [Repositorio de GitHub de FiercePhish](https://github.com/Raikia/FiercePhish)
* [Wiki de FiercePhish](https://github.com/Raikia/FiercePhish/wiki)
# Redirectors
## SMTP
"Redirector" puede no ser la mejor palabra para describir lo que vamos a lograr, pero el objetivo es el mismo que con nuestra otra redirección. Queremos eliminar cualquier rastro de nuestro origen de phishing de las cabeceras finales del correo y proporcionar un buffer entre la víctima y nuestro servidor backend. Idealmente, el redirector SMTP será rápido de configurar y fácil de retirar.
Hay dos acciones clave que queremos configurar para que un redirector SMTP realice:
### Sendmail
#### Eliminar cabeceras de servidores anteriores
Añade la siguiente línea al final de `/etc/mail/sendmail.mc`:```bash
define(`confRECEIVED_HEADER',`by $j ($v/$Z)$?r with $r$. id $i; $b')dnl
Añade al final de /etc/mail/access:```bash
IP-to-Team-Server TAB RELAY
Phish-Domain TAB RELAY
[Removing Sender’s IP Address From Email’s Received From Header](https://www.devside.net/wamp-server/removing-senders-ip-address-from-emails-received-from-header)
[Removing Headers from Postfix setup](https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/)
#### Configurar una dirección catch-all
Esto retransmitirá cualquier correo electrónico recibido en *@phishdomain.com a una dirección de correo electrónico elegida. Esto es muy útil para recibir cualquier respuesta o rebote de un correo de phishing.```bash
echo PHISH-DOMAIN >> /etc/mail/local-host-names
Añade la siguiente línea justo antes de //Mailer Definitions// (hacia el final) de /etc/mail/sendmail.mc:```bash
FEATURE(virtusertable', hash -o /etc/mail/virtusertable.db')dnl
Añade la siguiente línea al final de `/etc/mail/virtusertable`:```bash
@phishdomain.com external-relay-address
Nota: Los dos campos deben estar separados por tabulaciones
Postfix ofrece una alternativa más sencilla a sendmail con mayor compatibilidad. Postfix también ofrece soporte completo de IMAP con Dovecot. Esto permite a los testers corresponder en tiempo real con los objetivos de phishing que responden al mensaje original, en lugar de depender de la dirección catch-all y tener que crear un nuevo mensaje usando tu herramienta de phishing.
Una guía completa para configurar un servidor de correo Postfix para phishing está disponible en la publicación de Julian Catrambone (@n0pe_sled) Mail Servers Made Easy.
Nota: Al usar redirectores C2, se debe configurar un listener externo en tu framework de post-explotación para enviar el tráfico de staging a través del dominio del redireccionador. Esto hará que el host comprometido realice el staging a través del redireccionador, igual que el tráfico C2.
socat se puede usar para redirigir paquetes DNS entrantes en el puerto 53 a nuestro servidor de equipo. Aunque este método funciona, algunos usuarios han reportado problemas de staging con Cobalt Strike y/o problemas de latencia al usar este método. Editado el 21/04/2017: El siguiente comando socat parece funcionar bien gracias a las pruebas de @xorrior:``` socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto::53; echo -ne
[Redirecting Cobalt Strike DNS Beacons - Steve Borosh](https://medium.com/rvrsh3ll/redirecting-cobalt-strike-dns-beacons-e3dcdb5a8b9b)
### iptables para DNS
Se ha comprobado que las reglas de reenvío DNS de iptables funcionan bien con Cobalt Strike. No parece haber ninguno de los problemas que socat tiene al manejar este tipo de tráfico.
A continuación se muestra un ejemplo de conjunto de reglas de redirección DNS.```bash
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <IP-GOES-HERE>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1
También, cambia la política de la cadena "FORWARD" a "ACCEPT"
Algunos pueden tener el requisito o la necesidad de alojar un servidor c2 en una red interna. Usando una combinación de IPTABLES, SOCAT y túneles SSH inversos, ciertamente podemos lograr esto de la siguiente manera.
En este escenario, tenemos nuestro redirector volátil usando IPTables para reenviar todo el tráfico DNS usando la regla de ejemplo descrita anteriormente en esta sección. A continuación, creamos un túnel SSH de reenvío de puerto inverso desde nuestro servidor c2 interno hacia nuestro redirector principal. Esto reenviará cualquier tráfico que el redirector principal reciba en el puerto 6667 al servidor c2 interno en el puerto 6667. Ahora, iniciamos socat en nuestro servidor de equipo para bifurcar cualquier tráfico TCP entrante en el puerto 6667 hacia el puerto UDP 53, que es donde nuestro c2 de DNS necesita escuchar. Finalmente, configuramos de manera similar una instancia de socat en el redirector principal para redirigir cualquier tráfico UDP entrante del puerto 53 hacia nuestro túnel SSH en el puerto 6667.
Nota: Al usar redirectores C2, se debe configurar un listener externo en su framework de post-explotación para enviar el tráfico de staging a través del dominio del redirector. Esto hará que el host comprometido realice el staging a través del redirector, al igual que el propio tráfico C2.
socat proporciona una redirección de 'tubería tonta'. Cualquier solicitud que socat reciba en la interfaz/puerto de origen especificado se redirige a la IP/puerto de destino. No hay filtrado ni redirección condicional. Apache mod_rewrite, por otro lado, proporciona una serie de métodos para fortalecer su phishing y aumentar la resiliencia de su infraestructura de pruebas. mod_rewrite tiene la capacidad de realizar redirección condicional basada en atributos de la solicitud, como URI, user agent, cadena de consulta, sistema operativo e IP. Apache mod_rewrite utiliza archivos htaccess para configurar conjuntos de reglas sobre cómo Apache debe manejar cada solicitud entrante. Usando estas reglas, podría, por ejemplo, redirigir solicitudes a su servidor con el user agent predeterminado de wget a una página legítima en el sitio web de su objetivo.
En resumen, si su redirector necesita realizar redirección condicional o filtrado avanzado, use Apache mod_rewrite. De lo contrario, la redirección con socat y el filtrado opcional con iptables serán suficientes.
socat se puede usar para redirigir cualquier paquete TCP entrante en un puerto especificado a nuestro servidor de equipo.
La sintaxis básica para redirigir el puerto TCP 80 en localhost al puerto 80 en otro host es:``` socat TCP4-LISTEN:80,fork TCP4::80
Si tu redireccionador está configurado con más de una interfaz de red, socat puede vincularse a una interfaz específica, mediante su dirección IP, con la siguiente sintaxis:```
socat TCP4-LISTEN:80,bind=10.0.0.2,fork TCP4:1.2.3.4:80
En este ejemplo, 10.0.0.2 es una de las direcciones IP locales del redirector y 1.2.3.4 es la dirección IP del servidor de equipo remoto.
Además de socat, iptables puede realizar redirección de 'tubería tonta' mediante NAT. Para reenviar el puerto local 80 del redirector a un host remoto, use la siguiente sintaxis:``` iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination :80 iptables -t nat -A POSTROUTING -j MASQUERADE iptables -I FORWARD -j ACCEPT iptables -P FORWARD ACCEPT sysctl net.ipv4.ip_forward=1
### SSH para HTTP
Anteriormente hemos cubierto el uso de SSH para túneles DNS. SSH funciona como un medio sólido y robusto para atravesar NAT y obtener una vía para que el implante se conecte a un redirector y hacia tu entorno de servidor. Antes de configurar un redirector SSH, debes añadir las siguientes líneas a `/etc/ssh/sshd_config`:```text
# Allow the SSH client to specify which hosts may connect
GatewayPorts yes
# Allow both local and remote port forwards
AllowTcpForwarding yes
Para reenviar el puerto local 80 del redirector a tu servidor interno, usa la siguiente sintaxis en el servidor interno:``` tmux new -S redir80 ssh -R *:80:localhost:80 Ctrl+B, D
También puedes reenviar más de un puerto, por ejemplo si quieres que 443 y 80 estén abiertos a la vez:```
tmux new -S redir80443
ssh <redirector> -R *:80:localhost:80 -R *:443:localhost:443
Ctrl+B, D
Al servir cargas útiles y recursos web, queremos minimizar la capacidad de los respondedores de incidentes para revisar archivos y aumentar las posibilidades de ejecutar con éxito la carga útil, ya sea para establecer C2 o recopilar inteligencia.
Uso y ejemplos de Apache Mod_Rewrite por Jeff Dimmock:
Otros usos y ejemplos de Apache mod_rewrite:
Para configurar automáticamente Apache Mod_Rewrite en un servidor redirector, consulta la publicación del blog de Julain Catrambone (@n0pe_sled) Configuración automática de Mod_Rewrite y la herramienta adjunta.
La intención detrás de redirigir el tráfico C2 es doble: ocultar el servidor del equipo backend y parecer un sitio web legítimo si un respondedor de incidentes lo navega. Mediante el uso de Apache mod_rewrite y perfiles C2 personalizados u otros proxies (como con Flask), podemos filtrar de manera confiable el tráfico C2 real del tráfico de investigación.
Basándonos en "Redirección C2" anterior, otro método es hacer que tu servidor redirector use el Motor de Proxy SSL de Apache para aceptar solicitudes SSL entrantes y proxyarlas a solicitudes hacia un listener HTTPS inverso. El cifrado se usa en todas las etapas, y puedes rotar los certificados SSL en tu redirector según sea necesario.
Para que esto funcione con tus reglas mod_rewrite, debes colocar tus reglas en "/etc/apache2/sites-available/000-default-le-ssl.conf" asumiendo que has usado LetsEncrypt (también conocido como CertBot) para instalar tu certificado. Además, para habilitar el motor ProxyPass SSL, necesitarás las siguientes líneas en ese mismo archivo de configuración:```bash
SSLProxyEngine On
ProxyPass / https://DESTINATION_C2_URL:443/ ProxyPassReverse / https://DESTINATION_C2_URL:443/
SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off
### Otros recursos de Apache mod_rewrite
* [Automatización de perfiles Apache mod_rewrite y Cobalt Strike](https://posts.specterops.io/automating-apache-mod-rewrite-and-cobalt-strike-malleable-c2-profiles-d45266ca642)
* [mod-rewrite-cheatsheet.com](http://mod-rewrite-cheatsheet.com/)
* [Documentación oficial de Apache 2.4 mod_rewrite](http://httpd.apache.org/docs/current/rewrite/)
* [Introducción a Apache mod_rewrite](https://httpd.apache.org/docs/2.4/en/rewrite/intro.html)
* [Guía detallada de mod_rewrite para Apache](http://code.tutsplus.com/tutorials/an-in-depth-guide-to-mod_rewrite-for-apache--net-6708)
* [Comprobador de sintaxis de Mod_Rewrite/.htaccess](http://www.htaccesscheck.com/)
# Modificación del tráfico C2
## Cobalt Strike
Cobalt Strike modifica su tráfico con perfiles Malleable C2. Los perfiles ofrecen opciones altamente personalizables para modificar cómo se verá el tráfico C2 de tu servidor en la red. Los perfiles Malleable C2 se pueden usar para fortalecer la evasión en la respuesta a incidentes, imitar a adversarios conocidos o hacerse pasar por aplicaciones internas legítimas utilizadas por el objetivo.
* [Perfiles oficiales Malleable C2 - GitHub](https://github.com/rsmudge/Malleable-C2-Profiles)
* [Documentación de Malleable Command and Control - cobaltstrike.com](https://www.cobaltstrike.com/help-malleable-c2)
* [Cobalt Strike 2.0 - Malleable Command and Control - Raphael Mudge](http://blog.cobaltstrike.com/2014/07/16/malleable-command-and-control/)
* [Cobalt Strike 3.6 - Un camino para la escalada de privilegios - Raphael Mudge](http://blog.cobaltstrike.com/2016/12/08/cobalt-strike-3-6-a-path-for-privilege-escalation/)
* [Un mundo valiente: Malleable C2 - Will Schroeder (@harmj0y)](http://www.harmj0y.net/blog/redteaming/a-brave-new-world-malleable-c2/)
* [Cómo escribir perfiles Malleable C2 para Cobalt Strike - Jeff Dimmock](https://bluescreenofjeff.com/2017-01-24-how-to-write-malleable-c2-profiles-for-cobalt-strike/)
* [Evasión en memoria (serie de videos) - Raphael Mudge](https://www.youtube.com/watch?v=lz2ARbZ_5tE&list=PL9HO6M_MU2nc5Q31qd2CwpZ8J4KFMhgnK)
A medida que comiences a crear o modificar perfiles Malleable C2, es importante tener en cuenta los límites de tamaño de datos para la colocación de la información de Beacon. Por ejemplo, configurar el perfil para enviar grandes cantidades de datos en un parámetro de URL requerirá muchas solicitudes. Para obtener más información sobre esto, consulta la publicación del blog de Raphael Mudge [Cuidado con las descargas lentas](https://blog.cobaltstrike.com/2018/03/09/beware-of-slow-downloads/).
Si encuentras problemas con tu perfil Malleable C2 y notas que la consola del teamserver muestra errores, consulta la publicación del blog de Raphael Mudge [Promesas rotas y perfiles Malleable C2](https://blog.cobaltstrike.com/2018/06/04/broken-promises-and-malleable-c2-profiles/) para obtener consejos de solución de problemas.
## Empire
Empire utiliza perfiles de comunicación, que ofrecen opciones de personalización para los URI de solicitudes GET, el user agent y los encabezados. El perfil consiste en cada elemento, separado por el carácter de tubería, y se configura con la opción `set DefaultProfile` en el menú contextual de `listeners`.
Aquí hay un perfil predeterminado de muestra:```bash
"/CWoNaJLBo/VTNeWw11212/|Mozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.1)|Accept:image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*|Accept-Language:en-en"
Alternativamente, el valor de DefaultProfile se puede establecer modificando el archivo /setup/setup_database.py antes de la configuración inicial de Empire. Esto cambiará el Perfil de Comunicación predeterminado que Empire utilizará.
Además del Perfil de Comunicación, considere personalizar las URI de staging del servidor de Empire, los encabezados del servidor y el contenido predeterminado de la página web siguiendo los pasos presentados en la publicación de Joe Vest (@joevest) Empire - Modifying Server C2 Indicators.
Aprovechar servicios web legítimos y de confianza para C2 puede proporcionar una ventaja valiosa sobre el uso de dominios e infraestructura que usted mismo ha configurado. El tiempo y la complejidad de configuración varían según la técnica y el servicio utilizado. Un ejemplo popular de aprovechamiento de servicios de terceros para la redirección C2 es el Domain Fronting.
El Domain Fronting es una técnica utilizada por servicios y aplicaciones de evasión de censura para enrutar el tráfico a través de dominios legítimos y altamente confiables. Los servicios populares que admiten Domain Fronting incluyen Google App Engine, Amazon CloudFront y Microsoft Azure. Es importante tener en cuenta que muchos proveedores, como Google y Amazon, han implementado mitigaciones contra el Domain Fronting, por lo que algunos recursos enlazados o información proporcionada en esta wiki pueden estar desactualizados para cuando intente usarlos.
En pocas palabras, el tráfico utiliza el nombre DNS y SNI del proveedor de servicios confiable; en el ejemplo a continuación se usa Google. Cuando el tráfico es recibido por el Edge Server (por ejemplo, ubicado en gmail.com), el paquete se reenvía al Origin Server (por ejemplo, phish.appspot.com) especificado en el encabezado Host del paquete. Dependiendo del proveedor de servicios, el Origin Server reenviará el tráfico directamente a un dominio especificado, que apuntaremos a nuestro team server, o se requerirá una aplicación proxy para realizar el salto final de reenvío.
Para obtener información más detallada sobre cómo funciona el Domain Fronting, consulte el documento técnico Blocking-resistant communication through domain fronting y la documentación de meek del Proyecto TOR.
Además de los dominios frontables estándar, como cualquier dominio de google.com, es posible aprovechar otros dominios legítimos para el fronting.
Para obtener más información sobre la búsqueda de dominios frontables, consulte:
Muchos proveedores de PaaS y SaaS proporcionan un subdominio o URL estático para usar con una instancia aprovisionada. Si el dominio asociado es generalmente altamente confiable, las instancias podrían proporcionar confianza adicional a su infraestructura C2 en comparación con un dominio comprado y un VPS.
Para configurar la redirección, deberá identificar un servicio que emita un subdominio o URL estático como parte de una instancia. Luego, la instancia deberá configurarse con redirección basada en red o aplicación. La instancia actuará como un proxy, similar a los otros redirectores discutidos en esta wiki.
Otra técnica interesante que merece más investigación es el uso de buckets de Amazon S3 excesivamente permisivos para C2. Consulte la publicación S3 Buckets for Good and Evil de Andrew Luke (@Sw4mp_f0x) para obtener más detalles sobre cómo se podrían usar los buckets de S3 para C2. Esta técnica podría combinarse con las capacidades C2 de terceros de Empire para usar los buckets de S3 legítimos del objetivo en su contra.
Para otro ejemplo de uso de PaaS para C2, consulte Databases and Clouds: SQL Server as a C2 de Scott Sutherland (@_nullbind).
Otros servicios de terceros se han utilizado en la naturaleza para C2 en el pasado. Aprovechar sitios web de terceros que permiten la publicación o modificación rápida de contenido generado por el usuario puede ayudarlo a evadir los controles basados en reputación, especialmente si el sitio de terceros es generalmente confiable.
Consulte estos recursos para otras opciones de C2 de terceros:
La infraestructura de ataque a menudo es fácil de identificar, pareciendo un cascarón de un servidor legítimo. Necesitaremos tomar medidas adicionales con nuestra infraestructura para aumentar la probabilidad de mezclarnos con servidores reales, ya sea entre la organización objetivo o los servicios que el objetivo podría usar de manera concebible.
Los redirectores pueden ayudar a mezclarse redirigiendo URI inválidas, haciendo expirar enlaces de payloads de phishing, o bloqueando técnicas comunes de respondedores de incidentes; sin embargo, también se debe prestar atención al host subyacente y sus indicadores.
Por ejemplo, en la publicación Fall of an Empire, John Menerick (@Lord_SQL) cubre métodos para detectar servidores de Empire en internet.
Para combatir estos y otros indicadores similares, es una buena idea modificar los patrones de tráfico C2, modificar las páginas de aterrizaje del servidor, restringir los puertos abiertos y modificar los encabezados de respuesta predeterminados.
Para obtener más detalles sobre cómo hacer esto y otras tácticas para múltiples frameworks de ataque, consulte estas publicaciones:
La infraestructura de ataque puede ser atacada igual que cualquier otro host conectado a internet, y debe considerarse ALTAMENTE sensible debido a los datos en uso y las conexiones a los entornos objetivo.
En 2016, se divulgaron vulnerabilidades de ejecución remota de código en las herramientas de ataque más comunes:
iptables debe usarse para filtrar tráfico no deseado y restringir el tráfico entre los elementos de infraestructura requeridos. Por ejemplo, si un team server de Cobalt Strike solo servirá activos a un redirector Apache, las reglas de iptables solo deben permitir el puerto 80 desde la IP de origen del redirector. Esto es especialmente importante para cualquier interfaz de administración, como SSH o el puerto predeterminado 50050 de Cobalt Strike. También considere bloquear IPs de países que no son el objetivo. Como alternativa, considere usar los firewalls de hipervisor proporcionados por sus proveedores de VPS. Por ejemplo, Digital Ocean ofrece Cloud Firewalls que pueden proteger uno o múltiples droplets.
chattr se puede usar en team servers para evitar que los directorios cron sean modificados. Usando chattr, puede restringir a cualquier usuario, incluido root, de modificar un archivo hasta que se elimine el atributo chattr.
SSH debe limitarse solo a autenticación de clave pública y configurarse para usar usuarios con derechos limitados para el inicio de sesión inicial. Para mayor seguridad, considere agregar autenticación multifactor a SSH.
¡Actualización! Ninguna lista de aseguramiento está completa sin un recordatorio de actualizar regularmente los sistemas y aplicar hot-fixes según sea necesario para remediar vulnerabilidades.
Por supuesto, esta lista no es exhaustiva de lo que puede hacer para asegurar un team server. Siga las prácticas comunes de hardening en toda la infraestructura:
Hay una serie de recursos disponibles en línea que discuten la configuración y el diseño seguros de infraestructuras. No todas las consideraciones de diseño serán apropiadas para cada infraestructura de ataque, pero es útil saber qué opciones están disponibles y qué están haciendo otros testers.
Aquí hay algunos de esos recursos:
Los temas cubiertos en esta wiki fortalecen las infraestructuras de ataque, pero generalmente requieren una buena cantidad de tiempo para diseñar e implementar. La automatización se puede usar para reducir en gran medida los tiempos de implementación, permitiéndole implementar configuraciones más complejas en menos tiempo.
Consulte estos recursos sobre automatización de infraestructura de ataque:
Documente todo - Ejecutar una infraestructura compleja de Red Team significa muchas partes móviles. Asegúrese de documentar la función de cada activo y a dónde se envía su tráfico.
Divida los activos entre diferentes proveedores de servicios y regiones - Los activos de infraestructura deben distribuirse entre múltiples proveedores de servicios y regiones geográficas. Los miembros del Blue Team pueden elevar los umbrales de monitoreo contra proveedores identificados como realizando activamente un ataque e incluso pueden bloquear por completo a un proveedor de servicios determinado. Nota: tenga en cuenta las leyes internacionales de privacidad si envía datos cifrados o sensibles a través de fronteras.
No se exceda - Es fácil emocionarse con técnicas avanzadas y querer lanzar todo contra un objetivo. Si está emulando una amenaza adversarial específica, solo aproveche las técnicas que el actor de amenazas real usó o técnicas dentro del conjunto de habilidades del actor de amenazas. Si sus pruebas de red team atacarán el mismo objetivo a largo plazo, considere comenzar "fácil" y trabajar a través del tradecraft más avanzado a medida que avanzan sus evaluaciones. Evolucionar la técnica del red team junto con la del blue team empujará constantemente a la organización hacia adelante, mientras que golpear al blue team con todo a la vez puede abrumarlo y ralentizar el proceso de aprendizaje.
Monitoree los registros - Todos los registros deben monitorearse durante todo el compromiso: registros SMTP, registros de Apache, tcpdump en redirectores socat, registros de iptables (específicos para el reenvío de tráfico o el filtrado dirigido), weblogs, registros de Cobalt Strike/Empire/MSF. Reenvíe los registros a una ubicación central, como con rsyslog, para un monitoreo más fácil. La retención de datos de la terminal del operador puede ser útil para revisar el uso histórico de comandos durante una operación. @Killswitch_GUI creó un programa fácil de usar llamado lTerm que registrará todos los comandos de la terminal bash en una ubicación central. Registre toda la salida de la terminal con lTerm. Consulte la publicación de Vincent Yiu CobaltSplunk para ver un ejemplo de cómo enviar registros de Cobalt Strike a Splunk para monitoreo y análisis avanzado de infraestructura.* Implementar alertas de eventos de alto valor - Configurar la infraestructura de ataque para generar alertas sobre eventos de alto valor, como nuevas sesiones de C2 o capturas de credenciales. Una forma popular de implementar alertas es mediante la API de una plataforma de chat, como Slack. Consulta las siguientes publicaciones sobre alertas de Slack: Slack Shell Bot - Russel Van Tuyl (@Ne0nd0g), Slack Notifications for Cobalt Strike - Andrew Chiles (@AndrewChiles), Slack Bots for Trolls and Work - Jeff Dimmock (@bluscreenfojeff)
Identificar la respuesta a incidentes - Si es posible, intenta identificar pasiva o activamente las acciones de respuesta a incidentes antes de que comience la evaluación. Por ejemplo, envía un correo de phishing mediocre al objetivo (usando infraestructura no relacionada) y monitorea el tráfico que recibe esa infraestructura. Las investigaciones del equipo de respuesta a incidentes pueden revelar mucha información sobre cómo opera el equipo y qué infraestructura utiliza. Si esto se puede determinar antes de la evaluación, se puede filtrar o redirigir por completo.
UN GRAN AGRADECIMIENTO a todas las siguientes personas (listadas alfabéticamente) que contribuyeron con herramientas, consejos o enlaces para incluir en la wiki, y otro AGRADECIMIENTO a cualquiera que haya escrito una herramienta o publicación referenciada en esta wiki.