The problem with assumed breach engagements
Assumed breach is a pentest methodology where the attacker starts with an already-compromised internal position, simulating the scenario where an adversary has bypassed perimeter controls and established a foothold. The client grants you access to a machine on their network, and the assessment begins from there.
In practice, the logistics of that setup can introduce difficulties. You either need a physical laptop shipped to the client site, the client sending you a physical laptop, a VM spun up by their IT team (with all the configuration back-and-forth that implies), or a jump box you don't fully control. Every one of those options introduces friction, delays, and inconsistency. You end up spending time troubleshooting a client's environment before you've even started testing.
We wanted to offer an alternative that eliminate these difficulties entirely. The goal: hand the client a disk image, have them boot it on any hypervisor, and get a fully operational pentest workstation calling home automatically. No configuration on their end, no IT babysitting, no setup calls.
Rethinking how we deliver assumed breach scenarios
Every organization is different. Different network architecture, different security stack, different threat model, different risk appetite. When a client comes to us for an assumed breach assessment, our job is to simulate what a real adversary would do inside their specific environment; not run a generic checklist against a standardized setup.
That philosophy shapes everything we do, including how we build our tooling. This is why we started working on CYPFERVM.
Introducing CYPFERVM
CYPFERVM is a purpose-built penetration testing appliance we developed internally. It's a pre-configured VM image that a client simply boots on their hypervisor, and within minutes our team can access a secure, fully operational foothold inside the client's network, without requiring any IT involvement beyond running a virtual machine. Building our own deployment infrastructure gave us something none of the commercial options could: a consistent, client-agnostic, 100% customizable, immediately operational starting point that we fully control and that requires almost nothing from the client to deploy.
How it works
CYPFERVM is defined entirely as code using HashiCorp Packer. That means every tool installed, every service configured, every operational detail is explicit, versioned, and deliberately chosen; nothing is accidental. More importantly, it means the platform evolves. Each engagement informs the next version, and every release ships a more refined, more capable appliance than the one before it. Furthermore, each client deployment is completely isolated. Our infrastructure supports concurrent engagements across multiple clients simultaneously, with cryptographic separation between them.
Under the hood
It runs as a headless Debian system, consuming minimal resources on whatever hypervisor the client has available. CYPFERVM runs on a hardened Linux base and comes pre-loaded with the tools the security industry has relied on for years. The familiar stack is all there. What we've added is the integration layer that ties it together for operational deployment: persistent encrypted tunnels, a SOCKS5 proxy for routing assessment traffic through the client's own network segment, and a suite of custom tooling refined from years of experience. The foundation is proven technology. The implementation is entirely our own.
A foundation for more tailored engagements
The real value of having our own deployment infrastructure isn't just efficiency, it's flexibility. Because we control the entire stack, we can customize the deployment for engagements that require it. Custom engagements require custom tooling. Having built CYPFERVM ourselves means we can extend and adapt it to match the scope and goals of each client, rather than being constrained by what an off-the-shelf tool was designed to do.
Where CYPFERVM fits and where it doesn't
It's important to understand where assumed breach fits relative to a full red team engagement. Red team operations test the entire attack chain, from initial perimeter breach through to objective completion, conducted covertly against your live defenses. Assumed breach skips that first phase entirely. We start from the position of an attacker who is already inside and focus on what they can do from there: lateral movement, privilege escalation, and access to critical assets. CYPFERVM is built for that scenario specifically. If you are looking to perform a Red Team or a Detection Capability Assessment, we have other solutions tailored around your needs.
Closing thoughts
The assumed breach methodology is one of the highest-value assessments we offer. It answers the question that matters most after a security incident: how bad could it have gotten? But that question deserves a rigorous, tailored answer, not a templated one.
CYPFERVM exists because we believe the quality of an engagement should never be limited by deployment logistics. Getting our team into the right position, quickly and cleanly, is a prerequisite for doing the work well. Everything after that is expertise, and that's where our focus belongs, and where yours should be too when evaluating the results.
If you're considering an assumed breach assessment and want to understand how we'd approach your specific environment, we're happy to have that conversation.