Backups y `.sql` al descubierto: la fuga que los bots buscan primero

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

De todas las fugas que revisamos, un backup de base de datos expuesto es la más rentable para el atacante y la más silenciosa para el dueño de la web. Un .sql, un backup.zip o un volcado de phpMyAdmin accesible desde el navegador entrega, en un único archivo, todo lo que un intruso necesitaría robar pieza a pieza. Este artículo amplía nuestra guía sobre cómo saber si tu web está hackeada y se centra en por qué esta fuga es la primera que buscan los bots.

Qué contiene un backup de base de datos expuesto

La base de datos es el corazón de cualquier CMS o tienda. Un backup completo no es un fichero técnico inofensivo: es una fotografía íntegra de tu negocio. Un backup de base de datos expuesto suele incluir:

• Usuarios y hashes de contraseñas de todos los administradores y clientes.
• Datos personales de clientes: nombres, correos, teléfonos, direcciones, historial de pedidos.
• Claves y tokens guardados en tablas de configuración o de opciones.
• Contenido privado, borradores, notas internas y metadatos.

Con los hashes en la mano, un atacante los rompe sin prisa y en su propio equipo. Con los datos personales, ya tienes un incidente de protección de datos con obligaciones legales, aunque nadie haya «entrado» a tu panel.

Por qué los bots lo buscan antes que nada

Nada de esto requiere un ataque sofisticado. Existen redes de bots que recorren internet pidiendo, sobre cada dominio, una lista de nombres de archivo habituales. Prueban decenas de rutas por segundo, sin descanso. Los nombres más buscados son justamente los que ponemos por comodidad:

• backup.sql, database.sql, dump.sql, db.sql
• backup.zip, site.zip, www.tar.gz, public_html.zip
• El nombre del dominio: tudominio.sql, tudominio.zip
• Copias con fecha: backup-2026.sql, backup_old.sql

El patrón que vemos una y otra vez: alguien hace una migración o una prueba, deja el .sql «un momento» en la raíz de la web y se olvida. Ese momento es suficiente. Guías de referencia como las de OWASP clasifican esta exposición de datos sensibles entre los riesgos más comunes precisamente porque es barata de explotar y devastadora en consecuencias.

Backup de base de datos expuesto: cómo comprobar si tienes uno

La verificación está a tu alcance sin herramientas especiales:

• Prueba en el navegador rutas como tudominio.com/backup.sql o tudominio.com/backup.zip. Si empiezan a descargarse, tienes una fuga activa.
• Revisa por FTP o el gestor de archivos del hosting la raíz pública (public_html, httpdocs, www) buscando cualquier .sql, .zip, .tar.gz o .gz.
• Comprueba también carpetas de plugins de copias de seguridad mal configurados, que a veces dejan los backups en rutas adivinables.

Si encuentras uno, no basta con borrarlo: da por comprometidos todos los datos que contenía. Cambia las contraseñas de administración, fuerza el restablecimiento a los usuarios si procede y rota cualquier clave que estuviera en esas tablas. Y documenta el hallazgo: en un incidente con datos personales, saber qué se expuso y durante cuánto tiempo forma parte de tu obligación.

Cómo evitar que vuelva a pasar

• Nunca guardes copias dentro de la carpeta pública. Los backups deben vivir fuera del public_html o en almacenamiento externo, nunca donde un navegador pueda pedirlos.
• Automatiza y cifra. Usa un sistema de copias que las mueva a un destino privado y las cifre; no dependas de arrastrar archivos a mano.
• Bloquea las extensiones peligrosas a nivel de servidor para que un .sql o .zip en la raíz devuelva un error, no una descarga.
• Revisa después de cada migración. El descuido casi siempre ocurre justo tras un cambio o una mudanza de hosting.

Este descuido es inaceptable en entornos exigentes como banca o comercios que manejan datos de tarjeta, donde una copia expuesta es directamente un incidente notificable; por eso en PathSentinel lo tratamos con la misma seriedad en una pyme que en una entidad regulada. La documentación de Google sobre sitios pirateados y las recomendaciones de CISA insisten en el mismo principio: reducir la superficie expuesta antes de que alguien la encuentre por ti.

Conviene además revisar los síntomas vecinos. Cuando esos datos filtrados se usan para colar código, el resultado suele ser el desvío de visitas que explicamos en redirecciones maliciosas, o los avisos de mixed content y HTTPS roto cuando el atacante manipula recursos de la página.