Navegadores, correo y sincronización en la nube · Lección 3 de 6
Caché, navegación privada y rastros que perduran
13 min de lectura
Las lecciones 4.1 y 4.2 examinan las bases de datos del historial. Esta lección aborda la caché del navegador, que conserva copias de lo que realmente se entregó, y la navegación privada, que elimina el historial y la caché, pero no los rastros que conserva el resto de Windows. La tarea del examinador es saber qué rastros permanecen, dónde encontrarlos y hasta dónde permiten llegar con un hallazgo.
Qué contiene la caché y por qué importa
Un navegador almacena copias de páginas, imágenes, scripts, hojas de estilo y otros contenidos descargados para poder mostrarlos de nuevo sin volver a obtenerlos. Cada entrada de caché conserva la clave (básicamente, la URL), el propio contenido y los encabezados de respuesta del servidor, como Date (cuándo envió el servidor la respuesta), Last-Modified, Content-Type, Content-Length y ETag, además de las horas que registra el navegador según el reloj local. Esto proporciona al examinador tres elementos que la base de datos del historial no ofrece: el contenido que vio el usuario, pruebas de que ese contenido llegó a este perfil del navegador y una marca de tiempo del reloj del servidor.
El encabezado Date lo escribe el servidor web, que normalmente está sincronizado, por lo que resulta útil como reloj externo; una respuesta servida desde una CDN o una caché de proxy conserva su Date original, y un encabezado Age indica entonces su antigüedad. Compárelo con las horas locales de la misma entrada para medir el desfase del reloj del dispositivo (lección 3.5). Last-Modified proporciona un límite inferior: el contenido no puede haberse entregado antes de su última modificación en el servidor.
Caché de Chromium
Chrome guarda su caché HTTP en %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cache\Cache_Data; Edge utiliza la misma estructura bajo %LOCALAPPDATA%\Microsoft\Edge\User Data\<profile>. El formato en disco varía según la plataforma y la versión. Las versiones recientes de Chrome en Windows utilizan el formato blockfile en Cache_Data:
| Archivo | Contenido |
|---|---|
index | Tabla hash de direcciones de entradas; firma mágica 0xC103CAC3 |
data_0 | Bloques de 36 bytes: clasificaciones, lista de entradas usadas menos recientemente con las horas de último uso |
data_1 | Bloques de 256 bytes: registros de entradas con clave, hora de creación y direcciones de flujos, y datos pequeños |
data_2, data_3 | Bloques de 1.024 bytes y 4.096 bytes: encabezados y cuerpos de hasta 16 KB |
f_XXXXXX | Archivos independientes para flujos de más de 16 KB, como f_0001a3 |
Cada entrada tiene un flujo 0 (la información de la respuesta HTTP analizada, incluidos los encabezados) y un flujo 1 (el cuerpo, a menudo todavía comprimido con gzip o Brotli tal como se envió). Chromium almacena las horas como microsegundos desde 1601-01-01 UTC. En Android, Linux, ChromeOS y macOS, Chromium utiliza de forma predeterminada el formato simple cache: un archivo por entrada llamado <16 hex digits>_0, con archivos opcionales _1 y _s y una carpeta index-dir.
Desde Chrome 86, la caché HTTP está particionada por sitio, por lo que las claves pueden comenzar con un prefijo como 1/0/_dk_ seguido del sitio de nivel superior que cargó el recurso. Ese prefijo indica para qué página se cargó una imagen o un script de terceros.
A menudo se confunden con la caché dos carpetas adyacentes. Code Cache (subcarpetas js y wasm) contiene JavaScript y WebAssembly compilados, con la URL del script como clave: demuestra que se ejecutaron los scripts de un sitio, no qué se mostró. GPUCache contiene sombreadores gráficos compilados y tiene poco valor probatorio.
cache2 de Firefox
Firefox 32 y las versiones posteriores utilizan el formato cache2 en el perfil local (no en el itinerante): %LOCALAPPDATA%\Mozilla\Firefox\Profiles\<profile>\cache2\entries. Cada entrada es un archivo cuyo nombre es el hash SHA-1 de su clave, de 40 dígitos hexadecimales. El archivo contiene primero el contenido y después los metadatos: un hash de 4 bytes de los metadatos, los hashes de los fragmentos (2 bytes por fragmento de 256 KiB), un encabezado (versión, número de recuperaciones, última recuperación, última modificación, frecuencia y recencia, hora de caducidad, tamaño de la clave, indicadores), la clave que termina con la URL (precedida de indicadores breves como a,:) y elementos con nombre como request-method y response-head, que contiene los encabezados completos de la respuesta. Los últimos 4 bytes son un desplazamiento big-endian al inicio de los metadatos, que equivale a la longitud del contenido. Las horas del encabezado son segundos Unix de 32 bits, en big-endian. cache2\index resume todas las entradas (hashes, frecuencia y recencia, indicadores) y no contiene URL.
Ejemplo resuelto: lectura de una entrada de cache2
Un archivo de entrada tiene una longitud de 15.240 bytes. Sus últimos 4 bytes son 00 00 3A 98 = 0x3A98 = 15.000, por lo que los bytes 0 a 14.999 son el contenido en caché (comienzan por 89 50 4E 47, un PNG) y los metadatos empiezan en el desplazamiento 15.000. El campo de última recuperación contiene 69 B5 60 85 = 1.773.494.405 segundos desde 1970-01-01 = 2026-03-14T13:20:05Z. El elemento response-head contiene Date: Sat, 14 Mar 2026 13:20:03 GMT. El reloj local y el del servidor coinciden con una diferencia de 2 segundos, lo que encaja con un tiempo de transferencia normal, por lo que no se necesita corregir el desfase para este período.
Herramientas y limitaciones
Ejemplos gratuitos: ChromeCacheView y MozillaCacheView de NirSoft muestran la URL, el tipo de contenido, la hora del servidor y la hora de última modificación, y exportan el contenido; Plaso dispone de analizadores chrome_cache y firefox_cache2; Hindsight analiza la caché de Chromium junto con el historial. Sea cual sea la herramienta, abra una entrada manualmente y confirme las horas.
Una caché tiene límites. Los navegadores determinan su tamaño a partir de la configuración o del espacio libre en disco y eliminan las entradas usadas menos recientemente; las respuestas marcadas con Cache-Control: no-store, habituales en páginas bancarias y de inicio de sesión, nunca se escriben; y el usuario puede borrar la caché. La ausencia de una entrada de caché no demuestra que una página no se haya visitado.
Navegación privada
El modo Incógnito de Chrome, InPrivate de Edge y la navegación privada de Firefox funcionan de la misma manera en principio. El navegador no escribe el historial, la lista de descargas, los datos de formularios ni las entradas de búsqueda; las cookies y los datos de los sitios residen en la memoria y se descartan cuando se cierra la última ventana privada; y la caché HTTP se conserva en la memoria en lugar de en Cache_Data o cache2. Los tres conservan los archivos descargados en una ventana privada y los marcadores (favoritos) creados en ella, porque se almacenan fuera de la sesión privada. El modo privado protege frente al siguiente usuario del perfil, no frente al sistema operativo, la red ni los sitios visitados.
Por tanto, los rastros que perduran se encuentran fuera de las propias bases de datos del navegador:
| Rastro | ¿Perdura tras la navegación privada? | Dónde |
|---|---|---|
| Visitas, cookies, datos de formularios | No | No se escriben en History, Cookies ni places.sqlite |
| Caché HTTP | No (solo en memoria) | No se escribe en Cache_Data ni cache2 |
| Archivo descargado | Sí | Carpeta de descargas; $MFT y $UsnJrnl (módulo 1) |
| ADS Zone.Identifier | Sí; Chrome Incógnito omite la URL | Flujo del archivo descargado (lección 1.4) |
| Marcador creado | Sí | Archivo Bookmarks o places.sqlite |
| Ejecución del navegador | Sí, solo la ejecución | Prefetch, BAM (lección 2.3) |
| Bytes de red por aplicación | Sí, totales por hora | SRUDB.dat de SRUM (lección 2.8) |
| Descarga abierta | Sí | Archivos LNK y Jump Lists (lección 2.4) |
| Nombres DNS resueltos | Hasta que venza el TTL o se reinicie el sistema | Caché del cliente DNS en memoria |
| URL y fragmentos de páginas | Posiblemente | RAM, pagefile.sys, hiberfil.sys (módulo 5) |
| Conexiones | Sí, fuera del equipo | Registros de proxy, firewall, servidor DNS y router |
| Actividad de la cuenta | Sí, si el usuario inició sesión | Registros propios de la cuenta en línea (lección 4.5) |
Puntos que deben aplicarse con precisión:
- Zone.Identifier. Para una descarga en una ventana normal, Chromium en Windows 10 y 11 escribe
HostUrlyReferrerUrl. Para una descarga en modo Incógnito, no transmite la URL: el flujo conservaZoneId=3, peroHostUrlcontiene el valor de sustituciónabout:internetyReferrerUrlestá ausente. Confirme el comportamiento de la versión de su caso mediante una descarga de prueba. - Prefetch y BAM demuestran que se ejecutó
chrome.exeofirefox.exe, no que se utilizara una ventana privada. Prefetch no registra argumentos de línea de comandos, por lo que un modificador como--incognitosolo aparece donde se registran las líneas de comandos, por ejemplo, en el evento de seguridad 4688 con la auditoría de línea de comandos habilitada; una ventana abierta con Ctrl+Shift+N en un navegador en ejecución no se inicia con ese modificador. - Caché del cliente DNS. En un sistema en funcionamiento,
ipconfig /displaydnsenumera los nombres que resolvió el cliente DNS de Windows; es volátil y desaparece tras un reinicio. Un navegador que resuelve los nombres por sí mismo, como Chrome con su resolvedor integrado habilitado, puede omitir esta caché, y uno que utilice DNS sobre HTTPS también evita los registros del servidor DNS local. - Los registros de red suelen mostrar nombres de host, no URL completas: para HTTPS, un proxy sin interceptación registra el host y el puerto de la solicitud
CONNECT, no la ruta.
Borrar el historial no es navegar en privado
Borrar el historial elimina filas que se habían escrito; la navegación privada nunca las escribe. La diferencia importa porque las filas eliminadas pueden perdurar. En SQLite genérico, una fila eliminada queda en el espacio libre de una página o en una página de la lista de páginas libres hasta que ese espacio se reutiliza o se compacta la base de datos, pero Chromium y Firefox compilan SQLite con la eliminación segura activada, que sobrescribe con ceros el contenido eliminado en el archivo principal. Aun así, pueden quedar copias en el diario de reversión (History-journal en Chromium) o en el registro de escritura anticipada (places.sqlite-wal en Firefox), en las instantáneas de volumen y en los registros de $UsnJrnl de los archivos de caché eliminados al borrar los datos. La función de borrado del navegador no modifica en absoluto SRUM ni Prefetch.
Cómo redactar un hallazgo a partir de rastros indirectos
Cuando solo existan rastros indirectos, indique cada fuente y sus limitaciones, y no afirme como hecho que se utilizó una ventana privada a menos que algo lo demuestre. Una redacción adecuada sería: "Los rastros son compatibles con la navegación a transfer.example.com en una ventana privada; el propio historial del navegador no contiene ningún registro de ese sitio". A continuación, enumere las alternativas que comprobó: otro navegador o perfil, historial borrado u otro dispositivo.
Ejemplo resuelto: un recibo sin historial
Una recopilación de triaje de Windows 11 de otro caso, para el usuario lferraz, muestra:
Historyde Chrome: ninguna visita ni descarga detransfer.example.com. La visita más antigua de la base de datos es de 2026-04-21T15:02:41Z.C:\Users\lferraz\Downloads\upload-receipt.pdf, creado según $SI el 2026-04-21T13:41:07Z, con Zone.IdentifierZoneId=3,ReferrerUrl=https://transfer.example.com/upload/done,HostUrl=https://transfer.example.com/r/8f3a/upload-receipt.pdf.- Datos de uso de red de SRUM para
chrome.exe, usuariolferraz, intervalo que termina a las 14:00:00Z (fila anterior: 13:00:00Z): BytesSent 734.003.200, BytesRecvd 9.437.184. Cache_Datasolo contieneindexy archivos nuevos dedata_0adata_3sin entradas, creados el 2026-04-21T15:01:58Z.
Cálculo. 734.003.200 ÷ 1.048.576 = 700 MiB enviados y 9.437.184 ÷ 1.048.576 = 9 MiB recibidos entre las 13:00:00Z y las 14:00:00Z, una proporción de aproximadamente 78:1 que encaja con una carga. La descarga de las 13:41:07Z se encuentra dentro de ese intervalo.
Qué puede concluirse. Se guardó un archivo a las 13:41:07Z desde una URL de transfer.example.com, después de una página de ese sitio (/upload/done). chrome.exe, bajo el usuario lferraz, envió unos 700 MiB durante esa misma hora.
Qué debe explicar la hipótesis de navegación privada. El HostUrl real contradice la hipótesis de una descarga en Chrome Incógnito, que habría registrado about:internet. Una caché recreada a las 15:01:58Z y un historial que comienza a las 15:02:41Z encajan con un borrado de datos de navegación poco antes de las 15:02, no con la navegación privada, que deja intacta la caché normal. Próximos pasos: recuperar mediante carving páginas antiguas de History en History-journal, el espacio no asignado y las instantáneas de volumen; comprobar en $UsnJrnl si hay archivos f_ eliminados alrededor de las 15:01Z; y examinar Edge y otros perfiles de Chrome, porque otro navegador basado en Chromium podría haber escrito el mismo flujo.
Qué no puede concluirse. Ni SRUM ni Zone.Identifier indican qué se cargó ni que los 700 MiB se enviaran a transfer.example.com; SRUM no contiene destinos. Para establecer ese vínculo se necesitan registros de proxy o DNS de la red.
Enfoque del examen: Prepárese para leer la URL, el encabezadoDateo el tipo de contenido de una entrada de caché, o para calcular el desplazamiento de los metadatos de Firefox cache2 a partir de los últimos 4 bytes. Debe poder elegir qué artefactos perduran tras la navegación privada, informar de unHostUrlo de un recuento de bytes de SRUM y reconocer que unHostUrlreal en una descarga de Chromium no encaja con el modo Incógnito. Las preguntas pueden contrastar el historial borrado (con copias posiblemente recuperables) con la navegación privada (sin datos escritos).
Puntos clave
- Las entradas de caché contienen el contenido, la clave URL y los encabezados de respuesta del servidor; el encabezado
Datees un reloj externo para comprobar desfases. - Chrome en Windows utiliza
Cache_Datacon formato blockfile (index, dedata_0adata_3, archivosf_); Firefox 32+ utiliza un archivo encache2\entriespor entrada, con los metadatos después del contenido. - Las cachés tienen un tamaño limitado, omiten las respuestas
no-storey pueden borrarse, por lo que la ausencia de una entrada no demuestra nada. - La navegación privada no escribe historial, cookies, datos de formularios ni caché en disco, pero permanecen las descargas, los marcadores, Prefetch, BAM, SRUM, los archivos LNK, la memoria y los registros de red.
- Las descargas de Chrome Incógnito llevan
ZoneId=3conHostUrl=about:internet; una URL real apunta a otra explicación. - La eliminación segura sobrescribe con ceros el historial borrado en la base de datos principal, pero este puede perdurar en diarios, archivos WAL e instantáneas de volumen; la navegación privada no deja nada allí.