Páginas de verificación falsas están redirigiendo a los usuarios hacia malware. A pesar de que las direcciones web cambian constantemente, investigadores detectaron que durante cinco meses cuatro cadenas de ataque distintas utilizaban la misma red de alojamiento. Debido a que los dominios y servidores varían continuamente, bloquear sitios web individuales resulta ser una estrategia ineficaz para detener estas amenazas.

Las páginas de verificación falsas están dirigiendo a las personas hacia el malware, pero las direcciones web detrás de los señuelos no dejan de cambiar.

Durante cinco meses, los investigadores rastrearon cuatro cadenas de ataque diferentes que comenzaron con la misma red de hosting, incluso mientras los dominios, las descargas y los servidores de comando variaban. Este patrón hace que bloquear sitios web individuales sea una forma ineficaz de detener el primer paso.

La mayoría de las víctimas llegaron a un CAPTCHA falso a través de anuncios en línea, aunque una llegó mediante un enlace enviado por correo electrónico. La página copiaba silenciosamente un comando en el portapapeles y luego le decía al visitante que abriera el cuadro de Ejecutar de Windows y lo pegara.

Al igual que en ataques anteriores de CAPTCHA falsos, seguir esas instrucciones podría iniciar una infección sin necesidad de abrir un archivo adjunto sospechoso.

Analistas de ActiveSOC identificaron la infraestructura compartida mientras revisaban aproximadamente 150 alertas en entornos monitoreados.

ActiveSOC afirmó en un informe que cuatro casos llegaron a la ejecución de comandos, mientras que la mayoría de los contactos se detuvieron en la página del señuelo.

Los hallazgos describen un punto de entrada recurrente, no evidencia de que cada visitante fuera infectado, y esto muestra que las consecuencias variaron ampliamente.

Una cadena instaló un stealer (ladrón de datos) que sobrevivió a un reinicio, mientras que otra colocó un implante de Node.js en un host y permaneció activo durante casi dos días.

Un intento separado contactó con un cubo de almacenamiento en la nube pero no mostró una instalación confirmada de segunda etapa, lo que subraya la brecha entre la exposición y el compromiso.

Los dominios no dejan de desaparecer

El vínculo común fue la red de un proveedor de hosting registrado en las Seychelles. Los investigadores vieron al menos siete direcciones de entrada a través de seis rangos de red separados, y el proveedor expandió su espacio anunciado durante la investigación.

Es posible que los operadores hayan utilizado el mismo servicio, pero la evidencia no establece quién controlaba las campañas. Solo en una dirección, los investigadores observaron 12 dominios señuelo en su telemetría y encontraron 11 más en los datos de escaneo público.

Otros utilizaron sitios web de tiendas o restaurantes comprometidos, haciendo eco de la investigación sobre redirecciones envenenadas, donde la barra de direcciones del navegador mostraba un sitio web genuino mientras un script inyectado proporcionaba el desafío falso. Esa debilidad hace que las comprobaciones simples de dominios no sean fiables.

Esta investigación resalta lo que permanece fijo detrás de los nombres cambiantes y por qué eliminar un señuelo a la vez cambia muy poco. Algunas páginas incluso copiaban el nombre del sitio host en el desafío, haciendo que la solicitud pareciera pertenecer a ese lugar.

Una plantilla capturada mezclaba instrucciones de Windows con una referencia mal escrita a una función de Mac. Una vez que la gente pegaba el comando, el siguiente paso podía provenir del propio proveedor, de un cubo en la nube o de un instalador disfrazado de software.

El instalador colocaba una librería maliciosa junto a una aplicación legítima, una técnica que se asemeja a los casos de sideloading de instaladores de software reportados en otros lugares. Esos ejemplos sirven de contexto, no son evidencia de que las campañas separadas compartan un operador.

Bloqueando el primer paso

La velocidad fue crucial en un caso documentado: el navegador llegó al señuelo y el usuario ejecutó el comando pegado 41 segundos después. Una alerta de endpoint siguió un segundo después de la ejecución.

Los investigadores no pudieron determinar si la protección detuvo la siguiente etapa o si el cubo de la nube simplemente falló al entregarla, por lo que no calificaron ese host como comprometido.

Otras cadenas fueron más difíciles de seguir tras la página inicial. Un implante recuperó su servidor de comandos a través de una búsqueda en blockchain en lugar de un dominio convencional, un enfoque explicado en los informes sobre control de comandos basados en blockchain.

Es por esto que detener el señuelo no sustituye la monitorización de la actividad que ya se está ejecutando en un dispositivo. ActiveSOC recomienda revisar el tráfico saliente de tu propia organización antes de bloquear la red del proveedor, ya que otro entorno podría depender de una dirección allí.

Luego, bloquea los rangos anunciados de la red, mantén registros de las conexiones denegadas y actualiza la lista de rangos. Una lista fija puede pasar por alto espacios recién añadidos o bloquear direcciones que hayan cambiado de dueño.

Como defensor, también debes estar atento a los navegadores que pasan la ejecución a intérpretes de comandos, librerías no firmadas junto a software firmado y entornos de ejecución (runtimes) confiables lanzados desde carpetas donde el usuario tiene permisos de escritura.

Los anuncios sospechosos merecen atención, pero una alerta sobre la visita a una página por sí sola no prueba que se haya ejecutado malware. Enseña a tus usuarios que un sitio web que les pida pegar un comando del portapapeles en el cuadro de Ejecutar no está realizando una verificación.

Fuentes:
https://cybersecuritynews.com/domains-keep-disappearing/