En la parte superior del script puedes encontrar dos URL.
En un bucle, este script solicita tareas de getTaskUrl e informa los resultados a completeTaskUrl y luego recupera otra tarea, y así sucesivamente.
¿Qué tipo de tareas, te preguntarás? Bueno, cada tarea consta de lo siguiente:
- ID de tarea
- taskUrl (URL de un sitio aleatorio de WordPress)
- taskUser (nombre de usuario de WordPress)
- checkId (número del lote de contraseñas)
- …y una lista de 100 contraseñas para probar.
Para ilustrar mejor cómo se ve esto, aquí hay un ejemplo de una tarea real recibida por el script malicioso:
Todas las contraseñas de esta tarea pertenecen a colecciones conocidas de contraseñas comunes (y filtradas).
El número de lote de contraseñas más grande que hemos visto hasta ahora fue el #418, por lo que podemos suponer que los atacantes pueden probar más de 41.800 contraseñas para cada sitio.
Ahora que tenemos una comprensión simple de las funciones de administración de tareas del script, echemos un vistazo a cómo el atacante usa estos scripts para lanzar sus ataques contra los sitios víctimas.
Etapas de ataque y ciclo de vida.
El ataque consta de cinco etapas clave que permiten a un mal actor aprovechar sitios web ya comprometidos para lanzar ataques distribuidos de fuerza bruta contra miles de otros sitios potenciales víctimas.
- Etapa 1: obtener las URL de los sitios de WordPress. Los atacantes rastrean Internet ellos mismos o utilizan varios motores de búsqueda y bases de datos para obtener listas de sitios de WordPress objetivo.
- Etapa 2: extraer los nombres de usuario de los autores. Luego, los atacantes escanean los sitios de destino y extraen nombres de usuarios reales de los autores que publican en esos dominios.
- Etapa 3: inyectar scripts maliciosos. Luego, los atacantes inyectan su script dinámico-linx[.]com/chx.js en los sitios web que ya han comprometido.
- Etapa 4: Credenciales de fuerza bruta. Cuando los visitantes normales del sitio abren páginas web infectadas, se carga el script malicioso. Detrás de escena, los navegadores de los visitantes llevan a cabo un ataque distribuido de fuerza bruta en miles de sitios objetivo sin ninguna participación activa de los atacantes.
- Etapa 5: verificar las credenciales comprometidas. Los malos actores verifican las credenciales por fuerza bruta y obtienen acceso no autorizado a los sitios objetivo de la etapa 1.
Entonces, ¿cómo logran los atacantes realmente un ataque distribuido de fuerza bruta desde los navegadores de visitantes de un sitio web completamente inocentes y desprevenidos? Echemos un vistazo más de cerca a la etapa 4.
Pasos del ataque de fuerza bruta distribuida:
- Cuando un visitante del sitio abre una página web infectada, el navegador del usuario solicita una tarea desde la URL hxxps://dynamic-linx[.]com/getTask.php.
- Si la tarea existe, analiza los datos y obtiene la URL del sitio a atacar junto con un nombre de usuario válido y una lista de 100 contraseñas para probar.
- Para cada contraseña de la lista, el navegador del visitante envía la solicitud API wp.uploadFile XML-RPC para cargar un archivo con las credenciales cifradas que se utilizaron para autenticar esta solicitud específica. ¡Son 100 solicitudes de API para cada tarea! Si la autenticación tiene éxito, se crea un pequeño archivo de texto con credenciales válidas en el directorio de cargas de WordPress.
- Cuando se verifican todas las contraseñas, el script envía una notificación a hxxps://dynamic-linx[.]com/completeTask.php de que se ha completado la tarea con un taskId específico (probablemente un sitio único) y checkId (lote de contraseñas).
- Finalmente, el script solicita la siguiente tarea y procesa un nuevo lote de contraseñas. Y así indefinidamente mientras la página infectada esté abierta.
Así es como miles de visitantes en cientos de sitios web infectados, sin saberlo y simultáneamente, intentan forzar la fuerza bruta en miles de otros sitios de WordPress de terceros. Y dado que las solicitudes provienen de los navegadores de visitantes reales, puede imaginar que es un desafío filtrar y bloquear dichas solicitudes.
Cuando finaliza el ataque, los operadores simplemente necesitan visitar los sitios objetivo de su lista (identificados en la etapa 1) e intentar descargar un archivo específico. Si el archivo existe y logran descargarlo, encontrarán las credenciales de usuario válidas de WordPress codificadas en el contenido del archivo.
Estadísticas de ataques
En nuestra telemetría, vemos decenas de miles de solicitudes a miles de dominios únicos que buscan el archivo que este ataque de fuerza bruta intenta cargar. En la mayoría de los casos, la respuesta es 404, lo que significa que el ataque no tuvo éxito. Sin embargo, en aproximadamente el 0,5% de los casos, vemos el código de respuesta 200, lo que significa que los delincuentes podrían haber logrado adivinar la contraseña de WordPress.
Al revisar dos veces los sitios con respuestas “200 OK”, notamos que solo uno de ellos estaba realmente comprometido. El resto de los sitios simplemente tenían configuraciones no estándar que les hacían devolver 200 incluso para páginas «no encontradas». Esto redujo aún más la tasa de éxito de la campaña de fuerza bruta por debajo del 0,02%.
En los últimos 4 días, registramos más de 1200 IP únicas que intentaron descargar el archivo de credenciales. De esas IP, las siguientes cinco direcciones representaron más del 85% de todas las solicitudes.
Indicadores de compromiso, mitigación de riesgos y reflexiones finales.
En este punto, no está exactamente claro por qué los atacantes cambiaron de los drenadores de cifrado Web 3 a un ataque distribuido de fuerza bruta de WordPress. Lo más probable es que se hayan dado cuenta de que, a su escala de infección (~1000 sitios comprometidos), los drenadores de criptomonedas aún no son muy rentables. Además, llaman demasiado la atención y sus dominios se bloquean con bastante rapidez. Por lo tanto, parece razonable cambiar la carga útil por algo más sigiloso, que al mismo tiempo pueda ayudar a aumentar su cartera de sitios comprometidos para futuras oleadas de infecciones que podrán monetizar de una forma u otra.
Más que nada, este ataque nos recuerda la importancia de utilizar contraseñas seguras. Con el nivel de tecnología disponible actualmente para los delincuentes, es bastante fácil probar cientos de miles de contraseñas en millones de sitios en un período de tiempo razonable.
Además de las contraseñas seguras, es posible que desee considerar restringir el acceso a la interfaz de administración de WordPress y al archivo xmlrpc.php únicamente a direcciones IP confiables.
Para los aficionados al WP que creen que podrían verse afectados por este malware y quieren buscar indicadores de compromiso, recomendamos comprobar los directorios de carga de WordPress (wp-content/uploads/…) en busca de archivos desconocidos. Este ataque en particular crea archivos .txt cortos que contienen » ActiveLamezh «. También puede consultar directorios como wp-content/uploads/2024/02/ y wp-content/uploads/2024/03.
Incluso si no encuentra los archivos .txt cargados, considere cambiar las contraseñas de todos los usuarios administradores de WordPress para asegurarse de que sean largas, seguras y únicas de otros conjuntos de credenciales.
Si cree que su sitio web puede estar infectado con malware, pero no está seguro de cómo solucionar el problema, comuníquese con nosotros y charle con nosotros . Nuestros analistas experimentados están disponibles para ayudarlo a deshacerse de las infecciones de malware de sitios web.