Cyber
Incidentes de ciberseguridad
Incidentes de ciberseguridad
  • Practica1.1 Retos de cifrado simetrico y asimetrico
  • Practica1.0 Busqueda de leaks
  • Practica1.2 Envio email cifrado con thunderbird
  • Practica1.3 Phising y otras estafas
  • opcional sakura_room
  • opcional WebOsint
  • Practica2.1 Generacion de elementos
  • Practica2.2.2 Entrenamiento con phising email
  • practica2.2 gophish
  • Practica 3 2 Volumenes en docker
  • Practica 3 3 Profundizacion Syslog ng
  • Practica 3 4 Port Knocking
  • Practica 3 5 Montaje SOC con ELK
  • Practica4_2 Investigacion defacement
  • Practica4_3 Splunk
  • Practica 4_1 Investigacion elastic
  • Slingshot
  • Wazuh
  • AWS
  • Opcional1.0 Phising
  • Practica 4_4 Splunk exploring spl
  • Practica4_4_1 Splunk Dashboards
  • wireshark
Powered by GitBook
On this page
  • ENCONTRAR COMO ACCEDIO EL ATACANTE
  • ENCONTRAR LA WEBSHELL QUE UTILIZO EL ATACANTE
  • CONCLUSION

Practica4_2 Investigacion defacement

PreviousPractica 3 5 Montaje SOC con ELKNextPractica4_3 Splunk

Contenido

ENCONTRAR COMO ACCEDIO EL ATACANTE 2

ENCONTRAR LA WEBSHELL QUE UTILIZO EL ATACANTE 5

CONCLUSION 7

ENCONTRAR COMO ACCEDIO EL ATACANTE

Lo primero que vamos a hacer es encender la maquina y acceder a ella:

Lo primero que notamos al acceder a la maquina es que al darle a la tecla de recuperar comando tenemos el historial de los comandos que se han ejecutado en la maquina. No se han borrado , para que en un futuro a nosotros no nos pase lo mismo tenemos dos opciones:

  • Eliminar el historial actual de dicha terminal con “history –c”

  • Para deshabilitar que lo que ejecutemos se guarde automáticamente debemos ir a /etc/profile y agregar set +o history al final del archivo de configuración.

Volviendo a lo que nos ocupa , vamos a ejecutar “history” para ver el historial de comandos de la maquina:

Tambien podríamos ejecutar cat .bash_history que se encuentra en la carpeta home del usuario.

Si nos centramos en los primeros comandos :

Parece que no vemos nada raro , el usuario comenzó actualizando la maquina luego instalo apache , un servidor ssh y la configuración de teclado.

Pero tras investigar un poco este plugin Warfare 3.5.2 , vemos lo siguiente:

Y es que parece que esa versión del plugin permitia ejecución de código de forma remota. En la misma imagen podemos ver los pasos a seguir incluso para ver por ejemplo el archivo /etc/passwd.Asi que asumimos que esta fue la brecha de seguridad que aprovecho el atacante para hacer el defacement.

ENCONTRAR LA WEBSHELL QUE UTILIZO EL ATACANTE

Ahora vamos a entrar en los archivos del wordpress que se configuraron según el historial para ver si vemos algo raro.

En el index.php dentro del mismo home no veo nada raro.Pero en el index de /var/www/html/wp-content/plugins:

Veo esto , “el silencio es dorado” algo bastante raro.Pero tras investigar un poco por internet veo que es un mensaje por defecto de cuando un archivo index.php tiene errores asi que no hay nada mas por aquí.

Luego accedi a /var/log/apache2/access.log.1 y encontré:

Si nos fijamos a la mitad de la imagen vemos como se utilizo un archivo llamado s72_Shell.php

Vamos a buscar información del archivo por internet:

Y encontramos que es una webshell , que es la que parece que el atacante utilizo para realizar el ataque.Asi que ahora que ya sabemos el nombre de la Shell vamos a buscar el archivo:

Y parece que lo encontramos.Pero en su contenido no vemos nada mas solo que es una webshell utilizada para hackear pcs.

Si volvemos a nuestro Access.log.1 :

Despues de ejecutar la webshell la ip de la que recibe peticiones es la 192.168.1.37 asi que parece la que presumiblemente utiliza el atacante para atacar.

CONCLUSION

En definitiva hemos descubierto dos hechos interesantes:

  • El como accedió el atacante a la maquina , es decir , utilizando la vulnerabilidad del plugin Warfare 3.5.2 de RCE es decir ejecución de código remoto.

  • Y lo otro que hemos sacado en claro es la webshell que utilizo el atacante para realizar el defacement que en este caso fue la s72_Shell.php