Ya sea respondiendo a incidentes o investigando a través de conjuntos de datos grandes y complejos, las direcciones IP suelen ser un punto de análisis clave bastante recurrente.
Cuando se analizan casos de movimiento lateral, por ejemplo, saber de qué dirección IP se originó un inicio de sesión en particular es una pieza clave de información. De igual manera, al analizar algo como una intrusión de VPN, las direcciones IP también son críticas para establecer las narrativas del incidente y la “verdad fundamental.”
Sin embargo, las direcciones IP por sí solas solo cuentan parte de la historia, y debemos recurrir al enriquecimiento de datos para establecer dónde se ubica una dirección IP en particular, dónde está alojada esa dirección IP, y si una dirección IP en particular está asociada con actividad conocida como maliciosa o confirmada como maliciosa.
Otro dato clave cuando se trata de direcciones IP es el AS (sistema autónomo) al que pertenece una IP. Dependiendo del contexto de investigación o búsqueda, una dirección IP perteneciente a un ISP (proveedor de servicios de internet) residencial versus un proveedor de hosting puede cambiar las conclusiones del analista.
Es dentro de este contexto donde se sitúa este blog. En él, cubriremos qué son exactamente los ASN, cómo se pueden utilizar en flujos de trabajo de búsqueda y respuesta a incidentes, y proporcionaremos ejemplos reales de cómo usamos los ASN para desentrañar intrusiones y localizar actividad maliciosa en redes de socios.
¿Qué son los ASN?
Hoy en día, cuando pensamos en “internet,” normalmente pensamos en algún tipo de “cloud” abstracta que aparece en un diagrama.
Sin embargo, esta abstracción oculta una serie compleja de redes que se comunican entre sí y conforman lo que conocemos como internet.
Parafraseando a Cloudflare, los sistemas autónomos (AS) pueden pensarse como agrupaciones de redes que tienen una política de enrutamiento unificada.
Nos encanta esta analogía de Cloudflare:
“Imagina un AS como la oficina de correos de un pueblo.”
Cada “oficina de correos” de internet tiene un número asociado: el ASN, o número de sistema autónomo.
Cada dirección IP externa pertenece a un ASN o “oficina de correos” en particular. Por ejemplo, mi dirección IP de casa pertenece al ASN AS812, que pertenece a Rogers Communications Canada.
Armados con el conocimiento sobre qué son los ASN, veamos ahora cómo se puede utilizar y generar este dato.
¿Cómo se utilizan los ASN?
Ahora que sabemos que un ASN es como una dirección, el siguiente paso es utilizar esta información en el contexto de threat hunting o investigación de incidentes.
Cuando escuchamos frases como “enriquecimiento de datos” o “enriquecimiento de IP,” lo que a menudo se quiere decir con estas frases es enriquecer la dirección IP con metadatos como su información de ASN y/o su geolocalización.
Como ejemplo, podemos revisar la información de enriquecimiento de IP proporcionada por ipinfo.io para uno de los servidores DNS de Google:
Podemos ver en la imagen anterior que una dirección IP enriquecida nos proporciona mucha información útil.
Sabemos dónde se ubica la dirección IP (Mountain View, California, EE. UU.), y también sabemos a qué ASN pertenece la IP (AS15169 Google LLC).
Ahora, ponte en los zapatos de un analista al que se le pidió revisar un conjunto de registros de firewall. ¿Cómo podrías saber qué conexiones podrían ser maliciosas o al menos sospechosas?
Una forma de lograr esto es enriquecer estas direcciones IP con el tipo de metadatos descritos anteriormente, y usar esa información para detectar cualquier anomalía.
Los ASN son un dato crítico en este tipo de investigaciones, ya que los datos geográficos por sí solos pueden no contar toda la historia.
Veamos algunos ejemplos concretos y del mundo real de cómo el equipo de Huntress Tactical Response utiliza la telemetría de ASN para desentrañar intrusiones.
El caso del compromiso de escritorio remoto
Este caso comenzó cuando el Huntress SOC detectó movimiento lateral y enumeración de dominio.
Este es un conjunto de señales relativamente común de recibir, y cuando hay movimiento lateral involucrado, la red normalmente se aísla para evitar la propagación del acceso no autorizado.
Una vez que la red fue aislada y se emitieron los reportes, el equipo de Tactical Response comenzó a revisar la telemetría disponible para identificar el vector de acceso inicial. Nos enfocamos mucho en este aspecto investigativo, ya que saber dónde se originaron las intrusiones ayuda a nuestros socios a asegurar su entorno de manera estratégica y basada en riesgo.
Según la telemetría disponible, el compromiso parecía originarse desde el host de gateway de escritorio remoto del socio.
Sin embargo, esta no es suficiente información, y necesitábamos entender quién fue el “paciente cero” y exactamente cuándo se comprometió la cuenta, para que el socio (y nosotros) comprendiéramos el alcance completo del incidente.
Los registros del gateway de escritorio remoto estaban disponibles para este caso, y estos registros contenían información de IP. Sin embargo, como señalamos anteriormente en este blog, una IP sola no es suficiente. Necesitamos enriquecer esta información y luego analizarla.
Cuando enriquecimos las IP con información de ASN, la cuenta comprometida se hizo evidente, junto con información sobre exactamente cuándo se comprometió la cuenta y desde dónde.
Como podemos ver en la imagen anterior, el primer bloque de tiempo de telemetría muestra al usuario en cuestión autenticándose desde ISP residenciales como Comcast y Rogers.
En contraste, autenticaciones posteriores para la misma cuenta de usuario comienzan a ocurrir desde ASN más sospechosos como “LeaseWeb,” “BLNWX,” y “Datacamp Limited.”
Sin este enriquecimiento de ASN implementado, sería difícil—si no completamente imposible—detectar este compromiso de cuenta. Para conjuntos de datos que contienen miles de eventos de autenticación, revisar cada IP manualmente no es viable.
En este caso, pudimos brindarle al socio un panorama completo de la intrusión, incluyendo el vector de acceso inicial. Con esta información, el socio ahora podía comunicarle a su cliente la necesidad de controles de autenticación más fuertes, como la autenticación multifactor (MFA), de una manera respaldada por telemetría y datos concretos. ¡Una victoria para todos!
En este punto del blog, los lectores perspicaces que tienen algo de experiencia en respuesta a incidentes podrían preguntarse: “¿Qué pasa con las geolocalizaciones de IP?” “¿No es también un gran dato?”
Como todo en la vida, la respuesta a esta pregunta es un poco complicada. Vamos a desglosarla analizando otro caso de password spraying en un dispositivo RADIUS.
El password spray de RADIUS
En este caso, un socio tenía un dispositivo RADIUS que utilizaba Microsoft Entra para MFA.
El usuario se autenticaba en el dispositivo RADIUS, que está conectado al dominio de Active Directory de la red del socio, y la solicitud de MFA era manejada por Entra.
En este caso, el socio fue alertado por sus usuarios sobre una solicitud de MFA inesperada. Tras la investigación, se descubrió que alrededor de 60 cuentas fueron el objetivo. Ocurrió una autenticación exitosa en el lado de RADIUS, pero afortunadamente ningún usuario aceptó las solicitudes de MFA inesperadas.
Este caso es interesante por varias razones.
Primero, demuestra lo crítico que es el contexto al analizar compromisos relacionados con autenticación.
Si un analista solo hubiera revisado los registros de RADIUS de forma aislada, sin entender cómo estaban configurados AuthN y AuthZ en el entorno, todos los inicios de sesión parecerían exitosos.
Solo con la telemetría adicional de Entra pudimos correlacionar los inicios de sesión de RADIUS con sus eventos de autenticación correspondientes en Entra, y pudimos confirmar que ninguno de los inicios de sesión tuvo éxito del lado de Entra.
En segundo lugar, y más relevante para este blog, el caso ilustra las limitaciones de la geolocalización de IP al tratar con incidentes basados en cloud.
Al observar los eventos de autenticación de los usuarios en el lado de RADIUS con la información de IP geolocalizada, todo parece normal. El usuario históricamente se autentica desde Estados Unidos, en y alrededor de las ciudades marcadas en la siguiente captura de pantalla.
Solo después de agregar el enriquecimiento de ASN a estos eventos descubrimos que la cuenta efectivamente estaba comprometida:
Al observar solo la geolocalización, todo parecía normal. Sin embargo, al agregar los enriquecimientos de ASN, “Stark Industries” y “ROUTERHOSTING” destacaron como maliciosos.
Este caso es un excelente recordatorio de no confiar en un solo dato—como las geolocalizaciones—al determinar si un evento en particular es malicioso o benigno.
Los ASN son datos críticos al investigar el compromiso de dispositivos VPN.
Caso de compromiso de VPN
Si has leído nuestros blogs anteriores, no debería sorprenderte que el compromiso de VPN representa una gran parte de los casos que cubre tactical response.
Al investigar el compromiso de VPN, el enriquecimiento de ASN es invaluable y crítico para nuestro flujo de trabajo de investigación.
Veamos un ejemplo.
En este caso, Huntress recibió las siguientes señales para la red afectada:
Podemos ver un patrón común del actor de amenazas yendo tras credenciales de dos formas distintas:
- Mediante el volcado del registro
- Mediante el robo del historial de inicio de sesión del navegador
Los argumentos de línea de comandos utilizados para las técnicas anteriores indicaron que el movimiento lateral también estaba en juego para este incidente en particular, por lo que la red fue aislada para evitar más avances del actor de amenazas.
Cuando analizamos los registros de eventos de Windows para la red afectada, los patrones de autenticación indicaron un compromiso a través de un dispositivo VPN. Esto es muy común y un método popular de acceso inicial, como se mencionó anteriormente.
Al revisar los registros de VPN, dos inicios de sesión destacaron de inmediato.
Ambos inicios de sesión utilizaron el perfil super_admin , y cada uno ocurrió dentro de un segundo del otro, pero con direcciones IP diferentes.
Este es un patrón de autenticación inusual para un dispositivo VPN, especialmente para una cuenta de usuario que tiene privilegios administrativos sobre el dispositivo.
Cuando revisamos ambas direcciones IP en busca de sus valores de ASN, nuestro nivel de confianza en que estos eventos de autenticación eran maliciosos aumentó, ya que ambas IP pertenecían al mismo ASN: DigitalOcean.
Cabe señalar que el ASN de DigitalOcean no es inherentemente malvado o nefasto, y los administradores pueden estar utilizando máquinas alojadas en DigitalOcean para sus operaciones legítimas.
En este caso, sin embargo, los patrones de autenticación observados en combinación con los valores de ASN de DigitalOcean encontrados en los registros de VPN fueron suficientes para, como mínimo, escalar esto al socio, donde (desafortunadamente) se confirmó como comportamiento malicioso.
Conclusión
Los ASN son un dato crítico al realizar investigaciones y búsquedas.
A menudo, la actividad maliciosa se puede identificar únicamente a través de su valor de ASN asociado.
Por el contrario, los valores de ASN también se pueden usar como datos adicionales dentro de búsquedas e investigaciones para ayudar a confirmar o descartar actividad maliciosa.
Como hemos mostrado en este blog, el enriquecimiento de ASN es crítico al realizar investigaciones para una infinidad de servicios, incluyendo RDG, dispositivos de firewall/RADIUS y dispositivos VPN.
Este blog apenas toca la superficie en cuanto a la utilidad de los ASN como un dato de telemetría crítico. El mapa mental a continuación presenta algunas ideas adicionales para utilizar valores de ASN en tus propias aventuras de búsqueda e investigación, y proporciona una lista de valores de ASN que hemos observado recientemente vinculados a comportamiento malicioso.