Query SQL Forense

¿Qué es el Análisis Forense de Queries SQL?

El análisis forense de queries SQL es la técnica de investigación digital que examina las consultas SQL ejecutadas en bases de datos para:

1. Detectar accesos no autorizados - Quién accedió a datos sensibles y cuándo
2. Identificar inyecciones SQL - Ataques que explotan vulnerabilidades de input
3. Rastrear modificaciones - INSERT, UPDATE, DELETE no autorizados
4. Documentar extracción masiva - Descargas anormales de datos (data breach)
5. Reconstruir actividad - Timeline completo de operaciones en la base de datos

¿Dónde Se Encuentran las Queries SQL?

1. Logs del Servidor de Base de Datos

MySQL/MariaDB:

# Las rutas dependen de la distribución y de la configuración.
# Consultar las variables, no asumir el camino:
#   SHOW VARIABLES LIKE 'general_log%'; SHOW VARIABLES LIKE 'slow_query_log%';
/var/log/mysql/mysql.log          # ubicación habitual en Debian/Ubuntu
/var/log/mysql/mysql-slow.log     # Slow queries

PostgreSQL:

# log_directory: por defecto 'log', relativo al directorio de datos. Consultar:
#   SHOW log_directory;  SHOW data_directory;
# NO suponer la ruta
log_statement / log_min_duration_statement   # qué consultas registra el server log

SQL Server:

Extended Events sessions          # el mecanismo vigente
SQL Server Profiler traces        # en desuso: sustituido por Extended Events
Default trace                     # traza ligera de eventos de configuración,
                                  # NO un registro de las consultas ejecutadas

Oracle:

Unified Auditing                  # auditoría de accesos (audit_trail en versiones previas)
AWR                               # métricas de RENDIMIENTO y SQL agregado por plan;
                                  # no es el registro de cada consulta ejecutada
LogMiner                          # lectura de los redo logs: qué cambió y cuándo

2. Logs de Aplicación

Las aplicaciones web suelen logear queries ejecutadas:

[2025-03-15 14:23:45] SELECT * FROM usuarios WHERE email='juan@example.com'
[2025-03-15 14:23:47] UPDATE usuarios SET password='...' WHERE id=12345
[2025-03-15 14:23:50] DELETE FROM logs WHERE fecha < '2025-01-01'

3. Estadísticas de ejecución en memoria

No es un registro de lo ocurrido, y confundirlo con uno lleva a conclusiones falsas:

• MySQL: performance_schema.events_statements_history sí guarda las últimas sentencias por hilo, con su texto
• PostgreSQL: pg_stat_statements no guarda un histórico: acumula estadísticas agregadas por consulta normalizada —número de ejecuciones, tiempos— sin los valores de los parámetros ni el momento de cada llamada
• SQL Server: sys.dm_exec_query_stats

4. Binlog / Transaction Log

Registro de transacciones para replicación y recuperación:

• MySQL: binlog files (recuperación punto-a-punto)
• PostgreSQL: WAL (Write-Ahead Log)
• SQL Server: Transaction log (.ldf)

Técnicas Forenses de Análisis SQL

1. Análisis de Inyecciones SQL

Qué buscar:

Queries con patrones típicos de inyección:

-- Bypass de autenticación
SELECT * FROM users WHERE username='admin'--' AND password='X'

-- Extracción de datos (UNION-based)
SELECT nombre FROM productos WHERE id=1 UNION SELECT password FROM usuarios--

-- Blind SQL injection
SELECT * FROM users WHERE id=1 AND 1=1--  (TRUE)
SELECT * FROM users WHERE id=1 AND 1=0--  (FALSE)

-- Time-based blind
SELECT * FROM users WHERE id=1 AND SLEEP(5)--

Indicadores forenses:

• Comentarios SQL en queries (--, /**/, #)
• UNION SELECT inesperados
• Funciones de tiempo (SLEEP, WAITFOR DELAY)
• Queries con sintaxis malformada
• Múltiples intentos fallidos seguidos de uno exitoso

2. Rastreo de Accesos No Autorizados

Análisis temporal:

-- Accesos fuera de horario laboral
SELECT user, query_text, timestamp
FROM query_log
WHERE HOUR(timestamp) NOT BETWEEN 8 AND 18
AND user='empleado_interno';

-- Accesos anormales a tablas sensibles
SELECT user, COUNT(*) as num_queries
FROM query_log
WHERE query_text LIKE '%clientes%' OR query_text LIKE '%tarjetas%'
GROUP BY user
HAVING COUNT(*) > 1000;

3. Detección de Extracción Masiva

Patrones sospechosos:

-- SELECT masivos (sin WHERE = toda la tabla)
SELECT * FROM clientes;
SELECT * FROM transacciones;
SELECT * FROM usuarios;

-- Exportaciones con OUTFILE
SELECT * INTO OUTFILE '/tmp/clientes.csv' FROM clientes;

-- Queries con LIMIT altos (paginación de extracción)
SELECT * FROM usuarios LIMIT 0, 10000;
SELECT * FROM usuarios LIMIT 10000, 10000;
...

Indicadores forenses:

• Queries SELECT sin cláusulas WHERE
• Uso de INTO OUTFILE o exportación
• Secuencias de queries con LIMIT incremental
• Volumen inusual de queries por usuario/IP
• Queries a múltiples tablas en corto período

4. Análisis de Modificaciones/Borrados

Reconstrucción de cambios:

-- UPDATEs sospechosos
UPDATE usuarios SET rol='admin' WHERE id=12345;  -- Escalada de privilegios
UPDATE logs SET fecha='2024-01-01' WHERE id > 5000;  -- Manipulación temporal
DELETE FROM audit_log WHERE user='empleado_sospechoso';  -- Borrado de evidencia

-- Análisis del binlog de MySQL para recuperar queries ejecutadas:
# El formato por defecto en MySQL 8 es ROW: sin --verbose el SQL no aparece como texto.
# Y la ruta se consulta, no se supone: SHOW VARIABLES LIKE 'log_bin_basename';
mysqlbinlog --verbose --base64-output=DECODE-ROWS "$BINLOG" | grep -i "DELETE"

Herramientas Forenses para Análisis SQL

1. Análisis de Logs

2. Análisis de Inyecciones SQL

3. Análisis de Performance y Actividad

Casos de Uso en Peritaje Informático

Caso 1: Empleado Descarga Base de Datos Antes de Irse

Situación: Empresa sospecha que empleado descargó base de clientes antes de renunciar para llevarla a competencia

Análisis forense:

Evidencia encontrada:

• 15/03/2025 14:23:12 - SELECT * FROM clientes; (30.000 registros)
• 15/03/2025 14:25:34 - SELECT * FROM contratos; (15.000 registros)
• 15/03/2025 14:27:01 - SELECT * FROM precios; (5.000 registros)

→ Lo que esto acredita: que el servidor recibió esas consultas. No que el cliente recibiera todas las filas ni que se exfiltraran: el registro cuenta sentencias, no resultados entregados. Para sostener el volumen hacen falta otros artefactos —tráfico de red, ficheros creados, logs de la aplicación—.

Caso 2: Inyección SQL en E-commerce

Situación: Tienda online sufrió acceso no autorizado a datos de tarjetas de clientes

Análisis forense:

Evidencia encontrada:

• 127 intentos de inyección SQL desde misma IP
• Extracción exitosa de tabla usuarios (1.234 registros)
• Extracción de tabla pagos (567 registros con datos de tarjetas)

→ Conclusión pericial: Brecha de seguridad por inyección SQL, datos personales y financieros comprometidos

Caso 3: Modificación Fraudulenta de Registros Contables

Situación: Auditoría detecta discrepancias en base de datos contable, sospecha de manipulación interna

Análisis forense:

Evidencia encontrada:

• 23 facturas modificadas fuera de horario laboral
• Montos incrementados artificialmente (+450.000€)
• Intento de borrar logs de auditoría

→ Conclusión pericial: Fraude contable interno con evidencia digital clara

Preservación de Evidencia SQL

Protocolo de Preservación Inmediata

Limitaciones del Análisis SQL Forense

❌ Limitación 1: Logs No Habilitados

Problema: el registro de consultas viene desactivado de fábrica en los motores más comunes —el general_log y el slow_query_log de MySQL, por ejemplo, tienen OFF como valor por defecto—. No es una mala configuración del cliente: es el comportamiento estándar.

Solución: Verificar inmediatamente si hay logs disponibles. Si no, el análisis forense se limita a:

• Analizar estructuras de tablas (detectar modificaciones)
• Comparar con backups anteriores
• Analizar logs de aplicación (si los hay)

❌ Limitación 2: Logs Ya Rotados

Problema: Los logs rotan cada X días y se pierden si no hay retención configurada

Solución: Actuar rápidamente. Cada día que pasa reduce la ventana de evidencia disponible.

❌ Limitación 3: Queries Ofuscadas

Problema: Atacantes sofisticados ofuscan queries SQL:

-- Query normal
SELECT password FROM users WHERE id=1;

-- Query ofuscada
SEL/**/ECT/**/password/**/FR/**/OM/**/users/**/WHE/**/RE/**/id=1;

Solución: Análisis con expresiones regulares y técnicas de de-ofuscación.

❌ Limitación 4: Accesos Directos a Archivos

Problema: Si el atacante tiene acceso físico a archivos de base de datos (.ibd, .frm), puede leerlos sin generar queries

Solución: Análisis forense del sistema operativo (accesos a archivos, logs de sistema)

Conclusión

El análisis forense de queries SQL es fundamental para investigaciones de fraudes internos, brechas de seguridad y litigios relacionados con bases de datos. La clave del éxito es la preservación inmediata de logs antes de que roten y la aplicación de técnicas forenses rigurosas para reconstruir la actividad en la base de datos.

Referencias y fuentes

1. MySQL 8.0 Reference Manual — The General Query Log, The Slow Query Log y Server System Variables: ambos registros tienen OFF como valor por defecto.
2. MySQL 8.0 — The Binary Log y mysqlbinlog. El binlog registra los cambios, no las consultas de solo lectura.
3. PostgreSQL 18 — Error Reporting and Logging, pg_stat_statements —estadísticas agregadas, no un registro de consultas— y pg_waldump.
4. Microsoft — Extended Events Overview, SQL Server Profiler (en desuso) y The Transaction Log.
5. Oracle Database 19c — Introduction to Auditing y Using LogMiner to Analyze Redo Log Files.
6. RGPD — Reglamento (UE) 2016/679, art. 32 sobre seguridad del tratamiento.
7. NIST — SP 800-61 Computer Security Incident Handling Guide. La revisión 2 que enlaza este PDF fue retirada el 3 de abril de 2025; la vigente es la Rev. 3. Sobre preservación de evidencia volátil.

Última actualización: 29 de agosto de 2026 Categoría: Técnico Código: QSF-001

Artículos relacionados:

• Perito Informático Judicial: Guía Completa 2026
• Logs de Sistema
• Evidencia Digital
• Análisis Forense Digital