El atacante ha utlizado una cuenta de active directory por defecto (printer) para hacer login por SSH contra el honeypot / servidor de pruebas que tenemos disponible en nuestra ip publica El puerto SSH del firewall esta redirigido por NAT a ese servidor para que cualquier ataque SSH sea contra una maquina prescindible en lugar de contra la red corporativa La maquina sirve de repositorio de ficheros de informatica (utilizando samba). La maquina envia un log diario de seguridad por correo electrénico. En l log del dia 8 de marzo del 2011 se observé que el usuario printer habia hecho login desde la direccién IP 83.37.131.116 perteneciente a la red de telefénica Espana y a un’ usuario de IP dinamica de (posiblemente) la zona de Castilla La-Mancha, Se observa que el atacante lleva desde el 6 de febrero entrando y saliendo al servidor sin hacer nada hasta que decide actuar, utlizando el mismo como punto de origen para varias actividades maliciosas, entre ellas, el escaneo completo de una red de clase B (/16) por lo que el usuario ataca directamente la red corporativa, Pese a que el atacante lleva desde el 6 de febrero entrando, no ha realizado absolutamente nada en el servidor hasta el dia 8 de marzo. €! atacante dejé de entrar el dia 18 de febrero para volver 10 dias después y realizar todo el ataque de golpe en un intervalo de tiempo no superior a una hora, lo que indica que el atacante estaba ‘examinando y preparando el ataque con premeditacién, El atacante parece ser de origen Rumano (debido al idioma presente en los scripts usados, como por ejemplo “cautam” -> Search). El objetivo del atacante parece la red 189.1.0.0/16 brasilena Se observa también busquedas DNS hacia el dominio mundodastribos.com (brasilefio) El atacante habia redirigido un tty a un screen, Las primeras medidas tomadas, ya que el atacante no habia podido salir de su usuario “printer” han sido: = Desactivacion del usuario printer = Busqueda de todos los ficheros cuyo propietario es printer. = Busqueda de todos los ficheros creados entre las fechas del ataque ~ Eliminacion de todos los procesos del usuario printer. ~ Cambio del propietario de los ficheros del atacante a root y eliminacién de los permisos de sus directorio. ~ Diagnéstico del sistema ~ Analisis de los logs y carga del firewall interno / externo Entre ellos, el fichero /bin/ping estaba modificado en las horas del ataque, por lo que se procede posteriormente a la reinstalacién del paquete iputils.El andlisis del ancho de banda consumido para acceder al tunel ppp en 192.168.112.1 con la nueva red demuestra que el ataque se produce a las 15 horas y se mantiene up hasta el momento en el que se apagan los scripts que el atacante estaba ejecutando: HM sirewetn - trattic - etn2 I prey ry ce ey 14:00 16:00 10:00 20:00 22:00 00:00 02:00 04:00 05:00 From 2011/03/08 13:02:43 To 2011/03/09 06:03:58 Inbound Current: 275.30 Average: 313.52 k Maximum; 381.7 Outbound Current: 168.57 Average: 5.85 M Naximum: 6.8: Weekly (20 Minute Average) (GMT + 0 , la hora real es +1) El atacante s6lo tenia permisos de escritura en /var/tmp y /tmp por lo que en esas ubicaciones se localizan los scripts usados: Carpeta “Wvar/tmp/./.eyes”El fichero mass es un script en bash que ejecuta el script A para todas las direcciones ip de una subred determinada (encima ni se molestan en hacer un for...) Ja$i0 Ja$id Ja $1.2 Ja $13 Jas El fichero a es un script en bash que ejecuta pscan2 en el puerto 22 y guarda los resultados en bios.txt El resultado es una lista de hosts dentro de la subred que contienen un proceso escuchando en el puerto SSH (22) Scanner es un compilado para escanear el equipo local tanto a nivel de HW como de red, asi como realizar diversos escaneos tcpdump para interceptar conexiones (MIM supongo) Scanssh utiliza el fichero passfile como DB para atacar los sistemas SSH detectados previamente mediante un ataque de fuerza bruta. Screen es un proceso que se enlaza con uno o varios TTY para interceptar las consolas de administracién y/o ser utilizado como netcat clasico, Ninguno de estos iltimos pudo ser ejecutado con éxito ya que’ - No han sido compilados para la plataforma - No existe gcc / compilador disponible para ser utilizado. Ante la imposibilidad de actuar con estos sistemas, el atacante introduce en /tmp/uidd un script de perl para el control remoto de la maquina a través de IRC Las conexiones de IRC de la maquina son cortadas por el firewall interno por lo que el atacante sélo puede entrar por SSH pero no salir de la maquina de ninguna forma kernel.c es un Backdoor por IRC para el control de la maquina de forma remota. El script estaba siendo ejecutado pero no disponia de permisos para realizar ninguna tarea sobre el sistema Alas 15:39 del dia 9 de marzo, tras terminar el diagnéstico del sistema se procede al reinicio del mismo, comprobando que la configuracién del sistema no ha sido alterada y que el sistema es estable y seguro de nuevo.