No escribo herramientas, construyo soluciones: el camino detrás de OIHEC Labs

Durante muchos años he visto cómo la industria de la ciberseguridad se ha llenado de herramientas enormes, pesadas y, en muchos casos, abandonadas. Frameworks que prometen resolverlo todo, pero que terminan dependiendo de decenas de librerías, interfaces complicadas y procesos lentos. En algún momento entendí que, si quería aprender realmente cómo funciona una tecnología, tenía que dejar de depender de herramientas de terceros y comenzar a construir las mías.

Así nació gran parte de los proyectos que hoy publico en GitHub bajo la organización hackermexico y que forman parte de OIHEC Labs. No nacieron con la intención de competir contra los gigantes de la industria, sino como una forma de experimentar, aprender y demostrar que una buena idea vale más que miles de líneas de código innecesarias.

Cada repositorio representa horas de investigación, errores, noches completas frente al editor de código y muchas tazas de café. Hay proyectos escritos en Python, Go, Rust, Nim y Crystal porque considero que cada lenguaje tiene fortalezas distintas y que un investigador de seguridad nunca debe limitarse a una sola tecnología. Aprender nuevos lenguajes no solamente mejora la forma de programar; también cambia completamente la manera en que uno entiende el funcionamiento de los sistemas operativos, las redes y el software moderno.

Uno de los proyectos que más disfruto desarrollar es NimProxy, una implementación ligera de proxy escrita completamente en Nim. Mi objetivo era comprobar hasta dónde podía llegar un lenguaje poco utilizado dentro de la comunidad ofensiva. El resultado fue un proyecto extremadamente rápido, con bajo consumo de memoria y una arquitectura muy sencilla de mantener. Además de ser un ejercicio técnico, NimProxy representa mi interés por explorar tecnologías que normalmente pasan desapercibidas.

Otro proyecto muy importante para mí es OpenSOC. Durante años he trabajado con soluciones comerciales de monitoreo y respuesta ante incidentes, pero siempre me quedó la sensación de que muchas pequeñas empresas jamás podrían pagar esas plataformas. OpenSOC nace precisamente con esa idea: construir una plataforma abierta que permita montar un Centro de Operaciones de Seguridad utilizando software libre, permitiendo que más organizaciones puedan mejorar su postura defensiva sin depender de licencias costosas.

También disfruto experimentar con lenguajes poco convencionales. Crystalfuscator surgió mientras exploraba Crystal como alternativa para generar binarios rápidos y difíciles de analizar. Más allá de la ofuscación, el proyecto me permitió estudiar compiladores, optimizaciones y técnicas modernas para proteger código fuente.

En el terreno del OSINT desarrollé Stalkeador, una herramienta enfocada en automatizar procesos de recopilación de información pública. Siempre he pensado que la inteligencia de fuentes abiertas es mucho más que buscar perfiles en redes sociales; bien utilizada puede ayudar a investigadores, periodistas, equipos Blue Team y analistas de fraude a comprender mejor el contexto de una investigación.

Para auditorías sobre aplicaciones web escribí PirataWeb, un proyecto pensado para facilitar el reconocimiento inicial y automatizar tareas repetitivas durante una evaluación de seguridad. En lugar de ejecutar decenas de comandos manualmente, mi intención fue concentrar varias funciones en una única herramienta sencilla de utilizar.

Otra área que siempre me ha parecido fascinante es la manipulación de protocolos. De ahí nació SpoofMaster, un proyecto que utilizo para estudiar cómo funcionan distintos mecanismos de identificación y comunicación entre equipos. Comprender los protocolos desde sus fundamentos permite identificar errores de implementación y fortalecer las defensas de manera responsable.

Con WebOS intenté construir un entorno donde varias utilidades relacionadas con pruebas sobre aplicaciones web convivieran bajo una misma interfaz. No buscaba crear otro framework gigantesco, sino un espacio modular donde fuera sencillo agregar nuevas capacidades conforme avanzara el desarrollo.

Rust se convirtió rápidamente en uno de mis lenguajes favoritos. Esa fascinación terminó convirtiéndose en ChingaRust, una colección de utilidades desarrolladas para aprovechar el rendimiento y la seguridad de memoria que ofrece este lenguaje. Cada nuevo módulo representa una oportunidad para aprender conceptos avanzados de concurrencia, redes y programación de sistemas.

En redes locales desarrollé LANCatcher, una herramienta orientada a facilitar la captura y análisis de tráfico. El objetivo nunca fue reemplazar soluciones ampliamente conocidas, sino comprender desde cero cómo funcionan los paquetes, las interfaces de red y los mecanismos de captura.

La información también deja rastros en Internet. Por eso escribí TrackLink, una utilidad que automatiza la obtención de información asociada con enlaces y recursos públicos, permitiendo agilizar procesos de análisis durante investigaciones OSINT.

Uno de los proyectos técnicamente más interesantes fue GeoLocator_Ultimate, donde reuní distintos mecanismos para obtener información geográfica asociada con direcciones IP y otros indicadores públicos. Más que un simple geolocalizador, representa un ejercicio sobre correlación de datos provenientes de múltiples fuentes.

Dentro del análisis de tráfico también desarrollé NetSpy, pensado para observar el comportamiento de una red y comprender mejor cómo interactúan los dispositivos entre sí. La visibilidad sigue siendo uno de los pilares más importantes de cualquier estrategia de defensa.

En cuanto a herramientas multipropósito, Chacal nació como un laboratorio personal donde voy integrando distintas funciones utilizadas durante auditorías y ejercicios técnicos. Es probablemente uno de los proyectos que más evoluciona conforme aparecen nuevas ideas.

Uno de mis objetivos a largo plazo es facilitar el despliegue de infraestructuras defensivas. ChaosWAF representa precisamente esa filosofía: un firewall para aplicaciones web ligero, abierto y personalizable, diseñado para integrarse fácilmente en distintos entornos.

Para reconocimiento de servicios desarrollé Sherminator, un escáner rápido cuyo propósito principal es acelerar la fase inicial de enumeración. Muchas veces unos cuantos segundos de diferencia hacen una enorme diferencia cuando se trabaja con cientos o miles de objetivos autorizados.

La privacidad siempre ha despertado mi curiosidad, y eso me llevó a desarrollar MartillazoNion, una herramienta enfocada en el análisis y enumeración dentro del ecosistema Tor. Más que explorar la red, mi interés ha sido comprender su funcionamiento interno y estudiar sus características técnicas.

Otro proyecto experimental es QuesoFr33, una colección de utilidades para auditoría y automatización que continuamente utilizo como banco de pruebas para nuevas ideas antes de incorporarlas a herramientas más grandes.

Probablemente uno de los desarrollos más ambiciosos ha sido NecropolisC2.py, un framework modular escrito en Python que nació como un proyecto educativo para comprender la arquitectura de los sistemas de comando y control utilizados en simulaciones de Red Team. Construir cada componente desde cero me permitió aprender sobre comunicaciones, modularidad, administración de sesiones y diseño de software distribuido desde una perspectiva completamente diferente.

Cuando alguien entra a mi GitHub suele pensar que solamente está viendo una colección de repositorios. Yo veo algo muy distinto. Veo años de aprendizaje, de errores, de versiones descartadas y de miles de horas dedicadas a entender cómo funcionan realmente los sistemas. Cada proyecto representa un experimento, una pregunta que quise responder escribiendo código en lugar de limitarme a leer documentación.

No creo que una herramienta convierta automáticamente a alguien en un mejor profesional. Lo que realmente hace la diferencia es comprender qué ocurre detrás de cada línea de código. Esa es la razón por la que sigo desarrollando software abierto: porque programar sigue siendo una de las mejores formas de aprender ciberseguridad.

Mi objetivo con OIHEC Labs no es publicar la herramienta más famosa de Internet. Mi objetivo es construir conocimiento abierto, demostrar que en Latinoamérica también podemos desarrollar tecnología de alto nivel y motivar a otros investigadores a crear sus propios proyectos. Si una sola persona decide abrir un editor de código después de leer este artículo y comienza a desarrollar su primera herramienta, entonces todo este esfuerzo habrá valido la pena.

Hay algo que pocas personas ven cuando observan un repositorio terminado: el enorme trabajo invisible que existe detrás de cada commit. Antes de escribir una sola línea de código normalmente paso días leyendo RFC, documentación técnica, implementaciones de referencia, investigaciones académicas y proyectos similares. No me interesa reinventar la rueda únicamente por orgullo; me interesa entender por qué esa rueda fue diseñada de esa manera y qué podría hacerse diferente. Muchas veces un proyecto termina siendo completamente distinto a la idea original porque durante el proceso descubro limitaciones que solamente aparecen cuando uno se enfrenta directamente al código.

Una de las cosas que más me apasiona es desarrollar prácticamente sin depender de frameworks gigantescos. Vivimos en una época donde instalar cientos de dependencias parece algo normal, pero cada dependencia representa un riesgo potencial, una actualización inesperada o una vulnerabilidad que tarde o temprano termina apareciendo. Prefiero invertir más tiempo escribiendo componentes propios que tener una montaña de librerías cuyo funcionamiento desconozco. Esa filosofía ha hecho que mis proyectos sean relativamente pequeños, fáciles de entender y sencillos de mantener incluso años después de haber sido publicados.

También me gusta experimentar con arquitecturas que normalmente no reciben mucha atención dentro de la comunidad. Mientras muchos desarrolladores siguen el mismo camino, yo intento explorar alternativas poco comunes. Por eso constantemente salto entre Python, Rust, Nim, Go y Crystal. No lo hago por presumir cantidad de lenguajes; lo hago porque cada uno me obliga a pensar de manera diferente. Rust me enseña disciplina con la memoria. Go me obliga a simplificar la concurrencia. Nim me recuerda que el rendimiento puede convivir con una sintaxis elegante. Crystal demuestra que un lenguaje moderno también puede generar binarios extremadamente rápidos. Python, por su parte, sigue siendo uno de los mejores laboratorios para convertir una idea en un prototipo funcional en cuestión de horas.

Muchas personas creen que escribir herramientas ofensivas significa únicamente pensar en ataques. Mi experiencia ha sido exactamente la contraria. Para construir una herramienta útil primero necesito comprender cómo defenderme de aquello que estoy estudiando. Entender protocolos, sistemas operativos, arquitecturas web y redes termina fortaleciendo mi capacidad para identificar debilidades antes de que un atacante real las aproveche. Esa mentalidad es la que intento transmitir cuando comparto mis proyectos públicamente: aprender cómo funcionan las cosas para construir mejores defensas.

Otra parte importante de mi trabajo consiste en automatizar tareas repetitivas. Después de realizar suficientes auditorías uno comienza a notar patrones que aparecen una y otra vez. Ejecutar los mismos comandos, revisar los mismos encabezados HTTP, analizar los mismos registros o repetir procesos de reconocimiento termina consumiendo un tiempo enorme. Cada vez que detecto una de esas tareas repetitivas me hago la misma pregunta: ¿por qué seguir haciéndolo manualmente si puedo escribir una herramienta que lo haga por mí? Muchas de mis aplicaciones nacieron precisamente de esa necesidad de optimizar el trabajo diario.

El rendimiento también ocupa un lugar importante en mi forma de desarrollar. No me obsesiona obtener el benchmark más alto, pero sí me interesa que cada aplicación haga exactamente lo que debe hacer sin desperdiciar recursos. Cuando una utilidad inicia en pocos milisegundos, consume poca memoria y puede ejecutarse incluso en hardware modesto, sé que el diseño va por buen camino. Esa filosofía me ha permitido probar muchas de mis herramientas en equipos antiguos, máquinas virtuales con pocos recursos e incluso dispositivos pequeños donde normalmente otros programas resultarían demasiado pesados.

Otro aspecto que considero fundamental es la portabilidad. Intento que mis proyectos puedan compilarse o ejecutarse con la menor cantidad posible de modificaciones entre Linux, Windows y, cuando es viable, macOS. No siempre es sencillo porque cada sistema operativo tiene diferencias importantes en su manejo de procesos, redes y permisos, pero precisamente ahí se encuentra uno de los aprendizajes más valiosos. Entender esas diferencias ayuda a escribir software más robusto y, al mismo tiempo, permite comprender mejor la superficie de ataque de cada plataforma.

La documentación merece un capítulo aparte. Durante mucho tiempo subestimé su importancia porque prefería dedicar cada minuto a escribir código. Con el paso de los años descubrí que una herramienta sin documentación es prácticamente invisible. No importa qué tan buena sea una aplicación si nadie entiende cómo instalarla, ejecutarla o extenderla. Por eso intento que cada nuevo proyecto incluya ejemplos, capturas, instrucciones y explicaciones suficientes para que cualquier persona pueda reproducir los resultados sin depender de mí.

Algo que disfruto especialmente es observar cómo evolucionan mis propios proyectos. Rara vez considero que una herramienta está terminada. Casi siempre encuentro una optimización pendiente, una función nueva o una forma diferente de resolver el mismo problema. En ocasiones vuelvo meses después a revisar código antiguo y descubro decisiones que hoy resolvería de otra manera. Lejos de verlo como un error, lo interpreto como una evidencia de crecimiento. Si mi código de hace dos años me parece mejorable, significa que he aprendido algo nuevo en ese tiempo.

El software libre también me ha enseñado el valor de recibir críticas. Publicar un repositorio significa aceptar que otras personas leerán tu código, encontrarán errores, propondrán mejoras o incluso implementarán soluciones que nunca habías considerado. Esa interacción es una de las mayores fortalezas del desarrollo abierto. Cada comentario, cada reporte de errores y cada contribución representan una oportunidad para construir proyectos más sólidos que difícilmente podrían existir si permanecieran encerrados en un disco duro privado.

A menudo me preguntan por qué continúo publicando código si muchas empresas prefieren mantener sus desarrollos completamente cerrados. La respuesta es sencilla: porque aprendí gracias al trabajo abierto de miles de desarrolladores que decidieron compartir conocimiento antes que esconderlo. Gran parte de lo que sé hoy existe porque alguien escribió un artículo técnico, publicó un repositorio o explicó cómo resolvió un problema complejo. Compartir mis proyectos es una forma de devolver una pequeña parte de todo lo que la comunidad me ha enseñado durante estos años.

Mirando hacia el futuro, mi intención no es solamente aumentar el número de repositorios. Quiero que OIHEC Labs se convierta en un laboratorio donde pueda experimentar con inteligencia artificial aplicada a la ciberseguridad, análisis de malware, automatización de SOC, herramientas de respuesta a incidentes, investigación sobre protocolos emergentes y nuevas plataformas de monitoreo. Me interesa desarrollar software que no solo resuelva problemas actuales, sino que también sirva como material de aprendizaje para la siguiente generación de investigadores.

Al final, cuando cierro el editor de código después de una larga jornada, no siento que simplemente haya programado otra herramienta. Siento que entendí un poco mejor cómo funciona Internet, cómo se comunican los sistemas y cómo podemos construir tecnología más eficiente, más transparente y más accesible. Ese aprendizaje constante es el verdadero motor de OIHEC Labs y la razón por la que seguiré publicando código abierto mientras tenga una nueva idea que explorar.