Instancias de MongoDB expuestas directamente a internet vuelven a estar bajo fuego en campañas automatizadas de ransomware. Grupos criminales están escaneando masivamente la red en busca de servidores mal configurados, eliminan las bases de datos almacenadas y las reemplazan por notas de rescate que prometen una supuesta “recuperación” de la información a cambio de pago.
MongoDB expuesto a internet: cifras clave y alcance de los ataques
Según un análisis reciente de la firma de ciberseguridad Flare, se identificaron más de 208.500 servidores MongoDB accesibles públicamente. Una fracción significativa presenta configuraciones inseguras: más de 100.000 instancias filtran información operativa (estado del clúster, parámetros de configuración, etc.) y alrededor de 3.100 servidores permiten conexión sin ningún tipo de autenticación.
Lo más preocupante es que casi la mitad (45,6%) de los MongoDB sin restricciones de acceso ya estaban comprometidos en el momento del estudio. En estos sistemas, las bases de datos legítimas habían sido borradas y sustituidas por colecciones que contienen notas de extorsión. En total, se contabilizaron cerca de 1.400 víctimas activas de este tipo de ataques ransomware dirigidos a MongoDB.
Cómo funcionan las campañas de ransomware contra bases de datos MongoDB
La cadena de ataque sigue un patrón automatizado. Los delincuentes utilizan escáneres para localizar servidores con los puertos por defecto de MongoDB (27017/27018) expuestos a internet. Cuando encuentran un sistema accesible y sin autenticación habilitada, se conectan con permisos por defecto, enumeran las bases existentes y proceden a eliminar su contenido.
Acto seguido, crean una nueva base o colección con instrucciones de pago. La investigación de Flare revela que la mayoría de las notas exigen 0,005 BTC (unos 500–600 dólares estadounidenses al momento del análisis), a pagar en un plazo de 48 horas. El rescate se dirige a uno de cinco monederos de Bitcoin, aunque el mismo wallet aparece en aproximadamente el 98% de los casos, lo que sugiere un único operador o un grupo estrechamente coordinado detrás de la campaña.
Un problema recurrente: campañas de extorsión contra MongoDB desde 2016
Los ataques a servidores MongoDB inseguros no son una novedad. Desde al menos 2016 se han documentado oleadas similares en las que miles de bases de datos abiertas fueron borradas o secuestradas. En numerosos incidentes, los atacantes ni siquiera intentaban monetizar la brecha: simplemente destruían los datos, provocando pérdidas irreversibles para organizaciones sin copias de seguridad fiables.
Los investigadores señalan que la actividad actual es algo menor que en los picos observados antes de 2021, aunque continúa siendo significativa. Un fenómeno llamativo es la existencia de instancias abiertamente vulnerables que, sin embargo, no muestran signos de compromiso. Una hipótesis plausible es que algunos administradores ya habrían pagado el rescate y los atacantes optan por no volver a tocar esos sistemas para evitar levantar sospechas.
Configuraciones inseguras y versiones obsoletas: el talón de Aquiles de MongoDB
La causa raíz de estas brechas se encuentra en la configuración insegura de MongoDB. Es frecuente que instancias desplegadas para pruebas o prototipos se migren a producción sin revisar parámetros críticos. Como resultado, el servidor:
- escucha en 0.0.0.0, quedando accesible desde internet,
- opera sin autenticación obligatoria,
- mantiene credenciales débiles o predeterminadas.
A este problema se suma el uso de software sin actualizar. El estudio detecta cerca de 95.000 servidores MongoDB accesibles desde internet en versiones obsoletas, con vulnerabilidades ya conocidas y documentadas. Aunque muchas permiten principalmente ataques de denegación de servicio (DoS), en la práctica suelen integrarse en cadenas de ataque más complejas que pueden derivar en una intrusión completa.
Por qué pagar el rescate no garantiza la recuperación de la base de datos
Aunque las notas prometen la “devolución” o “desencriptado” de la información tras el pago, no hay garantías técnicas de que los atacantes conserven una copia de la base de datos. Históricamente, en múltiples campañas contra MongoDB los delincuentes simplemente han borrado los datos sin cifrado real ni respaldo previo, por lo que ni siquiera podrían restaurarlos aunque decidieran cumplir su promesa.
Las agencias reguladoras y los marcos de referencia en ciberseguridad (como NIST o ENISA) desaconsejan explícitamente negociar o pagar rescates, dado que se trata de un escenario de alto riesgo en el que la organización puede perder el dinero y los datos. La estrategia recomendada se centra en la prevención, el endurecimiento de la configuración y la existencia de copias de seguridad robustas.
Buenas prácticas de seguridad para proteger servidores MongoDB
La protección efectiva de MongoDB requiere actuar en varios frentes:
1. Restringir el acceso de red.
Siempre que sea posible, MongoDB no debe ser accesible directamente desde internet. Es recomendable:
- limitar la vinculación de la instancia con interfaces internas mediante
bindIp, - filtrar el acceso a través de un firewall solo desde IPs de confianza,
- emplear VPN o bastion hosts para tareas de administración remota.
2. Activar autenticación y usar credenciales robustas.
Debe habilitarse la autenticación de MongoDB, definir cuentas específicas con el mínimo privilegio necesario y utilizar contraseñas únicas y sólidas. Es inaceptable mantener cuentas por defecto o combinaciones triviales de usuario y contraseña.
3. Asegurar despliegues en Kubernetes y en la nube.
En entornos de contenedores y nubes públicas, la seguridad de MongoDB depende de network policies y grupos de seguridad bien diseñados. Copiar configuraciones genéricas de guías públicas sin adaptarlas al contexto de la organización conduce con facilidad a bases de datos expuestas.
4. Mantener MongoDB actualizado y gestionar vulnerabilidades.
La actualización periódica del motor de base de datos y sus componentes reduce la superficie de ataque. Es aconsejable complementar esto con escaneos de vulnerabilidades, inventarios de servicios expuestos y revisión continua de puertos abiertos.
5. Implementar copias de seguridad y planes de recuperación.
Las copias de seguridad periódicas, probadas y almacenadas de forma aislada del entorno de producción son la única vía fiable para recuperar datos tras un ataque ransomware o un borrado accidental. Estas copias deben verificarse de forma regular mediante simulacros de restauración.
Las campañas automatizadas de ransomware contra instancias MongoDB abiertas demuestran que un solo error de configuración puede desembocar en la pérdida completa de información crítica. Resulta fundamental que las organizaciones inventaríen todas sus bases de datos, revisen su exposición a internet, refuercen los mecanismos de autenticación y establezcan políticas de copia de seguridad sólidas. Actuar de forma proactiva hoy es la mejor forma de evitar que la próxima nota de rescate aparezca en su propio servidor MongoDB mañana.
