Parte: 9 — Forense digital y respuesta a incidentes · Fuente: SANS FOR500 y documentación de formatos de navegador/correo ⏱️ Duración estimada: 120 min · Nivel: Intermedio
Aprender a extraer y analizar actividad web y de correo: historial, cookies, descargas, caché y sesiones de navegadores (Chrome, Firefox, Edge), y encabezados, adjuntos y trazabilidad de mensajes. Al terminar podrás reconstruir actividad observable y analizar la ruta confiable y autenticación de un correo sospechoso.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Bases de datos de navegador | Historial, cookies, descargas |
| 2 | Chrome/Edge (History, Cookies) | Formato SQLite dominante |
| 3 | Firefox (places.sqlite) | Estructura propia |
| 4 | Caché y sesiones | Contenido y pestañas abiertas |
| 5 | Formatos de correo (PST, OST, MBOX, EML) | Dónde vive el correo |
| 6 | Encabezados de correo | Reconstruir la ruta declarada y sus límites |
| 7 | SPF/DKIM/DMARC | Interpretar autenticación y alineación de dominios |
| 8 | Adjuntos y phishing | Vector de entrada común |
Navegadores y correo mezclan contenido local, sincronizado y remoto. Historial, cookies, caché, descargas y sesiones dependen de perfil y versión; un URL en historial no prueba lectura consciente. En correo, cabeceras registran una cadena de transporte, pero campos presentados al usuario pueden falsificarse.
Se preserva mensaje original en su formato, no solo captura de pantalla. Received se lee de abajo hacia arriba con cautela; SPF, DKIM y DMARC expresan controles diferentes y resultados ligados al receptor. Un adjunto se hashea y analiza en copia. Para navegador se relacionan descarga, Mark-of-the-Web, archivo y ejecución antes de afirmar compromiso.
Chrome, Edge y Firefox distribuyen actividad entre bases SQLite, archivos de sesión, caché y preferencias. Copiar solo History puede omitir transacciones pendientes en archivos -wal y -shm; abrir el navegador puede escribir nuevas visitas, sincronizar datos o rotar sesiones. Se documentan usuario, perfil, versión, estado del proceso y método de copia, y se analiza un duplicado coherente del conjunto. La ubicación del archivo orienta, pero la estructura y la época temporal se verifican según producto y versión.
Una URL puede aparecer por navegación consciente, redirección, precarga, sincronización o recurso embebido. Una cookie indica que un navegador almacenó datos para un dominio, no que el titular de la cuenta autenticó personalmente. La interpretación mejora al relacionar visita, transición, descarga, caché, DNS, proxy y ejecución en el endpoint.
RFC 5322 define la sintaxis del mensaje de Internet, mientras MIME estructura cuerpos y adjuntos. El .eml original conserva campos que una captura de pantalla pierde. Cada servidor de transporte suele anteponer un campo Received, por eso el análisis comienza normalmente en el salto inferior confiable y avanza hacia arriba; aun así, los campos anteriores al primer servidor administrado por una parte confiable pueden haber sido proporcionados por el emisor.
Se separan From visible, Return-Path, dominio de DKIM, Message-ID, fechas y Authentication-Results. La IP hallada en la cadena puede identificar un relé o proveedor, no el dispositivo de la persona. Los adjuntos se extraen sin ejecución, conservando nombre MIME, tipo declarado, tipo real, hash y relación con el mensaje.
SPF autoriza hosts para el dominio usado en la identidad del sobre; DKIM verifica una firma y las partes cubiertas del mensaje; DMARC evalúa alineación del dominio visible con SPF o DKIM y aplica una política publicada. Un fail es evidencia de un resultado de autenticación en un receptor concreto, no prueba universal de intención maliciosa. Un correo puede pasar autenticación y seguir siendo phishing si usa un dominio controlado por el atacante o una cuenta legítima comprometida.
La conclusión útil no es solo «el mensaje era sospechoso», sino qué ocurrió después: entrega, apertura inferida, visita, descarga y ejecución. Cada paso exige su propio artefacto y nivel de certeza.
Received: campos agregados durante el transporte. Característica: se examinan desde el primer salto confiable y no todos poseen igual confianza.Un .eml presenta como remitente al área financiera. El primer Received confiable muestra entrega desde un servicio externo; SPF falla para la identidad del sobre, DKIM no existe y DMARC falla por falta de alineación. Esto sustenta suplantación del dominio, pero aún no demuestra que el usuario actuó. El analista extrae la URL, encuentra una visita en el perfil y una descarga con nombre de factura. El hash del archivo coincide con el objeto visto por el proxy y, minutos después, un artefacto del endpoint apoya su ejecución.
La narrativa conserva la separación: los encabezados explican autenticación y transporte; el navegador apoya visita y descarga; el endpoint apoya ejecución. Si DMARC hubiera pasado, no se descartaría el phishing: se evaluaría dominio parecido, cuenta comprometida o contenido engañoso.
Dominas la clase cuando adquieres un perfil sin alterar su estado lógico, incluyes archivos auxiliares de SQLite cuando corresponda, conviertes tiempos conservando su época, analizas un mensaje desde el primer salto confiable, explicas SPF/DKIM/DMARC por separado y correlacionas correo, navegación, descarga y ejecución sin atribuir más de lo que cada artefacto permite.
DB Browser for SQLite, herramientas de Eric Zimmerman, Hindsight (Chrome), nirsoft BrowsingHistoryView.libpff (PST), readpst, un visor de EML, y análisis manual de encabezados.Usa tu propio perfil de navegador y correos propios.
%LOCALAPPDATA%\Google\Chrome\User Data\Default\History.sql
SELECT url, title, visit_count, last_visit_time FROM urls ORDER BY last_visit_time DESC;
sql
SELECT url, title, visit_count FROM moz_places ORDER BY last_visit_date DESC;
.eml): abre los encabezados e identifica desde abajo el primer salto administrado por infraestructura confiable; separa relé observado de origen del usuario.Authentication-Results para ver el resultado de SPF, DKIM y DMARC.
- Un spf=fail o dkim=fail con dominio suplantado indica spoofing.Received y marca desde qué salto puede confiarse según la infraestructura disponible.Authentication-Results.Analiza un correo sospechoso propio, determina si la evidencia sustenta suplantación de dominio o requiere otra hipótesis, identifica el primer salto confiable y los resultados de SPF/DKIM/DMARC, y correlaciona una URL con artefactos del navegador.
Criterio de aceptación: reportas (a) el primer salto confiable y los límites para atribuir origen, (b) identidad y resultados evaluados por SPF/DKIM/DMARC, y (c) si los artefactos son compatibles con una visita o descarga, sin atribuir intención del usuario solo desde historial.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
database is locked |
El navegador está abierto. Trabaja sobre una copia con el navegador cerrado. |
| Timestamps sin sentido | Épocas distintas (WebKit vs. Unix). Convierte con la fórmula correcta. |
Encabezados Received confusos |
Léelos de abajo hacia arriba; los de arriba pueden estar falsificados. |
| SPF pasa pero igual es phishing | SPF valida el sobre, no el From visible. Revisa DKIM y DMARC. |
| Adjunto peligroso | Nunca lo ejecutes. Solo hashea y analiza en aislamiento. |
❓ ¿Por qué timestamps raros en Chrome? Usa la época WebKit: microsegundos desde el 1 de enero de 1601. Hay que convertirla.
❓ ¿SPF suficiente contra spoofing?
No. SPF valida el remitente del sobre (envelope), no el From que ve el usuario. DMARC alinea ambos; revísalo siempre.
❓ ¿Puedo recuperar correo borrado? A veces sí desde PST/OST (elementos recuperables) o desde el espacio no asignado con carving.
❓ ¿El modo incógnito deja rastro? En disco casi no, pero puede quedar en memoria, DNS caché y logs del proxy o del servidor.
From visible.Clase 209 — Análisis de línea de tiempo (timeline)