.-""-.

/ .--. \
/ / \ \
| | | |
| |.-""-.|
///`.::::.`\
||| ::/ \:: ;
||; ::\__/:: ;
\\\ '::::' /
`=':-..-'`

Del Defacement al Ransomware:

“Técnicas para Identificar, Mitigar y Recuperarse ante este
tipo de Incidentes”

Resumen

El presente es un informe sobre el análisis forense digital llevado a cabo en un servidor web
comprometido. En este caso, el servidor de la EmpresaXYZ fue comprometido y los
atacantes tenían acceso total al mismo. Para vulnerar las seguridades, los atacantes se
aprovecharon de plugins desactualizados de WordPress. Una vez que los atacantes tomaron el
control, realizaron un Defacement del sitio web y cifraron todos los ficheros alojados en el
servidor y solicitaban una recompensa para la restauración del sito web. Durante el análisis
forense, se logró identificar el origen, así como las técnicas usadas por los atacantes
informáticos, y finalmente se mitigó el ataque.

Palabras clave: webshell, análisis forense, incidente informático,

seguridad

betosec

Nota: Por motivos de confidencialidad, varios datos fueron modificados o surprimidos. Este informe sirve para ser
usado con fines educativos. El autor no se hace responsable del uso que se le de por parte de terceras personas.
 Del defacement al Ransomware

1. EL INCIDENTE
Aproximadamente a las n horas de un día lunes del año x, recibo una llamada de una
institución, que me informan que su sitio web XYZ ( empresaxyz.gob.ec ) está siendo víctima de
un ataque informático, para lo cual tuve que acudir inmediatamente al lugar de la EmpresaXYZ a
brindarles todo el apoyo necesario para la identificación del incidente y poder dar una pronta
respuesta ante el ataque informático del cual eran víctimas.

Ya en las instalaciones de XYZ, nos reunimos con todos los técnicos, y personas de otras
areas, quienes se encontraban un poco alertados, y no era para tanto, pues resultó que en esos días
dicha Institución se encontraba dando ciertos servicios a la ciudadanía, y era por esa página donde
los usuarios debían aplicar al proceso. Para que la EmpresaXYZ no siga siendo víctima del
ataque, solicitan que se realice un análisis forense digital, para detectar el tipo de ataque, su
procedencia, y las recomendaciones de seguridad que permitan solventar los problemas y asegurar
el sitio web.

Casos como este, donde se ve afectada la imagen de una Institución, se dan muchos a
nivel nacional, y es cuando suelen aparecer de manera inmediata las empresas, o consultores
expertos internacionales con el único afan de vender sus servicios o soluciones antivirus.
Lamentablemente muchas entidades se dejan engañar con la imagen de que un experto
internacional es mejor que el producto nacional, dejando de lado el talento ecuatoriano. Al final
estas empresas o los famosos expertos internacionales suelen implementar soluciones open
source, con unos costos excesivamente elevados.

El documento se divide en dos partes, que son el análisis forense digital que permitió identificar la
fuente del ataque, y la mitigación que ayudó con las medidas correctivas del servidor, en el
alcance se detalla estos dos puntos mencionados.

1.1. Alcance

o Identificar la fuente del ataque informático hacia el servidor web de la

Institución XYZ, así como su procedencia.

o Mitigar el servidor donde está alojado el contenido web, y brindar el apoyo

técnico para el aseguramiento del mismo.

1.2. Metodología
En casos como el sucedido, no existe metodología alguna o estandar que permita seguir
una serie de pasos para resolver el incidente informático. En este tipo de incidente, y según mi
experiencia, procedo primero a identificar bien el tipo de ataque informático, para poder tomar las
medidas correctas de mitigación. Muchas instituciones han fracasado en mitigar incidentes
similares, por caer en pánico y tomar el camino más rápido para ellos, que es borrar todo y
comenzar por una nueva instalación, lo cual es un grave error. No es recomendable que este tipo
de casos se proceda con el borrado de datos, lo más oportuno es inciar con una fase de
identificación y recolección de evidencias digitales, para su posterior análisis.

-2-
 Del defacement al Ransomware

1.3. Herramientas usadas

Al igual que en esta y otras instituciones, el personal creyó que se iba hacer uso de super
herramientas, como mucha gente cree, pero quedaron sorprendidos cuando se les comuniqué que
nuestra área hace uso de herramientas Open Source. Es increible como el Estado gasta recursos en
software y hardware licenciado que en varias ocaciones queda inservible, sobre este tema ya
tendré tiempo para narrar las experiencias y como conocí a varios proveedores.

En fin, la única super herramienta para este caso fue el sistema operativo Linux con
algunos comandos que ya vienen incluidos. Estos comandos fueron: ls, find, md5sum, sha1sum,
grep, whois, y xargs. Tambien se usé wpscan para identificar las vulnerabilidades que se
encontraban presentes en el sitio web por las cuales fue comprometido el servidor.

2. ANALISIS FORENSE
La seguridad del sitio web del sitio www.empresaxyz.gob.ec fue comprometida, en donde el
atacante pudo tomar el control del servidor y tenía como fin cobrar una recompenza. El atacante
realizó un cambio de imagen en su la página web (Defacement 1), el cual atenta contra la
integridad de datos de la Institución XYZ.

2.1. Identificación del Ataque

En la página inicial aparecía un texto (parte del mensaje en imagen 1), donde el presunto atacante
avisaba que el sitio está bloqueado y que se realice un pago en dólares americanos, y así, devolver
el control del sitio. En el mismo mensaje se mostraba una dirección de correo electrónico para que
se realice un pago vía PayPal, y lo más curioso del mensaje, es que decía: “Si intentas arreglar
por tu cuenta, toda tu información será borrada”, y es lo que dió inicio a la investigación.

Imagen 1. Página atacada de la EmpresaXYZ

Por la forma en que el atacante se manifestó en la página de inicio de la EmpresaXYZ, se

presume que el ataque fue realizado con fines económicos. El intruso no buscaba fama, ya que
generalmente, quienes se dedican a realizar este tipo de ataques suelen publicar sus hazañas en el

1Ataques a sitios web, donde son capaces modificar total o parcialmente el contenido o configuración de nuestra web. Las
técnicas más comunes del ataque se realizan por inyección SQL o vulnerando plugins desactualizados en gestores de
contenido.

-3-
 Del defacement al Ransomware

famoso sitio de Zone-H, lugar donde se encuentran los espejos de sitios web de todo el mundo,
que han sido atacados mediante esta modalidad.

Se hicieron varias busquedas en Internet sobre ataques parecidos, pero no existían ataques
similares o que tengan el mismo mensaje del incidente, lo cual dió muchas sospechas. Al realizar
búsquedas en Google con el texto "Your site is locked, please contact via email”, se encontró un
total de 59 resultados, pero hacian referencia a un malware conocido como Ronggolawe.

Imagen 2. Página atacada de la EmpresaXYZ

Otro ejemplo sobre este tipo de ransomware, es el que aparecía en un sitio web infectado con el
mensaje de la siguiente imagen, y llevaba como titulo de la página “CrYPT0WAR3”. En la misma
página aparece la dirección 13ZKcDGGN9J2koQzuq3QWQ7Gs6BLqmUdpL para que realicen
el pago de 0.25 BTC.

Imagen 3. Página atacada de la EmpresaXYZ

Tanto el ataque web de la página mostrada en la imagen 2, como el de la imagen 3, tienen un

patrón totalmente diferente al que se identificó en la página web donde ocurrió el incidente. Para
ambos casos solicitan pagos con Bitcoins, mientras que para el caso de investigación piden un
pago via Paypal, con esto se descartó que sea el Ranswomware Ronggolawe. Al momento de
realizar el análisis forense, existía poca información sobre este tipo de ataques, el único estudio

-4-
 Del defacement al Ransomware

encontrado fue uno realizado por la empresa Imperva, en donde hacen un análisis del
comportamiento y como puede ser bloqueado con su herramienta Imperva Incapsula2.

2.2. Comportamiento del Ataque

Con la intención de alertar y causar pánico en los administradores del sitio web, el atacante
codificó todos los archivos del sitio web del servidor, dando la apariencia de que el servidor se
encuentra infectado por algun Ransomware. Otra característica que se identificó, fue que todos los
archivos tenína una extensión shor7cut. A continuación un fragmento de algunos ficheros listados.

Imagen 4 Listado de archivos modificados por el atacante

Cuando se trató de acceder a los archivos, se confirmó que se encontraban codificados, ya que al
intentar abrir cualquiera de estos con un editor de texto, el contenido de los mismos, fueron
caracteres ASCII, tal como se muestra en el extracto del fichero readme-post.php.shor7cut a
continuación:

Imagen 5 Archivos cifrados del sitio web

Todos los archivos que se encontraban dentro del servidor web, estaban codificados de la misma
manera, dando la aparencia de estar codificados en base 64. La solución que tomaban dentro de la
institución afectada, fue restaurar backups del sitio con fechas anteriores al ataque, pero al parecer
el atacante ya tenía el control total del sistema; pues cada vez que los ingenieros solucionaban con
una restauración, el sitio volvía a ser atacado con el mensaje de defacement y los ficheros
codificados. El siguiente reto, fue identificar como es que el servidor había sido comprometido, y
detectar si existe algún backdoor o puerta trasera en el servidor, por la cual está dando acceso total
a los atacantes informáticos.

2.3. Identificando la WebShell

En una primera etapa se verificó el firewall para identificar conexiones del exterior, pero en esta
tarea no se encontró ninguna pista, a demás como medida de seguridad, los técnicos habían
cerrado el acceso por SSH y todo denegado todo tipo de conexiones entrantes hacia el servidor.
Ahora el siguiente reto, fue buscar algún tipo de petición irregular en las conexiones web que se
realizan por el protocolo HTTP y HTTPS.

2 Analysis of Ronggolawe Ransomware and How to Block It, https://www.imperva.com/blog/2017/08/ronggolawe-

ransomware-how-to-block-it/

-5-
 Del defacement al Ransomware

Sin contar con herramientas instaladas para el análisis de Logs, se accedió desde la consola de
comandos, y se ubicaron los Logs de acceso y error del servidor web. Lo más facil en estos casos
es descargar todos los registros y procesarlos en alguna herramienta de análisis de logs, yo suelo
usar ELK Stack para este tipo análisis, pero en este caso no se contaba con el tiempo suficiente
para dicha tarea.

Con la ayuda de comandos de linux, se realizaron varias búsquedas, todas enfocadas con el día y
hora estimada en que ocurrió el incidente. Buscando la hora del incidente, la cual fue
aproximadamente a las 20:40 de la noche, se analizaron todas las peticiones web del exterior. En
la siguiente imagen se observa que la IP 63.x.y.z accedió a un archivo de extensión php ubicado
en el directorio /plugins/.

Imagen 6 IP de conexión del atacante

Analizando el contenido de la carpeta de plugins se identificó la existencia de un archivo en

leguaje php y que tenía código ofuscado en base64, tal como se muestra en siguiente extracto:

Imagen 7 Código PHP codificado en bas64.

Al decodificar el código se pudo recuperar todo el contenido, el cual era una WebShell 3escrita en
lenguaje PHP. Fue esta webshell la que daba el acceso y control total al atacante informático.

Imagen 8 Parte de la web shell decodificada

Este código PHP o webshell, sirve para que el atacante pueda interactuar remotamente con el
servidor remoto donde se encuentra instalado WordPress. Al abrir directamente el archivo PHP
desde un navegador web, se evidenció como era posible acceder a una consola web, desde la cual,
un atacante realizaba los cambios del archivo de inicio de la página web o cifraba todos los
archivos del servidor web. La webshell identificada, se la conoce como WSO shell backdoor. En
la imagen 9, se puede ver en detalle como era el aspecto de la webshell, desde la cual estaban
cambiando la imagen de la institución por la del defacement.

3Una web shell, es un script (archivo de instrucciones) que se carga en un servidor web y sirve para habilitar la
administración remota del equipo. El script pude ser desarrollado en cualquier lenguaje soportado por el servidor web,
siendo los más comunes escritos en PHP.

-6-
 Del defacement al Ransomware

Imagen 9 Ventana de la web shell abierta desde un navegador.

Para cifrar todos los ficheros, es posible que el atacante pudo haber usado alguna característica
propia de la webshell, que le permitió usar algoritmos de encriptación para dejar los archivos
cifrados e inaccesibles. Durante el análisis no se encontró ningún script que permita cifrar los
archivos del servidor web. Tambien es posible que si usó algún script para cifrar la información,
lo haya borrado para evitar su análisis y recuperación de datos desde el lado de la víctima.

3. RESPUESTA AL INCIDENTE
3.1. Mitigación del Ataque

Lo primero fue localizar el archivo que permitía dar el control del sitio al atacante, también
conocido como una web shell desarrollada en lenguaje PHP. El fichero principal se encontraba
ubicado en el directorio /plugins/.

Imagen 10 Evidencia de la WebShell subida por el atacante

Dentro de los Logs de acceso no se pudo identificar la fecha en que fue subido el archivo de la
web shell, debido a que estos se van sobrescribiendo. Se cree que el atacante logró vulnerar el
sitio web mucho tiempo atrás del incidente ocurrido, pues como se evidenció en la imagen
anterior, la fecha de creación de los archivos datan del 20 de junio de 2014, a las 11:29 am.

Como comenté anteriormente, no contaba con herramientas forenses, y solo disponía de los
comandos de Linux, lo que se me ocurrió ese momento, fue buscar una firma que identifique la
webshell, y para este caso extraje el texto inicial codificado en base64: “texto”, realicé una
búsqueda de todos los archivos que tengan ese texto:

# find . -type f -exec grep -H 'texto' {} \;

-7-
 Del defacement al Ransomware

Imagen 11 Archivos WebShell subidos por el atacante

con la busqueda anterior, se pudo detectar que el atacante dejó varios archivos de tipo webshell
dentro del servidor, con esto aseguraba sus futuros accesos en caso de que borren el archivo
principal ubicado en plugins. Una vez identificados todos los archivos del atacante, se realizó una
restauración del gestor de contenidos a fechas anteriores, y se eliminaron todos los scripts PHP
subidos por el atacante. De esta manera, el sitio volvió a su funcionamiento normal.

3.2. Identificación del ataque

La última tarea para poder terminar con este caso, fue la de buscar posibles vulnerablidades que
hayan permitido la explotación y acceso no autorizado al sitio web. La institución XYZ, hacia uso
de el gestor de contenidos WordPress, y una herramienta muy útil para esto, es la conocida
wpscan que permite listar todos los plugins instalados y aquellos que son vulnerables. El scaner
de vulnerabilidades detectó un plugin desactualizado, y que pudo haber sido por donde el atacante
se aprovechó para subir su webshell.

Imagen 12 Verificación de plugins WordPress

En el escaneo realizado, se observó que varios plugins se encuentraban desactualizados, así como
la misma versión de WordPress. Se presume que el ataque pudo haberse dado por la
vulnerabilidad de tipo LFI4 (Local File Inclusion) contra el plugin WP Rocket 2.10.3 o menores a
esta versión. En el mismo resultado del escaneo con wpscan muestran varias referencias sobre
esta vulnerabilidad, así como la información de que la vulnerabilidad es solventada en la versión
2.10.4 del plugin.

3.3. Aseguramiento del sitio

Para que el sitio quede completamente seguro y libre de cualquier tipo de script malicioso, no
basta con eliminar todos los archivos del atacante, sino que se debe tomar otras medidas como son
las actualizacion tanto del gestor de contenido, como de sus plugins a sus últimas versiones. El
plugín WP Rocket fue deshabilitado por el administrador hasta que se verifique si es necesario o
no para el sitio, caso contrario va ser desinstalado de WordPress. Por otra parte, se bloqueó el
acceso a la página de administración de WordPress, dando únicamente el acceso a las redes
internas de la EmpresaXYZ.

En la fase de aseguramiento, se apoyó y verificó que se actualicen los plugins obsoletos del
servidor, así como el gestor de contenidos WordPress a la última versión.

4 Vulnerabilidad que afecta a sistemas web. Mediante esta vulnerabilidad, un atacante realizar la ejecución de archivos
locales del servidor y de esta manera tener acceso total a los ficheros de configuración. En la siguiente página, explican la
vulnerabilidad y como podrían atacarla: https://backtrackacademy.com/articulo/explotando-la-vulnerabilidad-lfi

-8-
 Del defacement al Ransomware

Imagen 13 Restricción al directorio de administración

Con las restricciones a carpetas de administración del sitio web, se logra añadir más capas de
seguridad, para de esta manera dificultar ataques de diccionario contra las páginas de acceso por
credenciales.

4. CONCLUSIONES Y RECOMENDACIONES
Durante el análisis forense digital, se verificó que el sitio web de la EmpresaXYZ fue afectado el
día xx, mediante un ataque de tipo Defacement, dañando la imagen del sitio web. Para realizar el
ataque, es probable que el atacante se haya aprovechado de alguna vulnerabilidad detectada en
plugins obsoletos de WordPress. Esto le permitió subir una web shell al sitio, tomando el control
del servidor web. El archivo de web shell fue desarrollado en PHP, y según las últimas conexiones
de acceso a la misma, se pudo comprobar mediante los Logs de acceso, la dirección IP A.X.Y.Z¡.
Para poder mitigar este incidente, se realizó una limpieza total de los scritps maliciosos subidos
por el atacante, así como sus respaldos ubicados en diferentes directorios.

El análisis de vulnerabilidades realizado durante el análisis, no puede ser considerado como

suficientes, y se recomienda que en este tipo de servidores, se haga un análisis completo de
vulnerabilidades web, de igual manera, se deberá realizar un escaneo completo en todo el Sistema
Operativo, con el objetivo de identificar posibles intrusiones al sistema. Una buena práctica es
correr un sistema de chequeo de integridad de archivos, tales como rkhunter.

Es muy importante que el sitio cuente con certificados digitales SSL, para evitar posibles ataques
de hombre en el medio que pueden poner en riesgo el intercambio de datos sensibles entre el
servidor y los clientes que acceden al sitio. Los certificados digitales pueden ser generados
localmente y validados por la Autoridad Certificadora (CA) Let’s Encrypt [1], que es libre y para
su facilidad se puede usar CertBot [2].

Finalmente, se recomienda restringir el acceso a las carpetas del servidor web, tales como plugins,
y aquellas que no sean necesarias mostrar al público. Para este punto es recomendable el uso de
un WAF (Web Application Firewall), puede hacer uso de ModSecurity.

5. REFERENCIAS

[1] Certificate Autorithy Let’s Encrypt,

[2] CertBot, https://certbot.eff.org/#centosrhel7-apache

-9-