Manual de investigación de Log4Shell — triaje basado en evidencia
Un manual de investigación paso a paso para Log4Shell (CVE-2021-44228): comprende la falla, encuentra los sistemas afectados, recopila indicadores, valida la exposición, detecta la explotación y planifica la mitigación — con herramientas reales y una ruta de investigación.
Respuesta rápida
Para investigar Log4Shell, confirma el registro y el CVSS de CVE-2021-44228 en NVD, comprueba el CISA KEV, identifica cada sistema que ejecuta versiones afectadas de Log4j, busca indicadores de consulta JNDI en los registros y el tráfico de red, valida la exposición y aplica los parches del proveedor o la mitigación antes de tratar el riesgo como reducido.
Definición
Una investigación de Log4Shell es el triaje basado en evidencia de la exposición a la vulnerabilidad de ejecución remota de código JNDI de Log4j (CVE-2021-44228), que cubre el descubrimiento de versiones afectadas, la recopilación de indicadores, la validación de la explotación y la planificación de la mitigación.
Respuesta primero
Haz triaje de Log4Shell en cinco pasos: Confirmar el CVE → Encontrar los sistemas afectados → Recopilar indicadores → Validar la explotación → Planificar la corrección.
1. Qué es Log4Shell y por qué importa
CVE-2021-44228 es una vulnerabilidad de ejecución remota de código en la función de búsqueda de mensajes JNDI de Apache Log4j 2. Un atacante que pueda controlar cualquier cadena registrada por una versión afectada puede desencadenar una consulta JNDI saliente y, cuando las condiciones lo permiten, una ejecución remota de código. Debido a que Log4j está integrado en miles de productos, el radio de impacto es amplio — por eso la vulnerabilidad tiene su propio aviso de CISA y su propia ola de explotación.
2. Sistemas y versiones afectados
Empieza por tu inventario de activos y mapéalo a las versiones conocidas como afectadas:
- Log4j 2.0-beta9 hasta 2.14.1 (y varias compilaciones 2.15.x) están afectadas por CVE-2021-44228.
- CVE-2021-45046 afecta a Log4j 2.x anterior a 2.16.0 y se puntúa por separado.
- Los productos que integran Log4j (servidores de aplicaciones, appliances de seguridad, SDKs) están afectados incluso si no instalaste Log4j directamente.
Usa el CVE Lookup para la severidad, el vector CVSS, los productos afectados y el estado en CISA KEV de cada CVE antes de priorizar.
3. Indicadores a recopilar
Cuando busques explotación, recopila — no borres — estas señales:
- Líneas de registro que contengan
${jndi:ldap://,${jndi:rmi://,${jndi:dns://o patrones JNDI codificados en base64. - Conexiones salientes desde hosts de aplicaciones hacia hosts LDAP/RMI/HTTP desconocidos en puertos inusuales.
- Cabeceras o parámetros HTTP que devuelven la entrada del usuario a los registros (User-Agent, Referer, X-Forwarded-For, campos de formulario).
- Fragmentos de comando observados en trazas de
exec()o líneas de comando de procesos en el host. - IOCs publicados por los proveedores y los avisos de CISA/NCSC: IPs de atacantes, dominios consultados mediante JNDI y hashes de payloads.
Normaliza y neutraliza cada indicador con IOC Lookup y comprueba el valor normalizado en la inteligencia de OpenTrojan. Registra el valor sin procesar antes de neutralizarlo.
4. Flujo de trabajo de la investigación
- Confirma el registro: lee los detalles del CVE y el aviso del proveedor para tu producto y versión exactos.
- Delimita el alcance: enumera cada host y servicio que ejecuta un Log4j afectado, incluidas las copias integradas.
- Recopila: extrae registros y capturas de paquetes de la ventana de tarea que estás investigando (no modifiques los archivos primero).
- Valida: distingue un escaneo benigno / una interacción con honeypot de una explotación real correlacionando la consulta JNDI con una solicitud saliente posterior o una ejecución de proceso.
- Contiene: aísla los hosts confirmados y luego aplica el parche del proveedor o la mitigación oficial antes de una remediación más amplia.
Inicia una nueva investigación para hacer seguimiento del alcance, la evidencia y la remediación por host — registra cada hallazgo del recopilador con su fuente y marca de tiempo.
5. Qué recopilar (disciplina de evidencia)
Para cada hallazgo, registra: host, servicio, versión de Log4j, línea de registro exacta (neutralizada), marca de tiempo observada, fuente del registro y el analista que lo confirmó. Mantén los registros sin procesar inmutables para una validación posterior.
6. Cómo validar
Una señal confirmada significa una consulta JNDI entrante desde entrada controlada por el atacante y una interacción saliente coincidente, o un marcador de ejecución de comandos. Una coincidencia única de plantilla de registro es sospechosa, no confirmada — tanto los atacantes como los escáneres desencadenan consultas. Nunca trates un hallazgo de herramienta como un veredicto por sí solo.
7. Detección y mitigación
- Detección: busca los indicadores anteriores, además de registros de acceso web con cadenas JNDI, y conexiones de salida hacia destinos LDAP/HTTP inusuales.
- Mitigación: actualiza a la versión de Log4j corregida por el proveedor, activa las mitigaciones oficiales para las versiones que no puedas actualizar, bloquea la salida hacia LDAP/RMI no confiables y aplica la acción requerida de CISA si el CVE está en KEV.
8. Herramientas que ayudan
- CVE Lookup — severidad, CVSS, productos afectados y estado KEV.
- IOC Lookup — normaliza, neutraliza y comprueba indicadores contra la inteligencia de OpenTrojan.
- Espacio de trabajo de investigación — hace seguimiento del alcance y la remediación.
9. Referencias
Referencias
Pregunte al asistente basado en evidencia de OpenTrojan — las respuestas citan sus fuentes.