¿Qué se puede detectar con análisis forense de queries SQL?

Accesos no autorizados a bases de datos, inyecciones SQL maliciosas, extracción masiva de datos (data breaches), alteración de registros, borrado de evidencia, y actividad de usuarios específicos mediante análisis de logs de transacciones y query history.

¿Dónde se almacenan los logs de queries SQL?

En MySQL: general_log y slow_query_log. En PostgreSQL: pg_stat_statements y csvlog. En SQL Server: SQL Server Profiler traces y Extended Events. En Oracle: audit trail y AWR. La ubicación exacta depende de la configuración del servidor.

¿Cuánto tiempo se conservan los logs SQL?

Depende de la configuración del servidor. Por defecto, MySQL mantiene logs por días/semanas, PostgreSQL similar, SQL Server depende del plan de mantenimiento (7-30 días típico). Empresas con compliance suelen retener 90 días-1 año. Sin configuración específica, los logs rotan y se pierden.

Query SQL Forense - Análisis de Consultas SQL en Peritaje Informático | Glosario

¿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:

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

Marco de Aplicación

Casos típicos: fraudes internos (empleados que acceden a datos de clientes), brechas de seguridad (hackers explotando vulnerabilidades SQL), litigios laborales (empleado descargó base de datos antes de irse), cumplimiento RGPD (auditorías de accesos a datos personales).

¿Dónde Se Encuentran las Queries SQL?

1. Logs del Servidor de Base de Datos

MySQL/MariaDB:

/var/log/mysql/mysql.log          # General query log
/var/log/mysql/mysql-slow.log     # Slow queries

PostgreSQL:

/var/lib/postgresql/data/pg_log/  # Logs de servidor
pg_stat_statements                # Estadísticas de queries

SQL Server:

SQL Server Profiler traces
Extended Events sessions
Default trace files

Oracle:

audit_trail                       # Auditoría de accesos
AWR (Automatic Workload Repository)

2. Logs de Aplicación

Las aplicaciones web suelen logear queries ejecutadas:

[2025-03-15 14:23:45] SELECT * FROM usuarios WHERE email='[email protected]'
[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. Caché de Queries

Bases de datos mantienen caché de queries recientes en memoria:

MySQL: performance_schema.events_statements_history
PostgreSQL: pg_stat_statements
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)

Volatilidad de la Evidencia

Los logs SQL son altamente volátiles. Sin configuración específica de retención, rotan cada 7-30 días. En investigaciones, es crítico preservar inmediatamente los logs antes de que se sobrescriban.

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:
mysqlbinlog /var/log/mysql/mysql-bin.000123 | grep -i "DELETE FROM logs"

Herramientas Forenses para Análisis SQL

1. Análisis de Logs

Herramienta	Uso	Base de Datos
mysqlbinlog	Recuperar queries desde binlog	MySQL/MariaDB
pg_waldump	Analizar Write-Ahead Log	PostgreSQL
SQL Server Profiler	Captura en tiempo real	SQL Server
Oracle LogMiner	Análisis de archive logs	Oracle

2. Análisis de Inyecciones SQL

Herramienta	Descripción
SQLMap	Detección automática de vulnerabilidades SQL injection
Burp Suite	Proxy para analizar peticiones HTTP con queries SQL
ModSecurity	WAF que logea intentos de inyección SQL

3. Análisis de Performance y Actividad

Herramienta	Uso
pt-query-digest (Percona)	Análisis de slow query log de MySQL
pgBadger	Análisis de logs PostgreSQL con gráficos
SQL Sentry	Monitorización forense de SQL Server

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:

Identificar usuario/IP del empleado

SELECT DISTINCT user, host FROM mysql.user WHERE user='empleado_sospechoso';

Analizar queries ejecutadas en período crítico

SELECT timestamp, user, query_text
FROM general_log
WHERE user='empleado_sospechoso'
AND timestamp BETWEEN '2025-03-10' AND '2025-03-15'
ORDER BY timestamp;

Buscar exportaciones o SELECT masivos

SELECT * FROM general_log
WHERE query_text LIKE '%SELECT%clientes%'
AND query_text NOT LIKE '%WHERE%'  -- Sin filtros = extracción completa
AND user='empleado_sospechoso';

Verificar volumen de datos extraídos

SELECT DATE(timestamp) as fecha, COUNT(*) as num_queries
FROM general_log
WHERE user='empleado_sospechoso'
GROUP BY DATE(timestamp);

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)

→ Conclusión pericial: Extracción completa de base de datos comercial

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:

Analizar logs de aplicación web

[2025-03-20 03:45:12] 192.168.1.100 - SQL: SELECT * FROM productos WHERE id='1' OR '1'='1'
[2025-03-20 03:45:23] 192.168.1.100 - SQL: SELECT * FROM productos WHERE id='1' UNION SELECT NULL,NULL,NULL--
[2025-03-20 03:47:01] 192.168.1.100 - SQL: SELECT * FROM productos WHERE id='1' UNION SELECT username,password,email FROM usuarios--

Reconstruir ataque exitoso
- Identificar payload que funcionó
- Determinar qué datos fueron extraídos
- Calcular alcance (número de registros comprometidos)
Rastrear origen del atacante
- IP de origen (puede ser proxy/VPN)
- User-Agent, headers HTTP
- Timing de ataques (automatizado vs manual)

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:

Analizar transaction log (binlog)

mysqlbinlog /var/log/mysql/mysql-bin.000456 | grep -i UPDATE | grep facturas

Identificar UPDATEs anómalos

-- Facturas modificadas después de cierre contable
UPDATE facturas SET importe=50000 WHERE id=12345 AND fecha='2024-12-31';

Reconstruir valores originales
- Uso de binlog para rollback conceptual
- Comparar con backups anteriores
- Identificar usuario que realizó modificación

Timeline de modificaciones

2025-01-15 23:45:12 - Usuario: admin_contable - UPDATE facturas SET importe=50000 WHERE id=12345
2025-01-15 23:45:34 - Usuario: admin_contable - UPDATE facturas SET importe=35000 WHERE id=12346
2025-01-15 23:46:01 - Usuario: admin_contable - DELETE FROM audit_log WHERE fecha='2025-01-15'

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

Deshabilitar rotación de logs

-- MySQL: Detener rotación automática
FLUSH LOGS;
SET GLOBAL max_binlog_size = 1073741824;  -- 1GB (evita rotación)

-- PostgreSQL: Aumentar retención WAL
ALTER SYSTEM SET wal_keep_size = '10GB';

Crear copias forenses de logs

# Calcular hash SHA-256 antes de copiar
sha256sum /var/log/mysql/mysql-bin.* > hashes_originales.txt

# Copiar logs a ubicación segura
cp -a /var/log/mysql/* /evidencia/logs_mysql/

# Verificar hash tras copia
cd /evidencia/logs_mysql/
sha256sum -c /evidencia/hashes_originales.txt

Exportar estado actual de bases de datos

# Dump completo con timestamps
mysqldump --all-databases --single-transaction --flush-logs > backup_forense_20250326.sql

# Calcular hash
sha256sum backup_forense_20250326.sql > backup_hash.txt

Documentar configuración del servidor

-- MySQL: Exportar configuración de logging
SHOW VARIABLES LIKE '%log%';
SHOW VARIABLES LIKE '%audit%';

-- PostgreSQL
SHOW log_statement;
SHOW log_min_duration_statement;

NUNCA Trabajar sobre Logs Originales

Los logs SQL deben ser copiados inmediatamente a ubicación forense con verificación de hash. Cualquier análisis debe realizarse sobre las copias, manteniendo los originales intactos para contraperitaje.

Limitaciones del Análisis SQL Forense

❌ Limitación 1: Logs No Habilitados

Problema: Muchos servidores SQL NO tienen logging habilitado por defecto (impacto en performance)

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.

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

Artículos relacionados:

Query SQL Forense

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

Marco de Aplicación

¿Dónde Se Encuentran las Queries SQL?

1. Logs del Servidor de Base de Datos

2. Logs de Aplicación

3. Caché de Queries

4. Binlog / Transaction Log

Volatilidad de la Evidencia

Técnicas Forenses de Análisis SQL

1. Análisis de Inyecciones SQL

2. Rastreo de Accesos No Autorizados

3. Detección de Extracción Masiva

4. Análisis de Modificaciones/Borrados

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

Caso 2: Inyección SQL en E-commerce

Caso 3: Modificación Fraudulenta de Registros Contables

Preservación de Evidencia SQL

Protocolo de Preservación Inmediata

NUNCA Trabajar sobre Logs Originales

Limitaciones del Análisis SQL Forense

❌ Limitación 1: Logs No Habilitados

❌ Limitación 2: Logs Ya Rotados

❌ Limitación 3: Queries Ofuscadas

❌ Limitación 4: Accesos Directos a Archivos

Conclusión

Preguntas Frecuentes

¿Qué se puede detectar con análisis forense de queries SQL?

¿Dónde se almacenan los logs de queries SQL?

¿Cuánto tiempo se conservan los logs SQL?

Términos Relacionados

Perito Informático

Evidencia Digital

Análisis Forense Digital

¿Necesitas un peritaje forense?