Leer un hallazgo de un servicio de detección

Un hallazgo de Amazon GuardDuty trae una severidad numérica entre 1.0 y 10.0, y el servicio la agrupa en cuatro bandas: baja (1.0 a 3.9), media (4.0 a 6.9), alta (7.0 a 8.9) y crítica (9.0 a 10.0). La documentación de AWS las describe así: baja es un intento que no comprometió nada, media es actividad sospechosa que se aparta de lo normal, alta indica que un recurso o una credencial está comprometido y en uso no autorizado, y crítica señala una secuencia de ataque posiblemente en curso.

Leer la banda es lo primero que haces con un hallazgo, porque fija el ritmo con el que miras el resto. Pero la banda es la gravedad que calcula el servicio con lo que ve; no sabe qué guarda el recurso para tu empresa. Eso lo aportas tú en la sala siguiente.

Abre el hallazgo del laboratorio y ubica el campo de severidad.

Un hallazgo siempre apunta a algo: una instancia, un bucket, una clave de acceso, un usuario. En los hallazgos de identidad, el recurso es la credencial usada, y dentro de ella viene la pista de dónde vive: una sesión temporal de un rol lleva en su identificador el rol y, cuando nació en una máquina virtual, también el identificador de esa instancia.

Saber qué máquina o qué recurso es el afectado es lo que te permite preguntar a su dueño, mirar su criticidad y, llegado el caso, contenerla. Sin ese dato el hallazgo es una alarma sin dirección.

El tipo de un hallazgo se lee de izquierda a derecha: la categoría de la amenaza, el recurso afectado y el nombre concreto de la detección. «UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS» dice, en orden: acceso no autorizado, sobre credenciales de identidad, que se trata de credenciales de instancia sacadas de la máquina y que se usan desde fuera de la red del proveedor.

Las credenciales temporales de una instancia se crean para que la propia máquina las use. Verlas llegar a la API desde una dirección que no es de AWS es raro, y por eso el servicio lo marca. Puede haber una explicación legítima, por ejemplo una salida a internet por una puerta de enlace propia, pero es una hipótesis que hay que descartar, no una suposición de partida.

El bloque de acción del hallazgo cuenta qué llamada a la API se vio y desde dónde. Ahí está el origen: una dirección IP y, a veces, la organización a la que pertenece. Esa dirección es el primer dato que se cruza con todo lo demás: con el registro de auditoría, con las listas de direcciones conocidas de la empresa y con otros hallazgos.

Anota siempre el origen tal como aparece. Más adelante verás que una misma dirección repetida en dos hallazgos distintos, o en dos nubes, cambia la historia.

Microsoft Defender for Cloud hace en Azure un trabajo parecido y escribe alertas con otro vocabulario: nombre, severidad (alta, media, baja o informativa), estado, recurso y una táctica de MITRE ATT&CK que describe la intención aparente. Según su documentación, la severidad se basa en el disparador concreto y en la confianza de que detrás haya una intención maliciosa; una alerta basada en una anomalía suele quedar en media.

El nombre del campo cambia, el razonamiento no: qué dice el servicio, con cuánta confianza, sobre qué recurso y desde dónde. Lee la alerta de ejemplo del laboratorio con esa misma plantilla.