Sammi Notes

Properties1
tagsanalysis, forensics, evtx, webshell

Command and Control - web_attack_and_isp_webshell_localhost_access_log.txt

Sigue el rastro de las IPs

Cuando tienes un log masivo con varias IPs, lo primero es identificar el rol de cada una. En este log verás principalmente tres direcciones: 192.168.105.83, 192.168.105.76 y 192.168.105.64. También se aprecian en ocasiones peticiones internas.

Primero: identifica qué hizo la IP 192.168.105.83 al principio del log. Si nos fijamos en los códigos de respuesta HTTP (401 vs 200) y los nombres de las aplicaciones a las que accede, empezamos a tirar del hilo.

Punto de entrada (IP 192.168.105.83)

  • ¿Qué aplicación intenta comprometer? Busca la palabra /manager. En Tomcat, este es el panel de gestión.
  • Patrón de ataque: Verás múltiples peticiones seguidas con códigos 401 (No autorizado) hasta que de repente aparece un 200.
  • Pregunta de mentor: Si ves varios 401 seguidos de un 200 en el /manager/html, ¿qué técnica crees que ha tenido éxito?

¿Qué hace ruido y qué ejecuta algo?

A partir de las 09:32, la misma IP empieza a lanzar cientos de peticiones a rutas extrañas como boot.ini, etc/passwd, y scripts aleatorios (jsd1nrlqrxYi.html, etc.).

  • No te pierdas los detalles de cada archivo. El 99% de estas peticiones devuelve un 404 o 400.
  • Interpretación: Esto no es un humano tecleando; es un escáner de vulnerabilidades automático (como Nessus o Nikto).
  • En un informe de incidentes, esto se cataloga como “Reconocimiento ruidoso”.

Buscando compromiso (IP 192.168.105.76)

Aquí es donde el caso se pone serio. Olvidamos el escaneo ruidoso y saltamos hacia el final del log.

Buscamos las peticiones realizadas por la IP 192.168.105.76.

  • Ruta crítica: Busca /error/cmd.jsp.
  • El acontecimiento: Verás peticiones POST a ese archivo .jsp.
  • Análisis forense: En Tomcat, los archivos .jsp dentro de carpetas como /error/ o que no pertenecen a la aplicación estándar suelen ser Webshells.
  • Evidencia de persistencia: Fíjate si esa IP utiliza el usuario admin para subir archivos (POST /manager/html/upload).

Filtra el log solo con las interacciones de la IP 192.168.105.76:

  1. ¿Qué archivos subió?
  2. ¿Qué comandos parece estar ejecutando a través de cmd.jsp?

Aunque no veas el contenido del comando, el hecho de que reciba un 200 OK tras un POST confirma la ejecución.

Resumen de fases

  1. Fase 1: Fuerza bruta exitosa al Tomcat Manager por la IP .83.
  2. Fase 2: Escaneo masivo de vulnerabilidades (ruido) por la IP .83.
  3. Fase 3: Despliegue de Webshell y ejecución de comandos por la IP .76.
  4. Fase 4: Rotación de IP y ejecución por la IP .64.

¿Hay patrón? La IP .83 abrió la puerta y la IP .76 (que podría ser el mismo atacante tras cambiar de VPN/Proxy o un movimiento lateral) es la que realmente opera el sistema.

Comandos de análisis

Identificar archivos leídos (Path Traversal)

grep "192.168.105.83" log.txt | cut -d'"' -f2 | awk '{print $2}' | sort | uniq -c | sort -nr

O alternativamente:

grep -a "192.168.105.83" log1.txt | cut -d'"' -f2 | awk '{print $2}' | sort | uniq -c | sort -nr

Filtrar por código de estado HTTP

En ciberseguridad, lo que devuelve 404 no nos interesa ahora. Queremos los 200 OK o 302 (Redirección):

grep -a "192.168.105.83" log1.txt | awk '$9 ~ /200|302/ {print $7}' | sort | uniq -c | sort -nr

Actividad de la IP comprometedora

grep -a "192.168.105.76" log1.txt | awk '{print $7}' | sort | uniq -c

Resultado: 21 /error/cmd.jsp

  • Ese archivo es una Webshell.
  • No es un archivo estándar de Tomcat.
  • El atacante lo subió para ejecutar comandos del sistema operativo a través de la web.

Peticiones con 200 OK a la webshell

grep -a "/error/cmd.jsp" log1.txt | awk '{print $1, $6, $7, $9, $10}'

Fíjate en los bytes devueltos en la columna 10: confirman que se ejecutó código.

Archivos subidos vía Tomcat Manager

grep -a "upload" log1.txt | grep "192.168.105.76"

El atacante usó el panel de control que hackeó la IP .83 para subir sus herramientas.

Carpeta sospechosa jsp_app

grep -a "/jsp_app/" log1.txt | awk '{print $4, $7, $9}'

¿Exfiltración?

En un servidor Tomcat, la exfiltración a veces no es descargar un .zip, sino:

  • Leer tomcat-users.xml (robar más credenciales).
  • Leer archivos de configuración de bases de datos (context.xml).

Conviene buscar peticiones que intenten acceder a archivos .xml o .properties. El intento a WEB-INF. (con punto final) es un bypass de seguridad: en algunos servidores mal configurados, añadir un punto al final permitía saltarse restricciones que impiden leer web.xml. Sin embargo, devuelve un 404 — no lo consiguió por ahí.

La tercera IP (192.168.105.64)

Al final del log aparece la IP 192.168.105.64. Si su última acción fue subir otro archivo o acceder a /manager/html/upload, significa que el incidente seguía activo cuando se extrajeron los logs. Parece que efectúa un reescaneo.

El detalle del favicon.ico

El favicon.ico es el pequeño icono de la pestaña del navegador. Es anormal que el servidor lo envíe justo después de un POST a la webshell.

Cuando un atacante usa una Webshell a través de un navegador, cada vez que la página se refresca, el navegador solicita automáticamente los recursos asociados (como el favicon). Esto es evidencia de actividad humana: un script automatizado no descarga el favicon, pero un navegador web sí. Confirma que tras la automatización inicial, hubo un operador humano tomando el control.

Misión Final

Si eres el analista y ves que la última línea del log es a las 15:25:48 con un código 200 en la webshell:

  1. ¿El ataque ha terminado? No. El log termina mientras el atacante sigue ejecutando comandos.
  2. ¿Qué harías primero?
  • A) Borrar el log para que no se llene el disco.
  • B) Desconectar el servidor de la red o apagar Tomcat inmediatamente.
  • C) Bloquear la IP .76 en el Firewall pero dejar el servidor encendido.

Bloquear solo la IP detiene el ataque inmediato sin tirar todo el servicio, manteniendo la disponibilidad — Confidencialidad, Integridad y Disponibilidad.

El riesgo de bloquear solo la IP 76

Si el atacante está rotando IPs (como vimos con la .83, .64 y .76), bloquear la .76 es insuficiente. El atacante ya tiene:

  1. Credenciales de administrador (usuario admin).
  2. Persistencia (archivos .war subidos y la webshell cmd.jsp).

Si solo bloqueas la IP, se conectará desde una cuarta IP, usará las credenciales que ya tiene, y volverá a llamar a cmd.jsp.

Plan Post-Contención

  • Aislamiento y Observación.
  • Limpieza de Persistencia: Borrar los archivos .war subidos y /error/cmd.jsp.
  • Cambiar la contraseña del usuario admin de Tomcat inmediatamente.
  • Parcheado: Analizar por qué el escáner de la IP .83 tuvo tanto éxito. ¿Versión antigua de Tomcat? ¿Contraseñas por defecto?

Vista Gráfica