In this blog, we want to do more than point at a new capability inside OST. We want to show how external researchers can bring their own tools into the platform, using InfraRED as a practical example of what that process can look like from both sides. InfraRED was created by Dominic Penn-Newman, and in this post we cover how the collaboration started, what it takes to turn a promising tool into something OST customers can rely on, and how Dominic experienced the process as the developer. Let’s go.
Why Do We Integrate External Projects Into OST?
Outflank Security Tooling (OST) is Outflank’s main product: a commercial offering designed to make life easier for red teams. OST brings together 30+ tools, a substantial knowledge base with 15k+ lines of documentation and 40+ hours of video content, and a closed community of more than 1,000 red teamers. Everything we build for OST is aimed at making our red teaming customers more effective and efficient, so they can deliver stronger engagements for their own customers.
Although the knowledge base and community are praised enormously, the core of OST is the tooling itself. The Outflank team now consists of 14 technical specialists, which gives us a significant R&D capability. At the same time, there are always great ideas, tools, and projects outside the Outflank team that we keep a close eye on.
One of those projects is InfraRED, created by Dominic Penn-Newman. InfraRED was built to remove much of the pain from red team infrastructure deployment through automation, flexibility, and structure, reducing the room for OPSEC mistakes. Dominic presented the project at x33fcon 2024, with the idea of doing a full release at a later stage. Back then, the project was called RedCommander.
After his talk, I approached him to discuss how closely the project aligned with our vision for OST. We are always open to external developers who want to bring their tooling into OST under a paid commercial arrangement, as we already do with several other non-Outflank researchers, for example Dirk-jan Mollema with his RoadTune tool that abuses insecurities in device compliance as enforced by Intune.
As the conversations continued, many ideas emerged: how the tool could be extended, how we could gather proper feedback from end-users, and how partnering with Outflank could put the tool directly into the hands of the audience it was built for: red teamers.
Scaling Up: Moving from Initial Discussions to Launch Day
What followed was a period in which we discussed Dominic’s commercial arrangement, the exact technical requirements, release cycles, development approach, and everything else needed to move from a promising project to a product-grade tool. These are many of the things researchers typically do not have to think of when they develop a single PoC or standalone tool.
People tend to forget that although it’s easy to make a tool or evasion PoC work in one specific niche case and setup, it’s a very different, much more challenging, and honestly quite a fun game to make it work reliably at scale.
That is also why we wanted to share this story publicly. Although InfraRED itself is part of the commercial OST offering (and thus will not be released as open source project), we think the route from external research project to production-grade tooling is relevant beyond this specific release.
If you are an offensive researcher and want to explore getting your tool or evasion PoC into the hands of OST red teamers, feel free to connect with me ([email protected]) so we can talk.
More about InfraRed’s Creator
InfraRed was designed and developed by Dominic Penn-Newman (aka Dom Mortimer). Dom’s background came from years as sysadmin before becoming a penetration tester and moving into red teaming. Over the years he and the teams he has built have taken an ‘automation and improvement first’ approach to red teaming. This requires relying on commercial tooling such as OST to provide a stable platform for operations whilst focusing internal development efforts on novel exploitation methods and designing tooling to support delivery. InfraRed saw years of service as an internal application before the final polish and release into OST. Feedback and improvement requests from the OST community and directly from real red team engagements continue to help define the road map and features of InfraRED.
What is InfraRED?
InfraRED is the final incarnation of a long-standing project spanning over five years. In the early days, huge amounts of our team’s time went on deploying, configuring and managing infrastructure ahead of engagements. That often ate into time that could have been spent on the “cool” bits of the planning and prep phases, such as research and development. With that in mind, I set about creating a series of automated scripts, handlers and pipelines, and anything else I could throw at it to make the process easier. This was sadly pre-AI, so I had to learn and implement it the old fashioned way. In the end an internal project called “redterra” was born, and it still forms the fundamental template and deployment core of the platform today. It was CLI driven, allowing simple infrastructure to be built via Terraform and Ansible, with an overlaying templating engine that let us reuse and version control our key infrastructure deployment configurations. This sped life up, but it was ultimately lacking, and so the concept for InfraRED was made.
The idea was “simple”: a unified platform that would let an operator control all deployed infrastructure, no matter where it lived. It needed to be modular, allowing resources to be deployed into whichever provider fit the use case or target profile. Beyond that it was to act as a centralising point for all deployment actions. This meant no more spreadsheets of random domains and their status, no operators each running their own scripts, and no unmanaged infrastructure sat forgotten in corners of the cloud, quietly racking up cost.
And so InfraRed was born:
Figure: InfraRED dashboard page showing a projects overview
Figure: InfraRED page showing information on used domains such as provider, expiry date and VT status
That core ethos has carried through to the latest product. Operators can manage DNS, infrastructure, and log sources and interact directly with key systems without having to wade through a mess of networks, cloud providers, and portals. The idea was refined further with linking and relationship systems, letting key variables and outputs from some resources pass cleanly into others, with the platform acting as overseer. This builds on the already solid foundations of Terraform and Ansible, but augments them with additional logic to align with the requirements of modern, secure red team infrastructure. The arrival of Tailscale and serverless functions opened up a new area to explore as well. The newest version supports AWS, Azure, Linode, and Fastly, allowing the deployment of complex, interconnected fleets of redirectors back to core C2 platforms. Building this alongside the Outflank team has allowed a greater focus on stability and a tighter linking of those products with the platform.
Figure: InfraRED page showing infra components of a project
Figure: InfraRED showing the relationship of infra components
When you actually sit down and use it, the process is straightforward. You create a project, pick the infrastructure you need, point it at a domain you already have in AWS or Azure, and hit deploy. The platform takes it from there: the servers get built, the networking gets configured, the C2 gets installed and started, the redirectors get pointed at it, and everything joins the same private network so it can all talk to each other securely without any of your core systems being exposed to the internet.
What used to take hours of manual work across multiple cloud consoles, SSH sessions and config files now takes minutes, and the end result is consistent every time because the same tested templates and playbooks are doing the heavy lifting underneath.
If something does go wrong, the build log is right there in the portal and each step retries automatically before failing out, so you are not left guessing what happened.
The other thing that took some time to get right was making sure the platform understood the relationship between infrastructure, not just the individual pieces. A redirector is useless unless it knows where to send traffic. A C2 server needs its profile URIs reflected in the nginx config in front of it. A CDN layer needs to know about the redirector behind it. In older workflows, stitching all of that together manually was where mistakes crept in, and where you often ended up with subtle misconfigurations that only surfaced mid-engagement.
InfraRED handles those relationships between infrastructure components at build time, so when you link a redirector to a teamserver, all that information flows through automatically. The platform knows what each piece needs from the others and makes sure it gets it before anything goes live.
There is also a side to the platform that goes beyond just building and managing infrastructure. Once an engagement is underway, operators can pull their C2 logs directly into the platform, build a running timeline of key events, and map actions against MITRE ATT&CK techniques as they go. At the end of the engagement that data is already organised and ready to feed into reporting, rather than sitting in raw log files that someone has to make sense of under deadline pressure. It is not the core product by any means, but it is the kind of feature that pays for itself the first time you use it.
Figure: InfraRED page showing operational logging mapped to MITRE ATT&CK
Figure: InfraRED dashboard page showing a projects overview (cont.)
Why the Right Process Makes the Right Product
Moving a product from an internal tool to one that serves hundreds of differing clients within a controlled framework was a really unique experience. Working with Outflank was a real eye opener: with UI and feature testing, streamlining, and generally far more eyes on the project not only as end users but also as developers. It gave me a superb training ground to refine the product and focus it into something that really could work for anyone. Throughout all of this, the team still worked hard not only to support the OST and Fortra products, but to give other teams the flexibility to take their existing deployment approaches and adapt them to work within InfraRED, without having to reinvent the wheel. That core ethos, which runs right through the whole OST ecosystem, is a big part of why I chose to work with them, and why I am a client myself.
The red teaming landscape seems to shift constantly, and teams are forced to adapt with it. Relying on paid, professional, tested tooling for the key areas lets us focus on the parts of an engagement that matter most. Spending more time on that fancy IA method or on a piece of exploit research is where the effort should go, not worrying about whether your C2 will stay alive long enough to see out the engagement, or whether you will even have time to stand up the infrastructure to deliver it.
The process of onboarding, controlling and releasing the product has been superb, too. The speed at which I can release, update, test, and ship to the end user is short, and the OST community members give great feedback that I can then use to keep reshaping the platform into what everyone wants.
I was asked, just after release, why I took this platform down the commercial route with Outflank rather than releasing it publicly, and in truth the answer is everything above.
Under Outflank’s guidance this project has been shaped into something better than one team, or one person, could ever have produced.
The knowledgeable OST community adds to that, and it keeps the product in a fully production ready state, without the risk of it disappearing into the ether as just another abandoned tool that everyone came to rely on.
Things to come
InfraRED launched with a stable set of initial providers and a real focus on stability and usability. As we have gathered feedback, and as the underlying tooling and services keep evolving, I want to be able to deliver those advances to operators. Tailscale’s product now allows for far more fine-grained network control, with separate tailnets opening the door to using multiple cloud tenancies at once, rather than a single tenant per provider. With InfraRED acting as the central controller, operators can apply specific controls and user access across every resource.
On top of that, the areas that have proved most useful to our reporting outputs and data handling, such as the OpCentre with its MITRE data mapping and timeline generation features, have been refined further. v1 of the tagging system is now due to land on domains as well, so you can catalogue and quickly identify the status and usage of records and domains within the platform.
The big push for the coming versions, though, is simply MORE. More DNS provider support, with a list including GoDaddy, Cloudflare, Linode, Digital Ocean and others, on top of bringing in more deployment systems such as phishing platforms. With the core platform complete and tested, adding these new features becomes straightforward, and that ability to adapt and extend the platform will not be limited to me. Plans are coming to let the community share and curate custom modules and deployments, so everyone can keep building on this foundation. With the advance of other platforms like Cobalt Strike, the upcoming Outflank C2 version 3, and more and more frameworks now offering API-based approaches as standard, the possibilities only keep opening up, and there is so much more to come.