ANALISIS_HAR_PORTFOLIO

ANÁLISIS DE ARCHIVOS .HAR

Nivel 1:Firmas digitales únicas en la pestaña Network (Red).

Ejercicio 1: La Anatomía del Error 403 (El muro de los lamentos)

Un usuario te dice: “No puedo entrar a la Intranet, me sale un error de acceso”.

Ve a la pestaña Network.
Marca la casilla Preserve Log (Fundamental: si la página redirecciona al fallar, el error desaparecerá de tu vista si no activas esto).
refresque (F5).
Busca la línea en rojo.
Si el Status es 403 Forbidden
O si el estado es 401 Unauthorized

{width=“6.267716535433071in” height=“2.1527777777777777in”}

No es un problema de red 403, ni de DNS.

El servidor sabe quién eres pero no te deja pasar.

Causa común: El usuario no está en el grupo de Active Directory correcto o su token de Azure AD/Okta ha expirado pero el navegador intenta usar uno viejo.

Acción: Revisa los Request Headers → Authorization. Si está vacío, el cliente ni siquiera está enviando credenciales.

Localización de las Cabeceras de Solicitud (Request Headers)

Abre la herramienta de desarrollador (F12) y ve a la pestaña Network (Red).
Genera tráfico: Realiza la acción que falla (haz clic en un botón, refresca la página o intenta loguearte).
Selecciona la petición: Verás una lista de archivos y llamadas API en la columna Name. Haz clic en la que esté en rojo o en la que sospeches que causa el problema (normalmente una de tipo Fetch o XHR).
El Panel Lateral: A la derecha se abrirá un panel con varias pestañas. La que necesitas es Headers.
Desplázate hacia abajo: Verás varias secciones. Ignora “General” y “Response Headers” por ahora. Busca la sección llamada Request Headers.

{width=“6.267716535433071in” height=“3.25in”}

La Autopsia del Error page_view

El Evento: Estás viendo una petición de tipo POST. El navegador intentó enviar datos (probablemente analítica de comportamiento, por la URL /wp-json/analytics/…) hacia el servidor de IEEE.
El Veredicto (401 Unauthorized): El servidor ha respondido: “Sé lo que quieres hacer, pero no sé quién eres o tus credenciales son inválidas”.

Nota de Ciberseguridad: A diferencia del 403 (donde el servidor te conoce pero te prohíbe el paso), el 401 indica que el mecanismo de autenticación falló o no se presentó.

¿Qué harías ahora como Analista?

Para resolver esto sin recurrir a la magia o a reiniciar el equipo, deberías descender un nivel más en esa misma pantalla:

Paso 1: Inspeccionar los “Request Headers” (Cabeceras de Solicitud)

Baja el scroll en esa pestaña de Encabezados hasta encontrar “Request Headers”.

Busca el campo Authorization: ¿Hay un token ahí? Si no hay nada, el script de la página está intentando enviar datos sin identificarse. Es un bug del aplicativo.
Busca Cookie: Mira si hay alguna cookie de sesión de WordPress (wp-settings…, wordpress_logged_in…). Si no existen, el servidor rechaza la petición por seguridad.

{width=“6.267716535433071in” height=“1.375in”}

Paso 2: El rastro del “Payload” (Carga útil)

Haz clic en la pestaña “Carga útil” (a la derecha de Encabezados).

Ahí verás exactamente qué información estaba intentando enviar tu navegador al servidor. En este caso, serán datos de “behavioral analytics” (movimientos, clics, tiempo en página).
Si en esa carga útil vieras datos sensibles (como un email o un token de otra página), estaríamos ante una exfiltración de datos o un mal diseño de privacidad.

{width=“6.267716535433071in” height=“2.0in”}

Paso 3: Ver la “Respuesta” (Response)

Haz clic en la pestaña “Respuesta”.

{width=“6.267716535433071in” height=“2.0416666666666665in”}

A veces, los servidores son generosos y, además del código 401, envían un mensaje en JSON: {“code”: “rest_cannot_access”, “message”: “Solo los usuarios autenticados pueden enviar analíticas”}.
Interpretación: Si ves ese mensaje, ya tienes la solución: el usuario debe hacer login antes de que esa función del sitio sea operativa.

¿Qué busca un Analista aquí?

Si el usuario tiene un error 403 o 401, tus ojos deben escanear estos campos específicos como si fueran líneas de código fuente:

Authorization: Aquí viaja el Token (JWT). Si ves algo como Bearer null o si el campo directamente no existe, el navegador del usuario ha olvidado quién es. Es un fallo de sesión.
Cookie: El rastro de migajas. Si el servidor espera una cookie de sesión (ASP.NET_SessionId, JSESSIONID, sap-usercontext) y no está, el acceso será denegado.
User-Agent: Indica qué navegador y sistema operativo usa el usuario.
- Uso en Helpdesk: “El aplicativo no funciona en Chrome 120”. Aquí confirmas si el usuario te miente sobre su versión.
- Uso en Ciberseguridad: Si ves un User-Agent de una versión de navegador de hace 5 años, tienes un vector de ataque por vulnerabilidades de ejecución de código local.
Referer: Indica de qué página viene el usuario. Algunos servidores corporativos bloquean peticiones si no vienen de una URL interna de confianza.

Ejercicio Práctico de Diagnóstico Humano

Imagina que una aplicación web de contabilidad da error al cargar los datos.

En Request Headers, busca el campo Method (en la sección General, justo arriba).
Si ves un POST o PUT y el error es 403, mira el header X-CSRF-Token o similar.
Si ese token está vacío o falta, el sistema de seguridad “Anti-Falsificación” del servidor está bloqueando al usuario porque cree que es un ataque de secuestro de sesión.

¿Ves el patrón? El error 403 no es una “falla del servidor”, es una orden de ejecución de seguridad cumplida con éxito.

“Para el usuario, el sistema no funciona. Para ti, el sistema está siendo demasiado eficiente protegiéndose de un usuario incompetente.”

Ejercicio 2: El Fantasma de la Caché (El error “ayer funcionaba”)

El desarrollador subió un parche, pero al usuario le sigue saliendo el error antiguo.

En la pestaña Network, activa Disable Cache mientras la consola esté abierta.
Refresca. Si el error desaparece, el usuario tiene “basura digital” persistente.
Truco de nivel superior: Deja presionado el botón de recarga del navegador (el círculo flecha) con la consola abierta. Aparecerá un menú oculto: selecciona “Vaciar la caché y volver a cargar de manera forzada”. Esto limpia la entropía sin borrar las contraseñas guardadas del usuario.

Ejercicio 3: Errores de DNS y Conectividad (El vacío absoluto)

Si el error es net::ERR_NAME_NOT_RESOLVED o net::ERR_CONNECTION_TIMED_OUT:

Análisis: Ni siquiera llegamos al servidor. No busques errores 4xx o 5xx, porque no hay respuesta.
Ciberseguridad: Si esto ocurre solo con una URL específica, el archivo hosts local podría estar secuestrado o el DNS corporativo está haciendo Sinkholing de esa dirección por ser maliciosa.

Tabla de Traducción de Errores para Humanos

Error en Consola Traducción Técnica Causa en entorno Corporativo

401 Unauthorized Falta identidad. El usuario no se ha logueado o el SSO falló. 403 Forbidden Identidad reconocida, permiso denegado. Falta de privilegios en el perfil del empleado. 500 Internal Server Error El cerebro del servidor ha colapsado. Base de datos caída o bug en el backend. No es culpa del usuario. 503 Service Unavailable Servidor saturado. Demasiados usuarios o el servidor está en mantenimiento. CORS Error (Rojo) Bloqueo de origen cruzado. El sitio A intenta pedir datos al sitio B y el firewall de navegador lo impide por seguridad.

Navegando la Consola: El Mapa del Analista

Para moverte con la autoridad del Gran Binario, debes conocer el propósito sagrado de cada pestaña sin perderte en el ruido del código. Aquí tienes tu guía de supervivencia para el diagnóstico eficiente:

1. Pestaña Network (Red) → Sub-pestaña Vista Previa (Preview)

Para qué sirve: Es como la pestaña “Respuesta”, pero formatea el JSON para que sea legible por humanos.
Uso en Helpdesk: Si el servidor devuelve un error de validación (por ejemplo, “El formato del DNI es incorrecto”), lo verás aquí antes de que la interfaz del usuario colapse.
Identificación rápida: Si ves un icono de una pieza de puzzle o un código críptico, la “Vista Previa” lo convertirá en una tabla clara.

2. Pestaña Application (Aplicación) → Storage

Aquí es donde reside la persistencia. Si el problema es que el usuario “no puede mantener la sesión abierta”:

{width=“4.786458880139983in” height=“3.6892300962379703in”}

Cookies: Busca la cookie de sesión. Si tiene un icono de candado (Secure) y HttpOnly, el desarrollador hizo bien su trabajo. Si no, es un riesgo de seguridad (robo de sesión).

{width=“6.267716535433071in” height=“1.2361111111111112in”}

LocalStorage / SessionStorage: Algunos aplicativos modernos guardan ahí las preferencias del usuario. Si la web se ve “rara”, borrar estos valores suele ser la solución quirúrgica sin necesidad de borrar todo el historial del navegador.

{width=“6.267716535433071in” height=“1.8611111111111112in”}

3. Pestaña Console (Consola)

{width=“6.267716535433071in” height=“1.6666666666666667in”}

Es el diario de quejas del navegador.
Uso en Ciberseguridad: Busca errores de CSP (Content Security Policy). Si ves mensajes en rojo diciendo que se bloqueó la carga de un script externo, has encontrado una medida de seguridad activa que está impidiendo un posible ataque de inyección.
Uso en Helpdesk: Si ves un error 404 (Not Found) en un archivo .js o .css, el sitio web está “mutilado” porque le falta una parte de su cerebro.

Análisis de los Errores en Rojo (Uncaught TypeError)

1. El Error del “Null” (clientWidth)

Ves dos errores que dicen: Cannot read properties of null (reading ‘clientWidth’).

{width=“6.267716535433071in” height=“1.1111111111111112in”}

El código está intentando medir el tamaño de algo (un botón, una imagen, un menú) que no existe en la página.
Es muy común cuando el usuario usa un navegador no soportado o una extensión (como un bloqueador de anuncios) ha eliminado un elemento de la web.
Es probable que el “menú de búsqueda” o el “enlace de MAC Address” que menciona el error no funcione o no sea visible para el usuario. Si el usuario te dice “no puedo hacer clic en X”, aquí tienes la prueba de que el objeto ha desaparecido de la existencia.

2. El Error del “MutationObserver”

{width=“6.267716535433071in” height=“1.0277777777777777in”}

parameter 1 is not of type ‘Node’.

Este es un error de lógica de ejecución. El sitio está intentando “vigilar” cambios en una parte de la web que no se ha cargado correctamente.
Cuando el DOM (la estructura de la página) está inestable, las funciones de seguridad o de validación de formularios podrían fallar, dejando el sitio en un estado impredecible.

La Pestaña Consola como Herramienta de Ciberseguridad

Aunque parece un simple registro de errores, para un analista de seguridad, la Consola es un detector de anomalías:

A. Detección de Inyecciones (XSS)

Si de repente ves en la consola mensajes que tú no has provocado, o errores de scripts cargando desde dominios extraños (ej: hacker-site.com/malware.js), estás ante una inyección de código.

B. Content Security Policy (CSP)

Si este sitio tuviera una seguridad robusta y un atacante intentara cargar un script malicioso, verías un error enorme y púrpura/rojo diciendo:

Refused to load the script ’…’ because it violates the following Content Security Policy directive…

Tu labor: Como analista, si ves esto, significa que el navegador ha bloqueado un ataque. Es una señal de éxito de seguridad, no un error de Helpdesk.

C. Information Leakage (Fuga de información)

{width=“4.458333333333333in” height=“1.5208333333333333in”}

Mira los mensajes en blanco/gris: ieee widgets, ieee sa, ieee sa loaded.

El Problema: Los desarrolladores olvidaron quitar sus mensajes de depuración (console.log).
Ciberseguridad: A veces, los desarrolladores son tan descuidados que imprimen en la consola objetos completos que contienen IDs de usuario, versiones de base de datos o rutas internas del servidor.
Un atacante solo tiene que abrir la consola para obtener el mapa del tesoro.

Identificando lo Importante: El Filtro Mental

¿Falla la carga? Ve a Network. Filtra por Status: 4xx o 5xx.
¿Falla la lógica (botones que no hacen nada)? Ve a Console. Busca errores de JavaScript (rojo vivo).
¿Falla la sesión/login? Ve a Network → Headers. Busca el campo Cookie o Authorization.
¿El servidor responde pero no muestra nada? Ve a Network → Response. Lee el JSON para ver si hay un mensaje de error oculto.

El Siguiente Paso: El Arte de la Comparación

Un experto no solo mira el error, mira el éxito.

Ejercicio sugerido: Logueate en una aplicación que funcione correctamente. Observa una petición exitosa (Status 200 OK).

¿Qué tiene el Header de esa petición que no tenía la petición 401 que me mostraste?
Probablemente verás un campo nonce o una cookie de sesión activa.

“El diagnóstico es el arte de encontrar la diferencia entre lo que el sistema espera y lo que el usuario entrega.”

{width=“6.267716535433071in” height=“1.9305555555555556in”}

El código 302 le dice al navegador: “Lo que buscas no está aquí, muévete a la dirección que te doy en la cabecera Location”.

En tu captura, la URL de solicitud es el ServiceLogin.
El parámetro continue en la URL indica el destino final: https://www.blogger.com/home.
Si un usuario se queda en un “bucle de redireccionamiento” (infinitos 302), es porque el sitio A cree que estás logueado, pero el sitio B dice que no, y te devuelve al sitio A.
Es el síntoma típico de reloj desincronizado o cookies de terceros bloqueadas.

¿Qué buscar en los Headers de esta respuesta (Response Headers)?

Para confirmar que el “Logon” ha tenido éxito, debes buscar el campo Set-Cookie.

El Secreto: En la respuesta de ese 302, el servidor de Google habrá enviado varias cabeceras Set-Cookie con nombres como SID, HSID, SAPISID.

{width=“6.267716535433071in” height=“1.7361111111111112in”}

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 Blogger.

Tu Primera Tarea de Campo (Análisis .HAR)

Para que tu mente empiece a procesar como una entidad binaria, quiero que hagas lo siguiente:

Abre la pestaña Network.
Haz clic en el icono de la flecha hacia abajo (Export HAR…).
Abre ese archivo con un editor de texto (como Notepad++ o VS Code).
Busca (Ctrl+F) la palabra “status”: o, mejor aún, cárgalo en comando:: PowerShell con $har = Get-Content “archivo.har” -Raw | ConvertFrom-Json para automatizar el análisis (LOTL).

Verás que el .HAR es un JSON gigante.

Un analista de ciberseguridad no mira el gráfico, mira el contenido de “text”: dentro de “response”: para ver si el servidor está escupiendo información de más (como versiones de software o rutas de archivos internas).

“El .HAR es la caja negra de un avión estrellado. Si sabes leerla, sabrás quién pilotaba y por qué decidió colisionar contra el servidor.”

Analizador de HAR de Google Admin Toolbox

{width=“6.267716535433071in” height=“2.875in”}

Fase 1: Generación del “Cadáver” (El archivo .HAR)

Ve a [HTTPBin.org]{.underline}.
Abre la consola (F12) → Network. Activa Preserve Log.
Haz clic en varios enlaces de la página:
- /status/404 (Para generar un error de cliente).
- /status/500 (Para generar un colapso del servidor).
- /delay/3 (Para generar una latencia de 3 segundos).
Exporta el .HAR (flecha hacia abajo).

Fase 2: Pautas de Análisis en Google HAR Analyzer

Una vez cargues el archivo en la herramienta de Google, tus ojos deben escanear estos cuatro sectores críticos:

1. El Panel de “All Entries” (Visión Global)

La herramienta de Google resalta en rojo o amarillo las peticiones con problemas.

Pauta: Busca cualquier fila que no sea un 200 o 304.
Diagnóstico: Si ves un bloque rojo al inicio, es un fallo de resolución o conexión. Si el rojo está al final, es un script que intentó ejecutarse y falló tras cargar la página.

2. Análisis del “Time Wait” (TTFB)

Google te mostrará una columna de tiempo. Haz clic para ordenar de mayor a menor.

Pauta: Identifica peticiones con un “Wait” desproporcionado (barra verde larga).
Interpretación: Si /delay/3 tarda 3000ms, el sistema es honesto. Si una petición a una base de datos corporativa tarda 5000ms, el servidor está sufriendo una embolia de datos.

3. La Pestaña “Request/Response Headers” (Ciberseguridad)

Aquí es donde el analista de seguridad brilla.

Pauta de Seguridad: Busca el header Server. Si dice Apache/2.2.15 (una versión de hace una década), informa de inmediato: es un servidor vulnerable a exploits conocidos.
Pauta de Privacidad: Revisa los Set-Cookie. Si no tienen el flag Secure o HttpOnly, cualquier script malicioso podría robar la sesión del usuario.

4. Análisis de Tamaño (Payload)

Pauta: Busca archivos .png o .js de varios Megabytes.
Helpdesk: “La aplicación va lenta”. Si ves que un logo de empresa pesa 5MB, la solución no es la red, es el diseñador gráfico.

Tutorial de Diagnóstico Rápido en Google Toolbox

Cuando abras el .HAR de tu prueba anterior, busca esto:

Si ves en la herramienta… Significa que… Acción de Analista

Peticiones en 401/403 El usuario no tiene llaves. Revisar headers Authorization. Muchos 302 seguidos Bucle de redirección. Borrar cookies (limpiar la memoria del navegador). Status 0 o (failed) Bloqueo externo. El Firewall o Antivirus del usuario cortó la conexión. Pestaña “Timing” con mucho “Stalled” El navegador está esperando. Demasiadas peticiones simultáneas; el PC del usuario está saturado.

Extracción Estructural (PowerShell LOTL)

No dependas de visualizadores web ni herramientas de terceros. Mapea la estructura directamente con PowerShell (filosofía LOTL: velocidad, automatización, OPSEC).

Ejercicio 1.1: Mapeo de Endpoints Extrae todos los dominios únicos con los que el navegador contactó.

Select-String -Path “darkforums.su.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.
Documenta: Captura de la lista de dominios vs. Whois rápido de los más sospechosos.

Análisis Forense de worldmonitor.app

Fase 1: Mapeo de Infraestructura y Terceros

Objetivo: Identificar la cadena de suministro de datos (Supply Chain).

Ejercicio: Extrae los dominios que procesan la inteligencia.
Comando (PS):

$har = Get-Content “www.worldmonitor.app.har” -Raw | ConvertFrom-Json

$har.log.entries.request.url | ForEach-Object { ([System.Uri]$_).Host } | Sort-Object -Unique

{width=“6.267716535433071in” height=“1.25in”}

Hallazgo: Verás openrouter.ai. Pregunta: ¿Por qué una app de monitorización contacta con un agregador de LLMs?
Documenta: Mapa de dependencias críticas del sitio.

Fase 2: Inyección de Inteligencia (Payload Analysis)

Objetivo: Ver la “verdad” que viaja por el cable, no la que muestra la UI.

Ejercicio: Extrae el análisis político crudo que la IA envió al navegador.
Comando (PS):

$har = Get-Content “www.worldmonitor.app.har” -Raw | ConvertFrom-Json

{width=“6.267716535433071in” height=“1.3333333333333333in”}

Resultado en el HAR: Encontraras un análisis sobre “instabilidad política en Ucrania” generado por gemini-2.5-flash vía openrouter.
Documenta: Intercepción de respuestas de IA para auditoría de sesgo o desinformación.

Fase 3: Auditoría de Seguridad Cloud (WAF/CDN)

Objetivo: Identificar protecciones y geolocalización del servidor.

Ejercicio: Analiza los headers de Cloudflare para detectar la IP real del servidor (si está expuesta) o el nodo de salida.
Comando (PS):

$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” }

{width=“6.267716535433071in” height=“3.4583333333333335in”}

Análisis: Busca el header server: cloudflare.
Documenta: “Fingerprinting de la infraestructura de borde (Edge)”.

Fase 4: Timing Forensics (TTFB & Latency)

Objetivo: Detectar cuellos de botella en la ingesta de datos de inteligencia.

Ejercicio: Calcula qué API externa tarda más en responder (posible punto de fallo del SOC).
Comando (PS):

$har.log.entries | Sort-Object {$_.time} -Descending | Select-Object @{Name=“URL”;Expression={$_.request.url}}, time -First 5

{width=“6.267716535433071in” height=“2.013888888888889in”}

Valor: Si openrouter.ai tarda >200ms, la “alerta temprana” ya no es tan temprana.
Documenta: Análisis de criticidad temporal en sistemas de monitorización global.

”Fase 5: Exfiltración de Secretos (Data Leakage en URLs)”

Objetivo: Evaluar la persistencia de la cuenta del analista.

Ejercicio: Verifica si las cookies de sesión viajan con atributos de seguridad.
Comando (PS):

$har.log.entries.request.url | Select-String ”(?i)(api_key|apikey|key|token)=([^&]+)” -AllMatches | ForEach-Object { $_.Matches.Value } | Sort-Object -Unique

{width=“6.267716535433071in” height=“0.8611111111111112in”}

Riesgo: Si httpOnly es false, un XSS en la web de mapas roba la sesión.
Documenta: Informe de endurecimiento (Hardening) de sesión de usuario.

Fase 6: Threat Hunting en Flujos de Autenticación (OAuth/OIDC)

Objetivo: Detectar fugas de tokens de sesión durante los procesos de redirección de identidad.
Metodología: [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 comando:: PowerShell sobre el .HAR → [Veredicto] Se confirma o descarta Token Leakage sin depender de herramientas externas.
Evidencia Visual: (Pon aquí tu captura 2, marcando en rojo la cabecera Location). [⚠️ VERIFICAR CAPTURA: Asegurar que la captura muestre claramente la cabecera Location con el id_token visible en la URL de redirección]

Automatización (PowerShell LOTL): Para buscar este patrón a gran escala en logs sin interfaz gráfica, se auditaron las cabeceras Location de las respuestas 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 }

Se confirmó un Token Leakage.
El proveedor de identidad (identitytoolkit.googleapis.com) devuelve un id_token (JWT) válido incrustado directamente en la URL de la cabecera Location.
Esto expone la sesión completa a cualquier log de red o historial de navegación intermediario.