La idea de este tutorial de Desarrollo de módulos auxiliares HTTP en Metasploit es mostrar la estructura de los módulos auxiliares de metasploit, familiarizarnos con el código, conocer las funcionalidades que nos ofrece el framework, para de esta forma empezar a crear y modificar los módulos de esta magnífica herramienta.
Tabla de Contenido
Desarrollo de módulos auxiliares HTTP en Metasploit tutorial 1
Este primer tutorial explica la modificación del módulo auxiliar de metasploit llamado «apache_mod_cgi_bash_env». Este módulo aprovecha la vulnerabilidad de Bash denominada shellshock y el cual fue publicado al poco tiempo que la vulnerabilidad se hizo pública.
También puede ser de tu interes – https://www.dragonjar.org/curso-de-metasploit.xhtml
<>
La principal motivación para modificar el módulo es porque al hacer las pruebas contra un servidor vulnerable, el módulo no respondía, ni generaba error o las excepciones correctas para verificar que el servidor era vulnerable o no, simplemente salía la siguiente pantalla:
Esta pantalla no era nada diciente por esta razón nace la necesidad de modificar los módulos y agregar puntos de depuración o mejoras.
Antes de empezar a modificar el módulo una breve explicación del código:
A continuación los parámetros que recibe como tal el módulo
Funciones del módulo auxiliar
Y por último las 3 funciones que conforman la operación del módulo auxiliar, las cuales vamos a explicar en detalle, la primera la funcion check_host, la cual es invocada una vez ejecutamos el comando check desde la consola de metasploit
El cuerpo de la función muestra el llamado de otro método llamado «req», el cual realizara la petición al servidor, enviando como parámetro el comando a ejecutar.
La función req hace uso del método «send_request_cgi» el cual hace parte de la clase «Msf::Exploit::Remote::HttpClient» incluida en la cabecera del módulo . Esta función se encarga de hacer la petición HTTP al servidor.
Como se puede observar en la imagen anterior, el método «send_request_cgi» recibe tres parámetros en este caso, el primero es el metodo http, el cual esta almacenado en la variable datastore[‘METHOD’], cabe recordar que esta variable es la que almacena el valor cuando nosotros hacemos uso del comando «set METHOD» en la consola de metasploit.
Segundo parametro en Desarrollo de módulos auxiliares HTTP en Metasploit
El segundo parámetro es el path del cgi, el cual almacenamos con el comando «set targeturi « en la consola de metasploit y por ultimo parámetro es el user-agent donde se inyecta el comando.
El método run_host no lo vamos a modificar en este ejemplo, por esta razón no vamos a explicar la funcionalidad. Solo vamos a modificar y validar el método check_host.
Entonces lo primero es agregar una función que imprima la respuesta del servidor, para esto vamos a utilizar el método:
print_status o el metodo vprint_status La diferencia entre estos dos métodos es que el método vprint_status despliega la información en pantalla si se encuentra en TRUE la variable VERBOSE
Nuestra función check_host queda de la siguiente forma
En la consola ejecutamos el comando reload, para que se tomen los cambios realizados
Ejecutamos la función check para validar la respuesta del servidor
Respuesta del servidor
Con esto validamos que la respuesta del servidor es un error interno del servidor (código 500) Podemos modificar el código que se envía en el agente, dado que el código inicial espera que la respuesta imprima un valor aleatorio, pero al validar que el servidor responde con un error 500, podemos intentar enviar un comando que cree un archivo en el servidor. Por ejemplo:
() { :; }; /bin/echo prueba > /var/www/poc/index_xxxxxx.php
El método req, quedaría de la siguiente forma:
Si recargamos el módulo con el comando reload y ejecutamos con check, vemos que sale el mismo erro 500 pero si verificamos en el explorador la dirección del nuevo archivo que se debió crear en el servidor podemos verificar que efectivamente responde
Por último agregamos al módulo que verifique si la creación del archivo en el servidor fue exitosa. solo basta con agregar un request y que dependiendo de la respuesta informe si el servidor es vulnerable.
Si todo sale bien el módulo auxiliar informa que el servidor es vulnerable una vez verifica la creación del archivo
Notas
- Para la POC es servidor vulnerable contaba con el CGI que especifican en la pagina https://www.invisiblethreat.ca/2014/09/cve-2014-6271/
- La versión publicada del módulo fue la que salio una vez se hizo publica la vulnerabilidad. En estos momentos el módulo tiene modificaciones y mejoras. (Recuerden mantener actualizado su metasploit msfupdate)
- En la próxima entrega como construir un módulo auxiliar para explotar una vulnerabilidad de denegación de servicio para Joomla. Saludos
Artículo escrito por Luis Hernandez, Especialista Seguridad Informática @luisco100 para La Comunidad DragonJAR.
La API de módulos auxiliares en 2026: lo que sigue vigente
Lo bueno de este tutorial es que no caducó: Metasploit Framework sigue vivo y activamente mantenido por Rapid7 —la versión 6.5.7 se publicó el 16 de octubre de 2026, y la rama 6.5 sumó 422 módulos nuevos aportados por la comunidad—. El framework sigue escrito en Ruby, y la anatomía que describe este artículo continúa intacta: `Msf::Auxiliary` como clase base, el mixin `Msf::Auxiliary::Scanner` con los métodos `run_host`/`check_host` por objetivo, `Msf::Exploit::Remote::HttpClient` para las peticiones HTTP, `send_request_cgi` para construirlas (verificado en la rama master actual), el `datastore` para las opciones como `METHOD` o `TARGETURI`, y `print_status`/`vprint_status` para el logging en consola.
La documentación oficial se movió a <a href=»https://docs.metasploit.com/docs/development/developing-modules/guides/how-to-get-started-with-writing-an-auxiliary-module.html»>docs.metasploit.com</a>, donde están la guía de inicio para módulos auxiliares (plantillas, campos `Name`/`Description`/`Author`, `update_info`) y la guía <a href=»https://docs.metasploit.com/docs/development/developing-modules/guides/how-to-write-a-check-method.html»>How to write a check method</a>, que formaliza lo que este tutorial hacía a mano: devolver códigos `Exploit::CheckCode` (`Vulnerable`, `Appears`, `Detected`, `Safe`, `Unknown`) en lugar de imprimir texto libre. Las buenas prácticas actuales son pocas y claras: usar las plantillas oficiales, registrar hallazgos con los mixins de reporte (`Msf::Auxiliary::Report`), no tragarse excepciones en silencio, mantener el framework actualizado y probar contra la rama master del repositorio <a href=»https://github.com/rapid7/metasploit-framework»>rapid7/metasploit-framework</a> antes de publicar nada.
Del laboratorio al aporte comunitario
El flujo del tutorial —editar el módulo, `reload` en `msfconsole`, `check`, iterar— sigue siendo el ciclo de desarrollo real, pero hoy se espera que corra sobre un laboratorio controlado: una máquina virtual vulnerable propia o un entorno de práctica aislado, nunca contra infraestructura ajena. Ejecutar módulos contra sistemas que no te pertenecen, aunque sea «solo un check», puede constituir acceso no autorizado; el límite no es técnico, es contractual: sistemas propios o autorización explícita y por escrito, con alcance, IPs y ventanas de tiempo definidos.
Si tu módulo aporta algo nuevo, el camino legítimo es contribuirlo. El framework acepta pull requests en GitHub; las guías de desarrollo exigen módulos autocontenidos, documentación en el propio código, códigos de check consistentes y comportamiento reproducible. Un consejo honesto: no portes este tutorial tal cual —Shellshock (CVE-2014-6271) es historia—. El valor actual está en aplicar la misma técnica —depurar respuestas, afinar `check_host`, validar PoCs— a vulnerabilidades vigentes. Un módulo auxiliar bien escrito que verifique una falla actual tiene más probabilidad de ser aceptado que cualquier exploit espectacular sin pruebas. Empieza pequeño, publica tu código, y deja que la revisión de la comunidad haga el resto.
