Análisis de VPC Flow Logs: exfiltración y criptominería
Cómo leer VPC Flow Logs en una investigación: campos clave, volumen saliente por destino, puertos de pools de minería, lo que nunca registran y sus trampas.
En resumen. Los registros de flujo son metadatos de red: quién habló con quién, en qué puerto, cuántos bytes, si se aceptó o se rechazó; por interfaz de red y agregados en ventanas de uno a diez minutos. En una investigación hay tres preguntas que merecen la pena: cuántos bytes salieron de una dirección privada hacia cada destino público (exfiltración), qué instancias mantienen conexiones de larga duración con puertos típicos de pools (minería) y qué direcciones externas llegaron con éxito a SSH/RDP (acceso). No contienen la carga útil, ni las consultas DNS al resolvedor de Amazon, ni el tráfico hacia los metadatos de instancia, y las descargas de S3 realizadas desde internet nunca atraviesan su VPC.
CloudTrail le dice qué se configuró. Los VPC Flow Logs le dicen qué hicieron después esos recursos en la red. Cuando un atacante llega a una instancia (mediante una clave robada, una aplicación vulnerable o una instancia nueva que ha lanzado él mismo), los registros de flujo suelen ser el único registro de adónde fueron los datos.
El registro predeterminado
El formato predeterminado es la versión 2 (documentación de AWS):
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 111122223333 eni-0f9e8d7c6b5a40000 10.20.1.11 192.0.2.150 40000 3333 6 42 8123 1789379520 1789379579 ACCEPT OK
| Campo | Significado en una investigación |
|---|---|
interface-id | La ENI: asóciela a una instancia con DescribeNetworkInterfaces o con las respuestas de RunInstances en CloudTrail |
srcaddr / dstaddr | En el tráfico saliente, srcaddr es la dirección privada de la interfaz |
dstport, protocol | 6 = TCP, 17 = UDP |
bytes, packets | Por registro, solo para esa ventana de agregación |
start, end | Segundos Unix |
action | ACCEPT o REJECT (grupo de seguridad / NACL) |
log-status | OK, NODATA (sin tráfico), SKIPDATA (registros omitidos) |
Los formatos personalizados pueden añadir vpc-id, instance-id, tcp-flags, pkt-srcaddr / pkt-dstaddr (las direcciones originales detrás de un NAT o de IP secundarias), flow-direction y traffic-path. Cuando reciba archivos desde S3, la primera línea indica los campos: consérvela, porque el orden de las columnas depende del formato elegido al crear el registro de flujo.
Pregunta 1: ¿salieron datos?
Filtre los registros ACCEPT cuyo origen sea privado (RFC 1918) y cuyo destino sea público, y después sume bytes por par (origen, destino) en toda la ventana del incidente. La exfiltración es una cuestión de volumen, y ese volumen se reparte entre muchos registros, porque cada uno cubre como máximo diez minutos (un minuto o menos en las instancias Nitro).
Qué buscar:
- un único destino público que recibe gigabytes desde una instancia que normalmente solo habla con una base de datos y un balanceador de carga;
- transferencias a horas inusuales, o que empiezan pocos minutos después de una sesión SSH del atacante;
- destinos en proveedores de alojamiento en lugar de sus socios conocidos.
Después compruebe qué más podría explicarlo: copias de seguridad hacia un servicio externo, actualizaciones de software, peticiones de origen de una CDN. La técnica correspondiente es MITRE ATT&CK T1048 Exfiltration Over Alternative Protocol: el protocolo es invisible para los registros de flujo; solo el volumen y los puertos son visibles.
Pregunta 2: ¿hay algo minando?
El tráfico de minería es lo contrario de la exfiltración: pequeño, constante e interminable. Indicios:
- cada instancia lanzada durante el incidente mantiene una conexión
ACCEPTcon las mismas una o dos direcciones públicas; - puertos de destino utilizados por pools de minería (3333, 4444, 5555, 7777, 14444 y similares);
- volúmenes de bytes parecidos minuto tras minuto, en ambos sentidos.
Existen pools que escuchan en el 443, así que el puerto por sí solo no es una prueba; lo son la regularidad y la coincidencia temporal con los eventos RunInstances. Consulte la respuesta a incidentes de minería de criptomonedas.
Pregunta 3: ¿quién entró?
Un ACCEPT entrante en el 22 o el 3389 desde direcciones públicas hacia una instancia le indica qué hosts externos alcanzaron un puerto de shell. Una avalancha de REJECT revela un escaneo; un único ACCEPT desde la misma dirección que después aparece en CloudTrail como origen de llamadas a la API une ambas fuentes.
Asociar interfaces con instancias
Los registros de flujo nombran interfaces de red, no instancias. Para vincular un flujo con la historia que cuenta CloudTrail:
- Tome el
interface-idde los registros sospechosos. - Búsquelo con
aws ec2 describe-network-interfaces --network-interface-ids eni-…, que devuelve la instancia asociada y sus direcciones privadas, siempre que la instancia siga existiendo. - Si se terminó, busque en CloudTrail la respuesta de
RunInstancesque contenga ese ID de interfaz o esa dirección privada; la respuesta incluyenetworkInterfaceSetpara cada instancia lanzada. - A partir de la instancia, pivote hacia el principal que la lanzó y hacia su perfil de instancia.
Añada instance-id a los formatos personalizados cuando cree nuevos registros de flujo: le ahorrará este paso en el próximo incidente.
Lo que los registros de flujo nunca le mostrarán
Según la lista de limitaciones de los registros de flujo de AWS, no se registra lo siguiente:
- el tráfico hacia el servidor DNS de Amazon (por tanto, nada de exfiltración por DNS a través del resolvedor de la VPC; utilice los registros de consultas de Route 53 Resolver);
- el tráfico hacia 169.254.169.254 (metadatos de instancia: el robo de credenciales desde IMDS no deja ningún flujo);
- Amazon Time Sync, DHCP, la activación de licencias de Windows, ARP y el tráfico hacia la dirección reservada del router predeterminado de la VPC;
- el tráfico reflejado (mirroring), en el lado de origen.
Además: los registros de flujo solo se aplican desde su creación en adelante, no se pueden editar (un formato nuevo requiere un registro de flujo nuevo), pueden omitir registros bajo carga (SKIPDATA) y no ven las descargas de S3 ni de otras API de AWS realizadas desde internet, que nunca entran en su VPC. Para S3, utilice los eventos de datos o los registros de acceso al servidor.
Trampas en los datos
- Dos registros por conversación. Uno por sentido y por interfaz; no cuente los bytes dos veces al sumar ambos.
- Gateways NAT. Detrás de un gateway NAT, los flujos de la instancia muestran la interfaz del NAT; utilice
pkt-srcaddr/pkt-dstaddrsi el formato los incluye. - Ventanas de tiempo.
start/enddelimitan la ventana de agregación, no la sesión TCP. - VPC predeterminada en regiones sin uso. Los atacantes lanzan instancias allí porque nadie activó los registros de flujo. La ausencia de registros no es ausencia de tráfico.
En el analizador
AWS Forensics lee registros de flujo en formato predeterminado y personalizado (teniendo en cuenta la cabecera y los campos pkt-*addr, y omitiendo NODATA/SKIPDATA) y señala más de 1 GiB aceptado desde una dirección privada hacia un único host de internet y conexiones salientes aceptadas hacia puertos conocidos de pools de minería, con las interfaces y los destinos como parámetros. Las evidencias de los registros de flujo aparecen en la misma Cronología que las de CloudTrail, de modo que la conexión SSH, la llamada RunInstances y la primera conexión al pool quedan alineadas. Para saber cómo recopilarlos, consulte la guía de exportación.