// ANÁLISIS FORENSE DE ARCHIVOS .HAR
// Anatomía de sesiones HTTP/HTTPS con filosofía LO
// Anatomía de sesiones HTTP/HTTPS con filosofía LO
0x00 // INTRODUCCIÓN
Los archivos .HAR (HTTP Archive) son el registro forense completo de cada transacción HTTP/HTTPS que realiza tu navegador.
Para un analista de ciberseguridad o helpdesk técnico, este artefacto es equivalente a la caja negra de un avión estrellado, contiene la verdad absoluta sobre qué ocurrió, cuándo, y porqué.
Este post pretende ser una guía sin mucha paja, yendo al grano, abre tus sentidos y practica.
CONTEXTOS
• Helpdesk: Diagnóstico de errores de autenticación, caché, redirecciones
• Blue Team: Detección de C2, exfiltración de datos, token leakage
• DFIR: Reconstrucción de sesiones comprometidas
• DevSecOps: Auditoría de flujos OAuth/OIDC
• Helpdesk: Diagnóstico de errores de autenticación, caché, redirecciones
• Blue Team: Detección de C2, exfiltración de datos, token leakage
• DFIR: Reconstrucción de sesiones comprometidas
• DevSecOps: Auditoría de flujos OAuth/OIDC
0x01 // FIRMAS DIGITALES EN LA PESTAÑA NETWORK
EJERCICIO 1: ERROR 403
Escenario típico: Un usuario me reporta "No puedo entrar a la Intranet, me sale un error de acceso".
// Protocolo de diagnóstico
1. Abrir DevTools (F12) → Pestaña Network
2. Activar Preserve Log (CRÍTICO: evita pérdida de trazas en redirecciones)
3. Refrescar página (F5)
4. Buscar línea en ROJO
1. Abrir DevTools (F12) → Pestaña Network
2. Activar Preserve Log (CRÍTICO: evita pérdida de trazas en redirecciones)
3. Refrescar página (F5)
4. Buscar línea en ROJO
| Código HTTP | Interpretación | Vector de Análisis |
|---|---|---|
| 401 | Falta identidad válida | Revisar Authorization header (Bearer token ausente/expirado) |
| 403 | Identidad reconocida, permiso denegado | Usuario autenticado pero sin permisos (revisar grupos AD/Okta) |
LOCALIZACIÓN DE REQUEST HEADERS
// Flujo de inspección forense
1. F12 → Network → Generar tráfico (reproducir error)
2. Clic en petición roja (tipo Fetch/XHR)
3. Panel lateral → Pestaña Headers
4. Scroll down → Sección Request Headers
1. F12 → Network → Generar tráfico (reproducir error)
2. Clic en petición roja (tipo Fetch/XHR)
3. Panel lateral → Pestaña Headers
4. Scroll down → Sección Request Headers
CAMPOS CRÍTICOS EN REQUEST HEADERS
| Header | Propósito | Diagnóstico Helpdesk | Vector Ciberseguridad |
|---|---|---|---|
| Authorization | Token JWT/Bearer | Si vacío/null → sesión perdida | Robo de token (XSS), expiración forzada |
| Cookie | Sesión persistente | Buscar JSESSIONID, ASP.NET_SessionId | Session hijacking si no tiene Secure/HttpOnly |
| User-Agent | Fingerprint del cliente | Confirmar versión de navegador reportada | UA obsoleto = vector de explotación RCE |
| Referer | Página de origen | Servidores corporativos validan origen interno | CSRF si referer no validado |
| X-CSRF-Token | Anti-falsificación | Si ausente en POST/PUT → 403 legítimo | Sistema protegiendo contra CSRF |
REFLEXIÓN DEL ANALISTA
"Para el usuario, el sistema no funciona. Para mi, el sistema está siendo demasiado eficiente protegiéndose de un usuario que no entiende... o de una sesión comprometida."
"Para el usuario, el sistema no funciona. Para mi, el sistema está siendo demasiado eficiente protegiéndose de un usuario que no entiende... o de una sesión comprometida."
0x02 // CACHÉ
Escenario típico: "Ayer funcionaba, hoy me sigue saliendo el error antiguo" (Se subió parche pero usuario sigue viendo versión obsoleta).
// Protocolo de limpieza quirúrgica
1. DevTools abierto → Network → Activar Disable Cache
2. Refrescar (F5)
3. Si error desaparece → Caché corrupta confirmada
4. Hard Refresh: Mantener pulsado botón recarga → "Vaciar caché y recargar forzado"
1. DevTools abierto → Network → Activar Disable Cache
2. Refrescar (F5)
3. Si error desaparece → Caché corrupta confirmada
4. Hard Refresh: Mantener pulsado botón recarga → "Vaciar caché y recargar forzado"
VENTAJA
Hard Refresh limpia la entropía sin borrar contraseñas guardadas del usuario. Es la solución quirúrgica vs. el reset de "borrar todo el historial".
Hard Refresh limpia la entropía sin borrar contraseñas guardadas del usuario. Es la solución quirúrgica vs. el reset de "borrar todo el historial".
0x03 // ERRORES DE DNS Y CONECTIVIDAD
Si el error es net::ERR_NAME_NOT_RESOLVED o net::ERR_CONNECTION_TIMED_OUT:
// Análisis de conectividad
Ni siquiera llegamos al servidor → No busques códigos 4xx/5xx
El navegador no pudo resolver el dominio o establecer conexión TCP
Ni siquiera llegamos al servidor → No busques códigos 4xx/5xx
El navegador no pudo resolver el dominio o establecer conexión TCP
| Error en Console | Traducción Técnica | Causa en Entorno Corporativo |
|---|---|---|
| ERR_NAME_NOT_RESOLVED | DNS no resuelve el dominio | Archivo hosts secuestrado o DNS sinkholing de dominio malicioso |
| ERR_CONNECTION_TIMED_OUT | Timeout TCP | Firewall bloqueando puerto o servidor caído |
| ERR_CONNECTION_REFUSED | Puerto cerrado | Servicio no escucha en ese puerto o IPS bloqueando |
VECTOR CIBERSEGURIDAD
Si esto ocurre solo con una URL específica, el archivo C:\Windows\System32\drivers\etc\hosts podría estar secuestrado (malware) o el DNS corporativo está haciendo Sinkholing de esa dirección por ser maliciosa (EDR/proxy actuando).
Si esto ocurre solo con una URL específica, el archivo C:\Windows\System32\drivers\etc\hosts podría estar secuestrado (malware) o el DNS corporativo está haciendo Sinkholing de esa dirección por ser maliciosa (EDR/proxy actuando).
0x04 // TABLA DE ERRORES TÍPICOS
| Error | Traducción Técnica | Causa Corporativa | Acción Inmediata |
|---|---|---|---|
| 401 | Falta identidad | Usuario no logueado o SSO falló | Revisar Authorization header |
| 403 | Permiso denegado | Falta de privilegios en perfil | Auditar grupos AD/Okta |
| 500 | Colapso del servidor | BD caída o bug backend | NO es culpa del usuario |
| 503 | Servicio no disponible | Servidor saturado/mantenimiento | Esperar o escalar a Ops |
| CORS Error | Bloqueo origen cruzado | Sitio A pide datos a sitio B sin permisos | Firewall de navegador bloqueando por seguridad |
0x05 // NAVEGANDO LA CONSOLA DEV
SUB-PESTAÑA PREVIEW (VISTA PREVIA)
Formatea JSON para legibilidad humana.
Si el servidor devuelve un error de validación como por ejemplo "El formato del DNI es incorrecto", lo verás aquí.
PESTAÑA APPLICATION → STORAGE
Aquí reside la persistencia. Si el usuario "no puede mantener la sesión abierta":
- Cookies: Buscar cookie de sesión. Si tiene flags Secure y HttpOnly → Desarrollador hizo bien su trabajo. Si no → Riesgo de session hijacking.
- LocalStorage / SessionStorage: Aplicativos modernos guardan preferencias aquí. Borrar estos valores = solución quirúrgica sin borrar historial completo.
PESTAÑA CONSOLE
Aquí verás los fallos del navegador.
USO CIBERSEGURIDAD
Busca errores de CSP (Content Security Policy). Si ves mensajes en rojo bloqueando carga de script externo → Medida de seguridad activa impidiendo posible XSS.
Busca errores de CSP (Content Security Policy). Si ves mensajes en rojo bloqueando carga de script externo → Medida de seguridad activa impidiendo posible XSS.
USO HELPDESK
Error 404 en archivo .js o .css → Sitio web "mutilado", le falta parte de su cerebro.
Error 404 en archivo .js o .css → Sitio web "mutilado", le falta parte de su cerebro.
0x06 // ANÁLISIS DE ERRORES EN ROJO: UNCAUGHT TYPEERROR
1. ERROR DEL "NULL" (clientWidth)
Cannot read properties of null (reading 'clientWidth')
El código intenta medir el tamaño de algo (botón, imagen, menú) que no existe en la página.
// Causas comunes
• Navegador no soportado
• Extensión (ej: bloqueador de anuncios) eliminó elemento del DOM
• Script ejecutándose antes de que la página cargue completamente
• Navegador no soportado
• Extensión (ej: bloqueador de anuncios) eliminó elemento del DOM
• Script ejecutándose antes de que la página cargue completamente
2. ERROR DEL "MUTATIONOBSERVER"
parameter 1 is not of type 'Node'
- Error de lógica de ejecución.
- El sitio intenta "vigilar" cambios en una parte de la web que no se ha cargado correctamente.
- Cuando el DOM está inestable, las funciones de seguridad o validación de formularios podrían fallar → Estado impredecible.
LA CONSOLA COMO DETECTOR DE ANOMALÍAS
| Vector | Indicador | Interpretación |
|---|---|---|
| XSS Detection | Scripts cargando desde dominios extraños | Inyección de código malicioso |
| CSP Block | Error púrpura/rojo: "Refused to load script... CSP directive" | Éxito de seguridad, no error de helpdesk |
| Info Leakage | Mensajes console.log con objetos completos | Desarrolladores olvidaron quitar debug → Pueden exponer IDs, tokens, rutas internas |
0x07 // CÓDIGO 302: REDIRECCIONES Y BUCLES INFINITOS
El código 302 Found (Temporary Redirect) le dice al navegador: "Lo que buscas no está aquí, muévete a la dirección que te doy en la cabecera Location".
EL BUCLE DE REDIRECCIÓN INFINITO
// Síntoma clásico
Usuario atrapado en infinitos 302:
• Sitio A cree que estás logueado
• Sitio B dice que no
• Te devuelve al Sitio A → Loop infinito
Usuario atrapado en infinitos 302:
• Sitio A cree que estás logueado
• Sitio B dice que no
• Te devuelve al Sitio A → Loop infinito
Causas típicas:
- Reloj del sistema desincronizado (tokens con timestamp inválido)
- Cookies de terceros bloqueadas por navegador
- SSO fallando entre dominios
- ¿QUÉ BUSCAR EN RESPONSE HEADERS DEL 302?
Para confirmar que el login es exitoso, busca el campo Set-Cookie:
// Headers de autenticación exitosa (ejemplo Google)
Set-Cookie: SID=...; Domain=.google.com; Secure; HttpOnly
Set-Cookie: HSID=...; Domain=.google.com; Secure; HttpOnly
Set-Cookie: SAPISID=...; Domain=.google.com; Secure
Set-Cookie: SID=...; Domain=.google.com; Secure; HttpOnly
Set-Cookie: HSID=...; Domain=.google.com; Secure; HttpOnly
Set-Cookie: SAPISID=...; Domain=.google.com; Secure
DIAGNÓSTICO
Si ves esas cookies, el login es un éxito técnico. Si el usuario sigue sin poder entrar, el problema no es el "Logon", sino los permisos dentro de la aplicación.
Si ves esas cookies, el login es un éxito técnico. Si el usuario sigue sin poder entrar, el problema no es el "Logon", sino los permisos dentro de la aplicación.
0x08 // ANÁLISIS DE ARCHIVOS .HAR
El archivo .HAR es un JSON gigante que contiene TODA la información de cada transacción HTTP capturada.
GENERACIÓN DEL .HAR
// Exportación desde DevTools
1. F12 → Network
2. Reproducir escenario (navegar, login, error)
3. Click en icono ↓ (Export HAR...)
4. Guardar como .har
1. F12 → Network
2. Reproducir escenario (navegar, login, error)
3. Click en icono ↓ (Export HAR...)
4. Guardar como .har
ANÁLISIS CON POWERSHELL (LOTL)
# Cargar archivo .HAR como JSON
$har = Get-Content "archivo.har" -Raw | ConvertFrom-Json
# Extraer todos los códigos de estado HTTP
$har.log.entries | Select-Object @{Name="URL";Expression={$_.request.url}}, @{Name="Status";Expression={$_.response.status}}
# Filtrar solo errores 4xx y 5xx
$har.log.entries | Where-Object {$_.response.status -ge 400}
$har = Get-Content "archivo.har" -Raw | ConvertFrom-Json
# Extraer todos los códigos de estado HTTP
$har.log.entries | Select-Object @{Name="URL";Expression={$_.request.url}}, @{Name="Status";Expression={$_.response.status}}
# Filtrar solo errores 4xx y 5xx
$har.log.entries | Where-Object {$_.response.status -ge 400}
MAPEO DE END POINTS
Extrae todos los dominios únicos con los que el navegador contactó.
Select-String -Path "archivo.har" -Pattern '"url":\s*"https?://(?<domain>[^/"]+)' | ForEach-Object { $_.Matches.Groups['domain'].Value } | Sort-Object -Unique
VALOR SOC
Identificación de conexiones a C2 (Command & Control) ocultas en CDNs legítimas. Si aparece un dominio sospechoso → Whois rápido + TI lookup.
Identificación de conexiones a C2 (Command & Control) ocultas en CDNs legítimas. Si aparece un dominio sospechoso → Whois rápido + TI lookup.
0x09 // GOOGLE HAR ANALYZER: HERRAMIENTA DE GOOGLE ADMIN TOOLBOX
Herramienta visual de Google para análisis rápido de .HAR sin necesidad de scripts: https://toolbox.googleapps.com/apps/har_analyzer/
FASE 1
// Ejercicio con HTTPBin.org
1. Navegar a httpbin.org
2. F12 → Network → Activar Preserve Log
3. Visitar endpoints:
• /status/404 (error de cliente)
• /status/500 (colapso del servidor)
• /delay/3 (latencia de 3 segundos)
4. Exportar HAR
1. Navegar a httpbin.org
2. F12 → Network → Activar Preserve Log
3. Visitar endpoints:
• /status/404 (error de cliente)
• /status/500 (colapso del servidor)
• /delay/3 (latencia de 3 segundos)
4. Exportar HAR
FASE 2
| Panel | Pauta de Búsqueda | Diagnóstico |
|---|---|---|
| All Entries | Filas rojas/amarillas | Rojo al inicio = fallo de conexión. Rojo al final = script fallando post-carga |
| Time Wait (TTFB) | Ordenar por tiempo descendente | Wait > 5000ms = servidor con embolia de datos |
| Request/Response Headers | Header Server | Apache/2.2.15 = versión antigua, vulnerable a exploits conocidos |
| Cookies | Flags Secure y HttpOnly | Si faltan = riesgo de session hijacking |
| Payload Size | Archivos .png/.js > 2MB | Problema de rendimiento, no de red (diseñador gráfico) |
TABLA DE DIAGNÓSTICO RÁPIDO
| Si ves... | Significa que... | Acción de Analista |
|---|---|---|
| 401/403 | Usuario no tiene llaves | Revisar headers Authorization |
| Muchos 302 seguidos | Bucle de redirección | Borrar cookies (limpiar memoria del navegador) |
| Status 0 o (failed) | Bloqueo externo | Firewall o Antivirus del usuario cortó la conexión |
| Timing: mucho "Stalled" | Navegador esperando | Demasiadas peticiones simultáneas, PC saturado |
0x0A // ANÁLISIS FORENSE DE WORLDMONITOR.APP
Caso práctico basado en auditoría de una aplicación de monitorización de inteligencia geopolítica y OSINT que utiliza LLMs para análisis.
FASE 1: MAPEO DE INFRAESTRUCTURA Y TERCEROS
Objetivo: Identificar la cadena de suministro de datos (Supply Chain).
# Extracción de dominios únicos
$har = Get-Content "www.worldmonitor.app.har" -Raw | ConvertFrom-Json
$har.log.entries.request.url | ForEach-Object { ([System.Uri]$_).Host } | Sort-Object -Unique
$har = Get-Content "www.worldmonitor.app.har" -Raw | ConvertFrom-Json
$har.log.entries.request.url | ForEach-Object { ([System.Uri]$_).Host } | Sort-Object -Unique
HALLAZGO CRÍTICO
Verás openrouter.ai en la lista. Pregunta: ¿Por qué una app de monitorización contacta con un agregador de LLMs? → Dependencia crítica en terceros para análisis de inteligencia.
Verás openrouter.ai en la lista. Pregunta: ¿Por qué una app de monitorización contacta con un agregador de LLMs? → Dependencia crítica en terceros para análisis de inteligencia.
FASE 2: INYECCIÓN DE INTELIGENCIA (PAYLOAD ANALYSIS)
Objetivo: Ver la "verdad" que viaja por el cable, no la que muestra la UI.
Intercepción de respuestas de IA para auditoría de sesgo o desinformación. La UI puede presentar el contenido manipulado, pero el .HAR tiene la verdad cruda.
FASE 3: AUDITORÍA DE SEGURIDAD CLOUD (WAF/CDN)
Objetivo: Identificar protecciones y geolocalización del servidor.
# Extracción de headers Cloudflare
$har.log.entries | Where-Object { $_.request.url -like "*worldmonitor.app*" } | Select-Object -ExpandProperty response | Select-Object -ExpandProperty headers | Where-Object { $_.name -match "cf-cache-status|server" }
$har.log.entries | Where-Object { $_.request.url -like "*worldmonitor.app*" } | Select-Object -ExpandProperty response | Select-Object -ExpandProperty headers | Where-Object { $_.name -match "cf-cache-status|server" }
FINGERPRINTING DE INFRAESTRUCTURA
Busca header server: cloudflare → Servidor protegido por WAF. Headers adicionales: cf-ray (ID de petición), cf-cache-status (HIT/MISS).
Busca header server: cloudflare → Servidor protegido por WAF. Headers adicionales: cf-ray (ID de petición), cf-cache-status (HIT/MISS).
FASE 4: TIMING FORENSICS (TTFB & LATENCY)
Objetivo: Detectar cuellos de botella en la ingesta de datos de inteligencia (API).
# Calcular qué API externa tarda más
$har.log.entries | Sort-Object {$_.time} -Descending | Select-Object @{Name="URL";Expression={$_.request.url}}, time -First 5
$har.log.entries | Sort-Object {$_.time} -Descending | Select-Object @{Name="URL";Expression={$_.request.url}}, time -First 5
CRITICIDAD TEMPORAL
Si openrouter.ai tarda >200ms, la "alerta temprana" ya no es tan temprana.
Si openrouter.ai tarda >200ms, la "alerta temprana" ya no es tan temprana.
FASE 5: EXFILTRACIÓN DE SECRETOS (DATA LEAKAGE EN URLS)
Objetivo: Detectar tokens/API keys expuestas en URLs.
# Búsqueda de secretos en query strings
$har.log.entries.request.url | Select-String "(?i)(api_key|apikey|key|token)=([^&]+)" -AllMatches | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique
$har.log.entries.request.url | Select-String "(?i)(api_key|apikey|key|token)=([^&]+)" -AllMatches | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique
RIESGO CRÍTICO
Tokens en URLs quedan expuestos en:
• Logs del servidor web
• Historial del navegador
• Proxies corporativos
• Logs de firewall
→ Secretos comprometidos permanentemente
Tokens en URLs quedan expuestos en:
• Logs del servidor web
• Historial del navegador
• Proxies corporativos
• Logs de firewall
→ Secretos comprometidos permanentemente
FASE 6: AUDITORÍA DE COOKIES DE SESIÓN
Objetivo: Evaluar persistencia y seguridad de la sesión del analista (Ojo no funciona si no te autenticas).
# Extracción de cookies Set-Cookie con atributos de seguridad
$har.log.entries.response.headers | Where-Object { $_.name -eq "Set-Cookie" } | Select-Object -ExpandProperty value
$har.log.entries.response.headers | Where-Object { $_.name -eq "Set-Cookie" } | Select-Object -ExpandProperty value
RIESGO
Si HttpOnly es false, un XSS en la web de mapas puede robar la sesión del analista → Acceso completo a la plataforma de inteligencia.
Si HttpOnly es false, un XSS en la web de mapas puede robar la sesión del analista → Acceso completo a la plataforma de inteligencia.
0x0B // THREAT HUNTING: TOKEN LEAKAGE EN FLUJOS OAUTH/OIDC
Objetivo: Detectar fugas de tokens de sesión durante procesos de redirección de identidad (Ojo no funciona si no te autenticas)
METODOLOGÍA
// Flujo de análisis
[Escenario] Aplicación con flujo OAuth/OIDC
[Hipótesis] Los tokens podrían exponerse en cabeceras Location durante redirecciones 30x
[Acción LOTL] Filtrado automatizado con PowerShell sobre el .HAR
[Veredicto] Confirmar o descartar Token Leakage sin herramientas externas
[Escenario] Aplicación con flujo OAuth/OIDC
[Hipótesis] Los tokens podrían exponerse en cabeceras Location durante redirecciones 30x
[Acción LOTL] Filtrado automatizado con PowerShell sobre el .HAR
[Veredicto] Confirmar o descartar Token Leakage sin herramientas externas
AUTOMATIZACIÓN CON POWERSHELL
# Extracción de cabeceras Location en redirecciones 30x
$har.log.entries | Where-Object { $_.response.status -ge 300 -and $_.response.status -lt 400 } | ForEach-Object { $_.response.headers | Where-Object { $_.name -eq "Location" } | Select-Object -ExpandProperty value }
$har.log.entries | Where-Object { $_.response.status -ge 300 -and $_.response.status -lt 400 } | ForEach-Object { $_.response.headers | Where-Object { $_.name -eq "Location" } | Select-Object -ExpandProperty value }
CUADRO DE HALLAZGOS
| Paso | Evidencia | Análisis |
|---|---|---|
| 1. Proveedor de Identidad | POST a identitytoolkit.googleapis.com | Firebase Auth (Google) validando usuario |
| 2. Leak Crítico | Header Location con id_token en URL | JWT completo pasado como Query String (307) |
| 3. Vector de Exposición | JWT en URL | Queda en logs del servidor, historial navegador, proxies, firewalls |
PESADILLA DE SEGURIDAD
Pasar un JWT por URL (Query String) es un anti-pattern crítico. Ese token da acceso total a la cuenta del usuario y, al viajar en la URL, se guarda en texto plano en:
• Historial del navegador (persistente)
• Logs del servidor web (access.log)
• Firewall corporativo (URL logging)
• Proxies de red (interceptación)
• Herramientas de analytics (tracking de URLs)
COMPROMISO PERMANENTE DE SESIÓN
Pasar un JWT por URL (Query String) es un anti-pattern crítico. Ese token da acceso total a la cuenta del usuario y, al viajar en la URL, se guarda en texto plano en:
• Historial del navegador (persistente)
• Logs del servidor web (access.log)
• Firewall corporativo (URL logging)
• Proxies de red (interceptación)
• Herramientas de analytics (tracking de URLs)
COMPROMISO PERMANENTE DE SESIÓN
RECOMENDACIÓN
El id_token debe viajar SIEMPRE en:
• Header Authorization: Bearer [token]
• Body de POST
NUNCA en Query String de URL.
El id_token debe viajar SIEMPRE en:
• Header Authorization: Bearer [token]
• Body de POST
NUNCA en Query String de URL.
0x0C // CONCLUSIONES
"El diagnóstico es el arte de encontrar la diferencia entre lo que el sistema espera y lo que el usuario entrega."
FILTRO RÁPIDO DEL ANALISTA
| Si falla... | Ve a... | Busca... |
|---|---|---|
| La carga | Network | Filtrar Status: 4xx o 5xx |
| La lógica (botones que no hacen nada) | Console | Errores JavaScript (rojo vivo) |
| La sesión/login | Network → Headers | Cookie o Authorization |
| El servidor responde pero no muestra nada | Network → Response | Leer JSON para mensaje de error oculto |
EL SIGUIENTE PASO: COMPARACIÓN
1. Logueate en una aplicación que funcione correctamente
2. Observa una petición exitosa (Status 200 OK)
3. Pregunta: ¿Qué tiene el Header de esa petición que no tenía la petición 401?
4. Probablemente verás un campo nonce o una cookie de sesión activa
2. Observa una petición exitosa (Status 200 OK)
3. Pregunta: ¿Qué tiene el Header de esa petición que no tenía la petición 401?
4. Probablemente verás un campo nonce o una cookie de sesión activa
HERRAMIENTAS DEL ARSENAL
- DevTools Network/Console: Análisis en vivo, inspección de headers, debugging JavaScript
- Archivos .HAR: Caja negra persistente, análisis post-mortem, evidencia forense
- PowerShell LOTL: Automatización, procesamiento masivo, scripts reutilizables
- Google HAR Analyzer: Visualización rápida, análisis de timing, identificación de bottlenecks
[EOF] "The HAR file is like the black box of a crashed plane"