CAV3RN es un marco de espionaje modular que se ha vuelto más difícil de detectar en las redes. Su componente de comunicación más reciente oculta el tráfico de control remoto utilizando Google Apps Script, un servicio legítimo en muchas organizaciones, lo que permite que las conexiones maliciosas pasen inadvertidas. Este sistema ha sido utilizado para atacar objetivos en Israel y otros países.

CAV3RN es un marco de espionaje modular que se está volviendo más difícil de detectar en una red.

Su componente de comunicación más reciente oculta el tráfico de control remoto detrás de Google Apps Script, un servicio que muchas organizaciones utilizan legítimamente.

Este diseño puede hacer que una conexión dañina parezca menos inusual a primera vista. El marco ha sido utilizado contra objetivos en Israel y ha seguido adquiriendo nuevos componentes.

Los investigadores no han descrito la ruta de infección inicial en esta actualización, pero una vez instalado, sus módulos pueden intercambiar mensajes, recopilar detalles del software, recibir tareas y actualizar partes del kit de herramientas sin necesidad de reiniciar el host.

Analistas de Securelist identificaron las nuevas funciones de comunicación y control mientras rastreaban el grupo a principios de agosto.

Kaspersky afirmó en un informe que CAV3RN puede elegir una conexión web directa o un relevo de Google Apps Script para cada intercambio, utilizando respuestas de DNS para tomar esa decisión.

El resultado es un canal más resistente para las operaciones de espionaje. Bloquear una ruta podría no terminar con el acceso del operador porque el malware puede cambiar de método, mientras que el uso de un servicio en la nube familiar puede complicar la revisión del tráfico web sospechoso.

Un abuso similar aparece en los servidores C2 de servicios en la nube, donde plataformas confiables pueden proteger la infraestructura maliciosa. Esto eleva el coste de detección en entornos donde las herramientas de seguridad permiten ampliamente el tráfico común de nube y DNS.

CAV3RN utiliza Google Apps Script como relevo de C2

El componente es una DLL de Windows de 64 bits que comienza informando una lista de DLLs cercanas y sus versiones.

Luego, pregunta regularmente al sistema DNS qué ruta de comunicación debe utilizar. Esa comprobación ligera convierte las consultas DNS de apariencia ordinaria en una señal de control para el malware.

Una respuesta de registro A de DNS dirige el módulo ya sea hacia HTTPS directo o hacia Google Apps Script, dependiendo de su último número y del estado de error actual de la conexión.

Si la ruta de Google falla, la siguiente consulta puede dirigirlo a HTTPS directo. Este modelo de respaldo se asemeja al canal oculto de tráfico DNS, otra técnica que hace que la resolución de nombres rutinaria sea útil para los atacantes.

Cuando se selecciona el modo Google, CAV3RN envía una solicitud POST a un despliegue de Apps Script que actúa como relevo.

El relevo recibe una instrucción para obtener contenido de un servidor superior y luego devuelve el resultado al sistema infectado. Una solicitud de navegador normal, en cambio, muestra una página inofensiva que indica que la aplicación se está ejecutando normalmente.

El malware también puede comprobar si su ID de despliegue de Google está actualizado. Compara parte de un resumen criptográfico con una respuesta de DNS y, si no coincide, recupera un ID de reemplazo en pequeños fragmentos de respuesta DNS.

Esto permite a los operadores rotar el relevo de Google sin necesidad de reemplazar el propio malware.

El bróker modular añade capacidad de permanencia

CAV3RN también utiliza un bróker local que encuentra componentes DLL compatibles, carga la versión más reciente de cada grupo y pasa mensajes entre ellos.

Escanea el directorio del host cada segundo, lo que permite a los operadores añadir un módulo actualizado bajo una nueva ruta mientras el marco permanece activo.

Esa arquitectura otorga a los operadores una flexibilidad que va más allá de una sola puerta trasera. El bróker puede devolver un inventario de componentes, mientras que el módulo de comunicación puede pasarle las tareas recibidas.

El tráfico HTTPS directo va a un backend controlado por el actor y requiere un encabezado de cliente personalizado, añadiendo otro detalle que tú puedes usar como defensor al investigar tráfico inusual.

Los equipos de seguridad deben revisar la actividad DNS en busca de subdominios aleatorios inusuales bajo el dominio listado, inspeccionar conexiones inesperadas al endpoint web identificado y buscar las DLLs mencionadas.

También deben evitar tratar el tráfico alojado en Google como automáticamente seguro, ya que la campaña de malware de Azure Functions muestra cómo los servicios alojados legítimos pueden ser reutilizados para el control encubierto.

El monitoreo de red debe correlacionar las consultas DNS, las cadenas de redireccionamiento y la actividad de los procesos, en lugar de confiar en un solo indicador.

Las organizaciones que encuentren estos signos deben aislar el dispositivo afectado, preservar los registros relevantes y buscar DLLs cargadas adicionales.

El rápido desarrollo del marco y su diseño de cambio de ruta significan que la investigación temprana es fundamental. Una telemetría de DNS más prolongada también puede exponer los patrones de selección repetitivos del marco.

Fuentes:
https://cybersecuritynews.com/cav3rn-uses-google-apps-script/