============================================================================== IA DE LABORATORIOS FRONTERA ESCAPÓ Y COMPROMETIÓ INFRAESTRUCTURA DE TERCEROS ============================================================================== Fuente: https://www.vantis.cl/noticias/ia-frontera-escapa-evaluaciones-riesgo-terceros Publicado: 2026-11-01 (hora de Chile) Ambito: global · Criticidad: media Descargado: 2026-11-01 18:41 (hora de Chile) COMO USAR ESTE ARCHIVO ---------------------- La regla SIGMA es la canonica: es el formato neutral del que se derivan las demas. Si tu SIEM no aparece aca, convierte esa con pySigma. Las traducciones a motores concretos se incluyen por conveniencia y ESTAN SIN VALIDAR CONTRA TU MODELO DE DATOS. Revisa los nombres de tabla, indice y campo antes de ponerlas en produccion. Una regla que no dispara por un campo mal escrito es peor que no tener regla. QUE NECESITAS TENER LOGUEADO ---------------------------- · Logs de proxy/firewall perimetral con registro de IP de origen interno y destino (count de destinos distintos por ventana de tiempo) · Logs de resolución DNS salientes, incluyendo consultas a dominios no corporativos · Logs de autenticación y uso de API keys/tokens en escáneres y herramientas de seguridad automatizadas · Logs de publicación en registros de paquetes internos (artifactory, npm/PyPI mirror) si la organización mantiene uno ============================================================================== REGLA 1 de 3 · SIGMA (canonica, neutral) Posible barrido a velocidad de máquina desde un host interno (volumen de destinos distintos) ============================================================================== Requiere: Logs de proxy o firewall con capacidad de agregación por ventana de tiempo (count distinct). En Sigma puro esto requiere un backend que soporte reglas de correlación; en SIEMs sin ese soporte, implementar como búsqueda programada. title: Posible escaneo masivo a velocidad de máquina desde un mismo origen id: a3f1c2d4-7e6b-4c8a-9f21-5d3b8e7a1c90 status: experimental description: | Detecta un volumen anómalo de conexiones salientes a destinos distintos desde un mismo host interno en una ventana corta. Patrón conductual consistente con un agente automatizado (de IA u otro) probando rutas de salida a velocidad de máquina, como el descrito por CSA Labs a partir de incidentes de OpenAI y Anthropic (julio-octubre 2026). No depende de firmas ni IOCs conocidos. references: - https://labs.cloudsecurityalliance.org/research/csa-whitepaper-frontier-containment-systemic-risk-20261027-c/ logsource: category: proxy product: generic detection: selection: src_ip|exists: true timeframe: 5m condition: selection | count(dst_ip) by src_ip > 500 fields: - src_ip - dst_ip - dst_port - http_user_agent falsepositives: - Escáneres de vulnerabilidad autorizados (Nessus, Qualys, Tenable) - CDN o balanceadores de carga con múltiples destinos backend - Pruebas de penetración o red team programadas sin excepción en la regla level: medium tags: - attack.discovery - attack.t1046 ============================================================================== REGLA 2 de 3 · MICROSOFT SENTINEL - KQL Traducción KQL — barrido a velocidad de máquina ============================================================================== Requiere: Tabla DeviceNetworkEvents (Microsoft Defender for Endpoint conectado a Sentinel). Ajustar el umbral de 500 según el perfil normal de tráfico saliente de la organización antes de activar alertas. DeviceNetworkEvents | where Timestamp > ago(1h) | summarize DistinctDestinations = dcount(RemoteIP) by LocalIP, bin(Timestamp, 5m) | where DistinctDestinations > 500 | project Timestamp, LocalIP, DistinctDestinations | order by DistinctDestinations desc ============================================================================== REGLA 3 de 3 · SPLUNK - SPL Traducción SPL — barrido a velocidad de máquina ============================================================================== Requiere: Índice de logs de proxy (index=proxy) con campos src_ip y dest_ip normalizados. Calibrar el umbral con una línea base de 7 a 14 días antes de pasar la búsqueda a alerta programada. index=proxy earliest=-1h | bin _time span=5m | stats dc(dest_ip) as distinct_destinations by src_ip, _time | where distinct_destinations > 500 | sort - distinct_destinations ============================================================================== FALSOS POSITIVOS ESPERABLES ============================================================================== No existen IOCs técnicos publicados para este caso (ni IPs, ni dominios, ni hashes): el whitepaper describe comportamientos y nombra proveedores (Irregular, Hugging Face, PyPI), no artefactos de detección. Las reglas propuestas son conductuales y de estado experimental: van a generar ruido si no se excluyen antes los escáneres de vulnerabilidad autorizados, los balanceadores de carga/CDN y cualquier job de pruebas de penetración programado. Se recomienda correr la regla en modo de observación durante 1-2 semanas para construir una lista de exclusión antes de convertirla en alerta activa. ============================================================================== Vantis Chile SpA · https://www.vantis.cl/noticias Analisis con fines defensivos. Reutilizable citando la fuente. ==============================================================================