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.
