Introducing Joro: Using AI to Build Security Tooling

TL;DR Recently I used AI-assisted development to build a complete web exploitation framework called Joro, tailored to how we (and many other teams) run engagements. Throughout the development of this tool, I encountered the ups and downs of leveraging frontier AI models to build security tooling and wanted to share my experiences along the way.

Introducing Joro

Joro is a collaborative web exploitation framework for offensive security professionals. It includes features such as an intercepting proxy, out-of-band callbacks for blind vulnerability detection, authenticated web shell generation, and C2 integration. These are backed by various collaboration tools wrapped in a single binary with an embedded web UI, enabling practical team-based assessments of web applications that can smoothly transition into testing of internal networks.

Check out the project at https://github.com/BishopFox/joro!

Here’s the backstory:

A New Era

Every week there’s a new headline about the latest advancements in AI and how the industry is cooked. While most of these posts are written to farm engagement without any real weight behind the claims, you can’t help but wonder - is AI really taking over the world? The answer is… kind of, but not in the way that headlines suggest.

Information security has always been a rapidly changing field. With each new breakthrough in technology, however, the reactions rarely change. Hype. Doubt. Fear. Denial. Acceptance. Adoption. The current AI news cycles are no different. As I doom-scrolled X, I found myself in a position common to most: forming opinions against a technology I hadn’t personally used.

Barriers to entry (or lack thereof)

A few years ago (or even months ago), building an entire web exploitation framework from scratch would have been a daunting task. Writing thousands of lines of code and integrating seamlessly with applications written in various other languages would be a significant time sink for anyone (even given that they know the languages to begin with). This is where AI is now extremely good.

Joro started off as a spinoff of a script we previously used to generate web shells. I originally wrote it to improve upon this script by taking web shells in various languages, obfuscating them uniquely each run, and directly facilitating execution through a CLI. Created before many LLMs were around, it was low in complexity and did its job.

When I decided to overhaul the project, I started with a simple prompt, something along the lines of:

```

I want to convert Joro into a web application. Keep the backend written in Go and use TypeScript for the frontend.

```

The scaffolding of the project almost felt magical, because that’s all it took. Being self-taught in Go and knowing very little about frontend development, I was blown away by how quickly the initial result was created. It just worked.

There were several issues along the way, however. The obvious first step was to get rid of the typical vibe-coded color palette; I had to be specific about the intended design and provided our own brand-focused colors. Next came the proxy integration as well as various forms of out-of-band callback support (both custom and third-party). These all worked well, but again, with each iteration came subtle errors or unintended “features” until everything finally fit into place.

Why build something that already exists?

Let me get this out of the way: the commercial intercepting proxy offerings on the market are great. I use them every day and they are very good at what they were built to do. When approaching the goal of using AI to build security tooling as a learning experiment, I needed a project that was large in scope, and which incorporated workflows that are familiar to what I do day-to-day.

As a Cosmos Operator, this involves performing continuous testing of public-facing attack surfaces for our clients. This includes carrying out full attack chains; starting from leads as small as an exposed configuration file and sometimes continuing the attack path all the way to complete internal domain compromise.

While most intercepting proxy offerings are suitable for intercepting web traffic, manipulating requests, and supporting several other web-exploitation-focused tasks, they are often lacking integration with other tools necessary for continuation of attack paths after the initial discovery of a vulnerability (such as web shell generation/execution or interaction with C2 frameworks). While many projects offer plugin support (Joro included), these often introduce their own barriers and are difficult to integrate cleanly.

Managing Expectations

I continued to iterate and felt like a kid watching a magic trick for the first time. Intercepting proxy functionality and third-party packages integrated effortlessly. Team server features, custom settings and more came together piece-by-piece, prompt-by-prompt. AI really was something special (when it was guided properly within strict constraints).

The honeymoon phase ended quickly when I was adding the Sliver integration. This would allow Operators to control implant sessions directly from Joro’s UI, providing a centralized application to carry out attacks from initial access through post-exploitation. Sliver uses gRPC with protobuf serialized messages for communication; if I were Joe Demesy, I would have had little problem integrating this by hand. Unfortunately, many of you would be unsurprised to hear that I am, in fact, not Joe Demesy.

I prompted the model to build the integration. “Make no mistakes”, I (should have) said, as it secretly made mistakes in real time.

While the integration initially appeared functional, I was encountering RPC errors when connecting to the Sliver server from within the Joro UI. After digging into the issue, I discovered that the model had hallucinated field numbers that seemed right but were not what the server expected. Surprisingly enough, after identifying the issue and prompting the model, it had no problem fixing its own mistake.

This experience was shared several times throughout the development of the tool. It became very clear that despite all the noise around AI, a human in the loop is necessary for building anything semi-complex. That said, it is an extremely useful tool as a force multiplier when given direction and monitored closely for any deviations from expected output.

Conclusion

Overall, going from being unfamiliar with AI to building a security tool like Joro almost completely with AI has been enlightening. Despite the various mistakes that were caught throughout development, I have been using Joro almost exclusively now in day-to-day workflows. So, while the industry certainly isn’t cooked, the use of AI has absolutely been a game changer in building a tool that would otherwise seem far out of reach.