Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Atacan instancias de MongoDB para borrar bases de datos y dejar notas de rescate


Los actores de amenazas están atacando activamente instancias de MongoDB expuestas en internet en campañas automatizadas de ransomware a gran escala. Los ataques siguen un patrón consistente: los atacantes escanean bases de datos de MongoDB no protegidas accesibles en internet, eliminan los datos almacenados e insertan notas de rescate exigiendo el pago en Bitcoin. Evidencias recientes indican que estas campañas siguen siendo altamente rentables a pesar de que las demandas de rescate suelen ser modestas.

 


Los actores de amenazas están atacando activamente instancias de MongoDB expuestas en internet en campañas automatizadas de ransomware a gran escala.

Los ataques siguen un patrón consistente: los atacantes escanean bases de datos de MongoDB no protegidas accesibles en internet, eliminan los datos almacenados e insertan notas de rescate exigiendo el pago en Bitcoin.



Evidencias recientes indican que estas campañas siguen siendo muy rentables, a pesar de que las demandas de rescate suelen ser modestas, entre 500 y 600 dólares por víctima.

El patrón de explotación es técnicamente sencillo pero operativamente efectivo. Los actores de amenazas utilizan herramientas automatizadas de escaneo para identificar servicios de MongoDB expuestos en el puerto 27017 sin autenticación.


Una vez establecido el acceso, los atacantes exportan o enumeran el contenido de la base de datos para evaluar su valor antes de ejecutar operaciones de destrucción de datos.

 

Instancias de MongoDB hackeadas

Las colecciones y bases de datos son eliminadas o borradas sistemáticamente, tras lo cual se inserta un mensaje de demanda de rescate en la instancia de MongoDB.

A las víctimas se les amenaza con que sus datos serán eliminados permanentemente a menos que envíen un pago en Bitcoin a direcciones de billetera controladas por los atacantes en un plazo determinado, generalmente 48 horas.

El análisis de compromisos en el mundo real revela que aproximadamente el 45,6% de las instancias de MongoDB completamente expuestas ya contienen notas de rescate, lo que indica que las víctimas han pagado los rescates o que sus datos han sido destruidos sin posibilidad de recuperación.

Notablemente, más del 98% de los pagos de rescate observados se dirigieron a una sola billetera de Bitcoin, lo que sugiere una actividad coordinada por un actor de amenazas dominante que opera esta campaña rentable.

Escaneos a nivel de internet han identificado más de 200.000 servidores de MongoDB accesibles públicamente en línea, con aproximadamente 3.100 instancias confirmadas como completamente expuestas y sin controles de acceso.

Esto representa una superficie de riesgo crítica, ya que cualquier MongoDB conectado a internet sin autenticación se vuelve inmediatamente vulnerable a la explotación automatizada.

La causa subyacente de este panorama de vulnerabilidades proviene de mala configuración en los despliegues más que de vulnerabilidades en el software.

Las imágenes de Docker y las configuraciones de infraestructura copiadas y pegadas suelen vincular MongoDB a todas las interfaces de red (0.0.0.0) por defecto, sin imponer autenticación.

Los desarrolladores frecuentemente despliegan estas plantillas en entornos de producción con el puerto 27017 expuesto externamente, creando sin querer acceso directo a bases de datos desprotegidas desde internet.

Un análisis de los repositorios de contenedores de Docker Hub identificó 763 imágenes con configuraciones inseguras de MongoDB en 30 espacios de nombres distintos.

Dos proyectos ampliamente distribuidos, con más de 15.000 descargas cada uno, contenían enlaces de bases de datos idénticos sin autenticación, demostrando cómo los valores predeterminados inseguros se propagan a través de plantillas de infraestructura populares.

Medidas de mitigación urgentes

Según Flare, las organizaciones deben auditar inmediatamente sus despliegues de MongoDB para identificar cualquier exposición pública.

Las medidas preventivas críticas incluyen restringir MongoDB solo a redes privadas y aplicar autenticación SCRAM con control de acceso basado en roles.

Implementar reglas de firewall para bloquear el acceso público en el puerto 27017 y reemplazar las imágenes predeterminadas de Docker con configuraciones reforzadas.

La monitorización continua de exposiciones con herramientas como Shodan Monitor y plataformas de gestión de postura de seguridad en la nube permite detectar rápidamente configuraciones erróneas antes de que sean explotadas.

Aunque MongoDB no tiene vulnerabilidades conocidas de ejecución remota de código antes de la autenticación, un solo día cero podría exponer instantáneamente cientos de miles de servidores a ataques automatizados a gran escala.

Las organizaciones deben priorizar la segmentación de red y la aplicación inmediata de autenticación para eliminar este vector de amenaza persistente.


Fuentes:
https://cybersecuritynews.com/mongodb-instances-hacked/

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.