============================================================================== CUATRO FALLAS DE OCTUBRE EXPONEN EL RIESGO DE CUSTODIOS DE CREDENCIALES ============================================================================== Fuente: https://www.vantis.cl/noticias/custodios-de-credenciales-cuatro-fallas-octubre-2026 Publicado: 2026-10-22 (hora de Chile) Ambito: global · Criticidad: alta Descargado: 2026-10-25 05:43 (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 ---------------------------- · Monitoreo de integridad de archivos (FIM) sobre los directorios wp-content/plugins y wp-content/mu-plugins en servidores WordPress · Telemetría de red de EDR (Microsoft Defender for Endpoint, tabla DeviceNetworkEvents) o proxy saliente con registro de dominio/SNI por host · Logs de uso y facturación por llave API en la consola de cada proveedor de IA (OpenAI, Anthropic, Google) · Alertas de Certificate Transparency y avisos de los root programs (Chrome CRLSet, Mozilla OneCRL) para las cadenas de certificados en uso ============================================================================== REGLA 1 de 3 · SIGMA (canonica, neutral) Creación de archivo PHP en directorio de plugins de WordPress fuera de ventana de despliegue conocida ============================================================================== Requiere: Agente de FIM (Wazuh syscheck, auditd o equivalente) configurado con alcance en el webroot de cada sitio WordPress; ajustar 'filter_known_deploy' con las cuentas reales usadas por el pipeline de despliegue title: Creación sospechosa de archivo PHP en wp-content/plugins id: 7e4a1c2d-9f3b-4e68-8a2c-5d6f7b8e9a1c status: experimental description: | Detección por comportamiento (no por firma): identifica la creación de archivos PHP dentro de wp-content/plugins o wp-content/mu-plugins. No se basa en nombres de plugins ni hashes conocidos, porque el fabricante no publicó indicadores reutilizables; ajustar las rutas y excluir pipelines de despliegue legítimos antes de usar en modo de alerta activa. references: - https://labs.cloudsecurityalliance.org/research/csa-research-note-credential-custodian-platform-concentratio/ logsource: category: file_event definition: 'Requiere monitoreo de integridad de archivos (auditd, Wazuh syscheck u OSSEC) con alcance en el webroot de WordPress' detection: selection_path: TargetFilename|contains: - '/wp-content/plugins/' - '/wp-content/mu-plugins/' selection_ext: TargetFilename|endswith: '.php' filter_known_deploy: InitiatingProcessAccountName: - 'deploy-ci' - 'wp-cli-service' condition: selection_path and selection_ext and not filter_known_deploy fields: - User - Image - TargetFilename - CreationUtcTime falsepositives: - Instalación legítima de plugins por administradores o pipelines de despliegue autorizados - Actualizaciones automáticas de plugins existentes level: medium ============================================================================== REGLA 2 de 3 · WAZUH / VERIFICACION EN HOST Alerta FIM sobre archivos nuevos en directorios de plugins de WordPress ============================================================================== Requiere: Directiva syscheck en ossec.conf con directories check="realtime,whodata" apuntando a /var/www/*/wp-content/plugins y /var/www/*/wp-content/mu-plugins, y reglas base de FIM de Wazuh (550/554) habilitadas; status experimental hasta calibrar exclusiones 550 wp-content/(plugins|mu-plugins)/ Detección conductual: nuevo archivo en directorio de plugins de WordPress, posible instalación vía claves de administración remota comprometidas. Ajustar exclusiones de despliegue en el entorno. wordpress,file_integrity,supply_chain ============================================================================== REGLA 3 de 3 · MICROSOFT SENTINEL - KQL Primera conexión de un endpoint a dominios de proveedores de IA en los últimos 30 días ============================================================================== Requiere: Microsoft Defender for Endpoint habilitado con la tabla DeviceNetworkEvents disponible en Sentinel, y retención mínima de 30 días para construir la línea base; status experimental, pensado para triage manual // Detección conductual (status: experimental) - ajustar lista de dominios e intervalo según el entorno let lookback = 30d; let timeframe = 1d; let AIProviderDomains = dynamic(["api.openai.com","api.anthropic.com","generativelanguage.googleapis.com"]); let Baseline = DeviceNetworkEvents | where Timestamp between (ago(lookback) .. ago(timeframe)) | where RemoteUrl has_any (AIProviderDomains) | distinct DeviceName, InitiatingProcessAccountName; DeviceNetworkEvents | where Timestamp > ago(timeframe) | where RemoteUrl has_any (AIProviderDomains) | join kind=leftanti (Baseline) on DeviceName, InitiatingProcessAccountName | project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, RemoteUrl, RemoteIP ============================================================================== FALSOS POSITIVOS ESPERABLES ============================================================================== La regla de WordPress (Sigma/Wazuh) genera ruido en sitios con despliegues automatizados o actualizaciones frecuentes de plugins; hay que excluir las cuentas y rutas de los pipelines de CI/CD conocidos antes de activarla como alerta. Es detección por comportamiento, no por firma: no identifica un plugin malicioso específico, sino la creación de cualquier archivo PHP en esas rutas, por lo que requiere ajuste al entorno antes de producción. La consulta de Sentinel marcará como 'primera conexión' a cualquier desarrollador legítimo que use por primera vez una herramienta de IA; está pensada para triage manual, no para bloqueo automático. Ninguna de las tres reglas reemplaza la verificación manual de accesos y cuentas de administrador que piden TeamUpdraft y Patchstack, ni sustituye la ausencia de IOCs públicos reutilizables en este caso. ============================================================================== Vantis Chile SpA · https://www.vantis.cl/noticias Analisis con fines defensivos. Reutilizable citando la fuente. ==============================================================================