4.5.2. Post-Explotation con Metasploit: Meterpreter Payload
4.5.2.1. Módulos de postexplotación Metasploit
En la introducción a Metasploit se ha explorado su arquitectura modular, siendo los módulos de postexplotación (post) uno de sus principales activos. En el punto anterior de introducción se han descrito las técnicas de postexplotación como todas aquellas acciones realizadas contra un objetivo que ha sido comprometido que incluyen: obtener información del sistema, escalar privilegios sobre el sistema, extender o programar el dominio sobre otros hosts o garantizar y mantener accesos posteriores (backdooring). Estas acciones se pueden realizar tras haber obtenido una shell de la víctima, empleando para ello los comandos que proporcionan las interfaces de consola de línea de comandos como CMD, Powershell (Windows) o sh, bash o zsh (Linux).
Los atacantes más habilidosos y conocedores de estos sistemas pueden ser capaces de realizar muchas de las acciones de postexplotación con algunos de los comandos básicos de sistema de la consola, aprovechando debilidades y vulnerabilidades inherentes al sistema (ver SO: Windows y SO: Linux) o de algún proceso activo que lo sea (un navegador web, un servicio, aplicaciones corporativas…). En otras ocasiones, no se tratará de aprovecharse de una vulnerabilidad, sino simplemente de acciones recurrentes como descargar un fichero, limpiar el registro de actividades, etc. No obstante, Metasploit proporciona una serie de recursos como son los módulos de postexplotación que permiten automatizar estas acciones.
Para poder usar uno de estos módulos, es indispensable en la mayoría de los casos haber obtenida una shell estándar del sistema comprometido o bien con el payload meterpreter (como se verá más abajo). En este bloque, no se volverá a explicar cómo obtener una sesión, se puede consultar las secciones correspondientes de Malware SA las dos formas principales (y obviando otros factores reales como son evasión de sistema de seguridad, uso de ingeniería social, etc.):
- A través de una vulnerabilidad de un servicio remoto con un exploit (2.5. Explotación de hosts y gestión de sesiones Shell y Meterpreter)
- A través de exportación y ejecución directa de carga útil (payload) de tipo obtención shell/meterpreter con Msfvenom (3.3. MSFvenom: Netcat y Handler Metasploit: Ejemplos prácticos).
Los módulos de postexplotación de Metasploit se pueden inspeccionar empleando el comando search (ver sección comandos básicos), indicando el tipo y si se quiere algún dato más.
search type:post <otras opciones>
Una búsqueda sin afinar puede resultar abrumadora, pero por cómo están organizados los módulos en Metasploit, rápidamente se puede observar que estos están clasificados por plataforma (sistema operativo, aplicación, multisistema…), función y objetivo, tal y como lo están los otros módulos comunes: exploits, payloads… El repositorio de información web del proyecto Metasploit contiene una clasificación basada en categorías. La traducción de estas categorías sería:
Categoría | Descripción |
gather | Módulos que involucran la recopilación de datos del sistema |
gather/credentials | Módulos para obtener datos de credenciales de usuarios y servicios. |
gather/forensics | Módulos que implican la recopilación de datos forenses. |
manage | Módulos que modifican, operan o manipulan algo en el sistema, incluyendo tareas relacionadas con la gestión de sesiones y procesos, acciones de migración o inyección, instalación de aplicaciones. |
recon | Módulos que ayudan a obtener más información sobre el sistema en términos de reconocimiento. Son pocos, algunos interesantes como el “Multi Recon Local Exploit Suggester“. |
wlan | Módulos que están destinados a tareas relacionadas con WLAN (red Wifi) |
escalate | De acuerdo a Metasploit: Esto está en desuso, pero los módulos permanecen debido a su popularidad. Esta solía ser la categoría para los módulos de escalamiento de privilegios. Todos los módulos de escalamiento de privilegios ya no se consideran módulos de post-explotación, ahora son exploits. |
capture | Módulos que implican la monitorización de algo para la recolección de datos. Por ejemplo: registro de teclas (keylogging). |
Afinando las búsquedas con el comando search de mfsconsole, se pueden obtener buenos resultados para examinar los diferentes tipos de módulos de postexplotación basándose en su plataforma y categoría. No obstante, si se quiere analizar en detalle, se recomienda exportar los datos de la consola y definir una tabla para extraer y clasificar por diferentes niveles como se muestra en el siguiente ejemplo. Aunque el catálogo de módulos de postexplotación parezca denso, para algunas plataformas y aplicaciones se reduce a pocos casos (no es el caso para los sistemas Windows y Linux, que son predominantes):
Como en cualquier otro módulo de Metasploit (payload, exploit, auxiliary…), el comando info proporciona información fundamental. Como se puede observar en la siguiente imagen para el módulo post/linux/manage/adduser, en la cabecera de la información se detalla que acción pretende y funciones, plataformas (sistemas admitidos), etc. Además, en la información inferior, se encuentra el tipo de sesiones para el cual es compatible (shell, meterpreter…) así como los datos a setear (ver configuración de módulo Metasploit), como si se tratará de un módulo de tipo exploit. En las siguientes secciones, se explicará cómo usar este módulo en las sesiones de shell o meterpreter establecidas.
4.5.2.2. Meterpreter Payload Metasploit: inicio y gestión de sesiones en red
Meterpreter es considerado un payload de tipo shell. Es decir, es la carga útil que en el proceso de explotación de una vulnerabilidad (o por acción de la víctima) permite obtener una consola de línea de comandos para hacerse con el control de un sistema remoto. Está integrado dentro del proyecto de Metasploit-Framework desde hace muchos años y proporciona una serie de funcionalidades exclusivas a través de la arquitectura modular de esta herramienta y la consola msfconsole. Las consolas obtenidas, también son denominadas sesiones (sessions), es por ello que en el artículo sobre administración remota (RAT; Remote Administration Tools) de la Wikipedia, se considera este payload como un programa usado para conectarse a otro ordenador a través de una red, a pesar de ser considerado un malware.
Como se ha indicado en la sección de configuración de payload de Metasploit, existen diferentes versiones de meterpreter, adecuándose a aspectos como la arquitectura de CPU, el sistema operativo, la distinción entre bind o reverse, así como aspectos técnicos sobre su funcionamiento que se han explicado en la sección de staged vs stageless payload. En todo caso, en las siguientes referencias se puede encontrar más información para quien quiera profundizar:
Otro ejercicio práctico es observar el tráfico de datos generado por la sesión de meterpreter. En la siguiente imagen de Kali Linux, se emplea una versión estándar reversa para un sistema Windows, es decir, la víctima comprometida es la que realiza la petición para establecer la sesión a través de la parte stager y posteriormente se envía el stage (carga útil), que es la parte que se carga en memoria y permite la ejecución de funciones de meterpreter como por ejemplo la obtención de información del sistema con el comando sysinfo. Las instrucciones introducidas en la consola de meterpreter pueden considerarse carga útil y también generan un tráfico de datos constante. De este modo, se establece una especie de arquitectura de tipo servidor-cliente entre la parte que controla o atacante (cliente) y la máquina comprometida (servidor), similar a los ataques de tipo Command And Control (C2).
Para ver en detalle el intercambio de datos de la sesión de meterpreter, se puede emplear Wireshark. Como es común en las comunicaciones en redes informáticas, se emplea el protocolo TCP-IP principalmente (aunque existen modalidades de meterpreter para utilizar otros protocolos de red de aplicación como HTTP/HTTPS, etc.) No obstante, meterpreter tiene como una de sus características principales el cifrado de datos de la comunicación. De este modo, más allá del establecimiento de la comunicación con el sistema Three-Way Handshake realizado en parte por el stager, en lo subsiguiente solo se podrá observar un intercambio de datos continuo. Para ampliar la información, ver el paper de meterpreter indicado arriba.
Para gestionar las sesiones primero deben obtenerse. Con el objetivo de hacerlo didáctico, en el ejemplo siguiente se obtienen dos sesiones de meterpreter tipo reverse en una máquina Windows 10 (192.168.1.41) y en otra máquina con Debian 12 (192.168.1.88), empleando para ello los puertos locales 3333 y 5555 respectivamente. Se ha utilizado un payload generado con Msfvenom. Como puede observarse en la imagen, para invocar el módulo de handler o manejador (módulo que se encarga de gestionar las peticiones del payload) se puede utilizar directamente la siguiente notación en msfconsole:
handler –p <payload> -P <LPORT | RPORT> -H <LHOST> <argumentos y opciones del payload>
La gestión de sesiones de realiza con el comando sessions de msfconsole. Con el argumento -h se descubren las diferentes opciones. En la siguiente imagen se resaltan algunas de las recurrentes o interesantes. Por ejemplo, está la opción de introducir comandos de la shell o meterpreter directamente desde msfconsole sin tener que acceder a la consola interactivo de control remoto con -c/-C, o bien hacer funcionar un script o módulo post con -s. Son opciones muy útiles cuando se tiene claro lo que se quiere hacer y se conoce bien la ejecución de acciones de postexplotación con Metasploit. También cabe destacar la opción –u, que permite obtener una sesión de meterpreter a partir de una shell estándar del sistema (CMD, bash…):
sessions -i <ID_session> <opciones: -c [command] | -s [script or module] | -u>
Pero centrándose en la gestión de sesiones, es decir, listar las sesiones activas, el acceso a ellas (interactuar) y terminar con ellas, que vendrían a ser las acciones más habituales, se podrían resumir en la siguiente secuencia:
- Listar sesiones activas (-l): Este comando permite ver que sesiones están en curso. El formato tabla idéntica con el valor Id a cada una de las sesiones. Metasploit va asignando de forma secuencial un número a cada sesión generada, siendo este número unívoco y que servirá para interactuar con esta (1, 2, 3… que se reinicia al terminar la sesión de Meterpreter). Además, también se presenta una mínima información del target y de la conexión establecida.
- Acceder o interactuar con la sesión (-i): Como indica la instrucción, consiste en acceder a la sesión remota y así poder manejar de forma directa con los comandos que ofrece la shell o meterpreter. En la imagen mostrada, también se puede observar en empleo del comando background. Este comando forma parte del núcleo o extensión principal de la shell/meterpreter y permite regresar a msfconsole. Como indica el nombre, en ningún momento se está cerrando la sesión, simplemente pasa a segundo plano.
- Terminar una o varias sesiones (-k / -K): Establece el fin de la conexión y en consecuencia el fin de la sesión. Se puede indicar para una sesión en concreto con -k o bien terminar con todas (-K).
# Listar sesiones activas
sessions -l
# Interactuar con sesión
sessions -i <id_session>
# Regresar a msfconsole (comando de núcleo)
background
# Terminar sesión o sesiones
sessions <-k [id_session] | -K>
NOTA: Se recuerda que aunque la sesión se haya marchitado, los manejadores (handler) pueden seguir activos a la espera de recibir nuevas peticiones e ir concretando diferentes sesiones (esquema C&C). Los handler en Metasploit se gestionando con la instrucción jobs, que también tiene sus propias opciones, similar a sessions (probar jobs –h):
4.5.2.3. Meterpreter extensiones y cargar módulos Postexploit
4.5.2.3.1. Meterpreter núcleo (core) y extensiones (load extensions)
La consola de meterpreter permite introducir instrucciones o comandos propios para actuar de forma remota a través de la sesión obtenida contra el target. Para distinguir este formato de los módulos de postexplotación de Metasploit, se les denominará comandos de núcleo y extensiones. Para comprender las funciones de las extensiones, se puede observar que al consultar las opciones avanzadas del payload (advanced) en la primera línea se muestra la opción AutLoadStdapi, que indica si cargar o no automáticamente la extensión Stdapi. En esta ocasión, se indica que no (false):
Una vez obtenida la sesión, con la instrucción ? o help se obtiene el listado de comandos disponibles en función de las extensiones cargadas. Al haber descartado la carga automática de la extensión stdapi, se mostrarán tan solo las funciones de núcleo (core) de meterpreter. En la imagen mostrada abajo se indican como Core Commands, e incluye funciones recurrentes ya mencionadas como background. Aunque la imagen está recortada, existen otras tantas opciones muy interesantes que se irán explicando a lo largo de este bloque de Postexplotación (4.5). En todo caso, los Core commands en general representan acciones de control de la propia sesión de Meterpreter, y no están dirigidos en gran parte a realizar acciones remotas contra el target:
Nota: En el siguiente enlace se muestran ejemplos para cada uno de los comandos, incluyendo los de la extensión stdapi. La información presentada es algo anticuada pero en la mayoría de los casos no ha habido variaciones significativas: https://en.wikibooks.org/wiki/Metasploit/MeterpreterClient
meterpreter > < ? | help >
Ahora sí, para trabajar con las extensiones disponible en meterpreter, debe emplearse el comando load. Es necesario indicar que las extensiones no son aplicables a todos los sistemas y en algunos casos pueden estar obsoletas. En todo caso, son un componente que va variando con las sucesivas versiones de Metasploit Framework, por la propia naturaleza del proyecto. Para listar las extensiones y cargarlas, se utilizan las siguientes instrucciones. En el ejemplo, se carga la extensión stdapi:
meterpreter > load -l
meterpreter > load <name_extension>
NOTA: Evidentemente, existen otras tantas extensiones interesantes como python, powershell, priv… que no se desarrollarán al completo en este bloque para no extender demasiado el artículo, aunque siempre se puede encontrar información interesante en Internet o a través de los repositorios oficiales del proyecto Metasploit: https://github.com/rapid7/metasploit-framework/tree/master/lib/rex/post/meterpreter/extensions
Una vez cargada la extensión, al indicar de nuevo la instrucción de ayuda aparecerán los nuevos comandos disponibles relativos a stdapi. Como se indica en el repositorio oficial, stdapi (vendría a ser algo como interfaz de programación de aplicaciones estándar para meterpreter) es la interfaz Ruby para entidades remotas para meterpreter proporciona acceso básico a archivos, red, sistema y otras propiedades del control remoto. Es en todo caso el corazón auténtico de meterpreter.
Como puede verse en la imagen de arriba (imagen compuesta), los comandos de stdapi se distribuyen por grupos de funciones que pueden resumirse del siguiente modo (existen ligeras diferencias entre Windows y Linux, pero como agrupación básica es válida para ambos sistemas):
Tipo | Descripción |
User interface Audio Output / Webcam | Registro de eventos y acciones del usuario y control sobre periféricos de sonido, webcam o ratón. Solo resultan útiles si detrás del target existe un usuario real que interactúe con el sistema. |
System | Obtener información y realizar acciones sobre los servicios y procesos del sistema (sysinfo, ps, getpid, getenv, getprivs…). La información proporcionada es crucial para poder acceder a privilegios superiores. |
Networking | Información sobre interfaces de red, servicios activos en puertos, etc. (arp, ipconfig, netstat, route…). |
File System | Acciones para tener gestión sobre el sistema de ficheros del sistema. Esto incluye navegación (cd, pwd, ls…), lectura (cat), creación de directorios (mkdir), así como la posibilidad de subir y descargar ficheros (download, upload, …), técnica habitual si se quiere llevar un paso más allá el proceso de postexplotación |
Es importante destacar que algunos de los comandos requieren de argumentos, por lo tanto, es recomendable inspeccionar cuales son antes de introducir la instrucción. Se pueden mostrar a través de help después del comando, como se muestra en esta imagen. En la siguiente sección de recopilación de información (Gathering), se mostrará alguno de estos comandos stdapi:
4.5.2.3.2. Meterpreter cargar módulos de Postexplotación Metasploit
Para utilizar los módulos de postexplotación con una shell o meterpreter en Metasploit, es habitual primero buscar el módulo adecuado así como obtener información: descripción, plataformas, opciones, parámetros… La información se puede obtener de diferentes formas, desde la sesión misma con el comando (info) o bien backgroundeando y empleando también el comando info o use y las opciones habituales de options, advanced…. En cualquier caso, la información será similar, aunque para ver las opciones avanzadas resulta mejor la última opción con use:
#Desde meterpreter
meterpreter > info <modulo>
#Desde msfconsole sin interactuar con el módulo
msf > info <modulo>
#Desde msfconsole interactuando con el módulo
msf> use <modulo>
msf(modulo) > <info | options | advanced>
El módulo utilizado para el siguiente ejemplo será post/linux/manage/adduser debido a que requiere determinados parámetros obligatorios que deben setearse. Como indica el nombre, sirve para crear un usuario en un sistema Linux.
NOTA: Aunque este no sea el caso, como podrá observarse al ir conociendo cada vez más meterpreter con la práctica, muchos de los módulos de postexplotación incluyen funciones que pueden realizarse directamente con stdapi.
Existen tres formas habituales de emplear los módulos post de forma interactiva y manual (en los anexos se explicará cómo automatizar este proceso al iniciar una sesión). Nótese que el parámetro más recurrente es SESSION, que indica la sesión o sesiones (sessions) en el que debe actuar el módulo. Las formas serían:
1) Desde meterpreter: Con el comando run. No será necesario setear la sesión. Las opciones deben indicarse a continuación de la invocación del módulo como en msfconsole:
meterpreter > run <module> <OPTION=valor>
2) Con comando sessions: Tal y como se ha indicado más arriba con el parámetro -s y posteriormente indicando las sesiones con –i (puede hacerse en varias a la vez, lo que representa una gran ventaja si se están manejando varias sesiones como en Command and Control):
msf > sessions -s <module> <OPTION=valor> -i <ID_sessions>
3) Usando el módulo y seteando las sesiones: Al igual que cuando se utiliza un exploit, con el comando use, seteando la sesión o sesiones (SESSION) y posteriormente ejecutando el módulo. Esta es la opción habitual que se muestra en la mayoría de manuales pues permite visualizar previamente información y parámetros del módulo:
msf > use <module>
msf (module) > set SESSION <ID_sessions>
msf (module) > exploit
Nótese que en cualquiera de los 3 casos, Metasploit proporciona la siguiente indicación: Post aborted due to failure: no-access: Session isnt running as root. Es decir, en ninguno de los casos el módulo ha resultado exitoso. Esto es así porqué el servicio o proceso iniciado por meterpreter en el target (servidor) está corriendo con un nivel de privilegios bajo, probablemente el del usuario corriente, que en ningún caso puede acceder al control de los procesos y acciones de gran impacto como es crear un usuario, como sí pueden hacer las cuentas de Administrator o Root para Windows y Linux respectivamente. Del mismo modo, al efectuar acciones para obtener información del sistema (Gathering), con un usuario de perfil bajo también se verá limitada la información a recolectar.
En la sección de Post-Explotation: Privilege Escalation (escalar privilegios) se ampliará la información respecto a los privilegios de la sesión de Meterpreter, así como en los métodos para que esta sesión pueda escalarlos y así poder efectuar acciones de postexplotación casi sin límites como Administrator o Root, lo que resulta fatal para la víctima.