{width=“6.267716535433071in”
height=“3.4027777777777777in”}
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 y se aprecian en ocasiones, peticiones internas.
Primero
Identificamos 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)]{.mark}
-
¿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 que ejecuta algo? (IP 192.168.105.83)
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 (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 (o busca visualmente) solo las interacciones de la IP 192.168.105.76.
-
¿Qué archivos subió?
-
¿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
-
Fase 1: Fuerza bruta exitosa al Tomcat Manager por la IP .83.
-
Fase 2: Escaneo masivo de vulnerabilidades (ruido) por la IP .83.
-
Fase 3: Despliegue de Webshell y ejecución de comandos por la IP .76.
-
Fase 4: Rotación de IP y ejecución por la IP .64
¿Hay patrón?
La IP .83 abrió la puerta y parece que 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.
Por ejemplo, para identificar qué archivos intentó “leer” el atacante (buscando ataques de Path Traversal o inclusión de archivos):
grep “192.168.105.83” log.txt | cut -d’”’ -f2 | awk ‘{print $2}’ | sort | uniq -c | sort -nr
grep -a “192.168.105.83” log1.txt | cut -d’”’ -f2 | awk ‘{print $2}’ | sort | uniq -c | sort -nr
Este comando te daría una lista ordenada de todas las URLs atacadas por esa IP.
El Comando para limpiar
En lugar de solo contar URLs, vamos a filtrar por el Código de Estado HTTP.
En ciberseguridad, lo que devuelve 404 (No encontrado) nos da igual ahora mismo. Queremos los 200 OK (Éxito) o 302 (Redirección).
grep -a “192.168.105.83” log1.txt | awk ‘$9 ~ /200|302/ {print $7}’ | sort | uniq -c | sort -nr
{width=“6.267716535433071in”
height=“3.9027777777777777in”}
Path Traversal
{width=“6.267716535433071in”
height=“1.3472222222222223in”}
Script XSS
{width=“6.267716535433071in”
height=“0.7916666666666666in”}
Hasta ahora observamos que la IP 192.168.105.83 hace ruido pero detras hay otra que realiza el compromiso al sistema
Compromiso de la IP 192.168.105.76
Vamos a grepear con el comando
grep -a “192.168.105.76” log1.txt | awk ‘{print $7}’ | sort | uniq -c
{width=“6.267716535433071in”
height=“5.458333333333333in”}
21 /error/cmd.jsp
{width=“3.8333333333333335in”
height=“1.4791666666666667in”}
-
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.
Buscamos las request HTTP con estado 200 OK
grep -a “/error/cmd.jsp” log1.txt | awk ‘{print $1, $6, $7, $9, $10}’
{width=“4.453125546806649in”
height=“2.870120297462817in”}
Aquí se escupe la información por el número de bytes
{width=“5.444386482939633in”
height=“3.6989271653543305in”}
-
Fíjateen peticiones a /manager/html/upload.
-
Esto es crítico.
-
El atacante usó el panel de control que hackeó la IP .83 para subir sus herramientas.
-
Fíjate que tienes peticiones a /manager/html/upload.
-
Esto es crítico.
-
El atacante usó el panel de control que hackeó la IP .83 para subir sus herramientas.
grep -a “upload” log1.txt | grep “192.168.105.76”
{width=“6.267716535433071in”
height=“1.3194444444444444in”}
Hay una carpeta sospechosa /jsp_app/ con 14 peticiones.
grep -a “/jsp_app/” log1.txt | awk ‘{print $4, $7, $9}’
{width=“4.614303368328959in”
height=“2.6145122484689414in”}
No veo exfiltración
En un servidor Tomcat, la exfiltración a veces no es descargar un .zip, sino:
-
Leer el archivo tomcat-users.xml (para robar más credenciales).
-
Leer archivos de configuración de bases de datos (context.xml).
Conviene buscar si hay alguna petición (ya sea de la .83 o la .76) que intente acceder a archivos con extensión .xml o .properties.
{width=“6.267716535433071in”
height=“3.25in”}
Ese punto extra (WEB-INF.) es un intento de Bypass de seguridad.
En algunos servidores mal configurados, añadir un punto al final de la carpeta permitía saltarse las restricciones que impiden leer el archivo de configuración más sensible de una aplicación Java (el web.xml), donde suelen estar definidos los servlets y parámetros de seguridad.
-
Sin embargo, devuelve un 404.
-
No lo consiguió por ahí.
En el final sale la otra IP que falta 192.168.105.64
Si su última acción fue subir otro archivo o acceder al `/manager/html/upload`, significa que el incidente seguía activo cuando se extrajeron los logs.
Parece que efectúa un reescaneo
{width=“6.267716535433071in”
height=“2.2777777777777777in”}
El favicon.ico es el pequeño icono que aparece en la pestaña del navegador.
Aquí 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 de la webshell se refresca o carga el resultado de un comando, el navegador solicita automáticamente los recursos asociados (como el favicon).
Aquí parece más el rastro de un humano usando una interfaz web para ejecutar comandos en /error/cmd.jsp. Cada vez que el atacante “clicaba” o enviaba un comando, el navegador pedía el icono.
Misión Final
Si eres el analista de esta red y ves que la última línea del log es a las 15:25:48 con un código 200 en la webshell
-
¿El ataque ha terminado? No. El log termina mientras el atacante sigue ejecutando comandos.
-
¿Qué harías primero?
-
A) Borrar el log para que no se llene el disco.
-
B) Desconectar el servidor de la red o apagar el servicio Tomcat inmediatamente.
-
C) Bloquear la IP .76 en el Firewall pero dejar el servidor encendido.
Si bloqueas solo la IP es detener el ataque inmediato sin necesidad de 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 puede ser como poner una tirita en una herida abierta. El atacante ya tiene:
-
Credenciales de administrador (usuario admin).
-
Persistencia (ha subido archivos .war y tiene la webshell comando:: cmd.jsp).
Si solo bloqueas la IP, el atacante simplemente se conectará desde una cuarta IP, usará las credenciales que ya tiene, y volverá a llamar a su comando:: cmd.jsp.
Plan Post-Contención
Una vez que has bloqueado las IPs sospechosas, tu informe y tu análisis de mejora deberían incluir estos pasos críticos que menciono
-
Aislamiento y Observación
-
Limpieza de Persistencia: Tienes que borrar los archivos .war subidos y, por supuesto, ese /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. ¿Quizás la versión de Tomcat es antigua o las contraseñas eran por defecto?
El favicon
Para el informe de incidentes (IR Report), lo que comentamos del favicon.ico es una evidencia de actividad humana.
Un script automatizado no suele descargar el favicon, pero un navegador web sí. Esto confirma que tras la automatización inicial, hubo un operador humano tomando el control.