Choosing a command and control framework for a red team engagement is a decision that gets made far too casually in some organizations, often defaulting to whatever tool an individual operator personally prefers rather than what actually fits the client's environment, risk tolerance, and detection maturity. A mature red team treats framework selection as a governed decision with clear criteria, not a matter of personal preference, because the wrong choice can produce misleading results, trigger unnecessary incident response, or leave artifacts the client never agreed to. This post covers how that selection and governance process should actually work. This is the same evaluation discipline the red team at Sagefox Cybersecurity applies before any C2 framework is used in a client engagement.
Why Framework Selection Deserves a Formal Process
The Risk of Defaulting to Familiarity
Operators naturally gravitate toward the framework they know best, since familiarity speeds up execution and reduces operational mistakes. But familiarity alone is not a sufficient reason to select a framework for a given engagement. A tool an operator knows well may still be a poor fit if it produces network artifacts that violate the client's stated scope, generates unexpected load on production systems, or leaves behind persistence mechanisms the client's teardown process was never designed to handle.
What Happens When Selection Skips Proper Vetting
- Detection signatures for a poorly vetted framework may already be public, meaning the client's SOC identifies the activity immediately and the exercise stops being a useful test of real detection capability
- Some frameworks generate more aggressive default behavior than a client's infrastructure can tolerate, risking service disruption on production systems
- Licensing terms on certain frameworks may conflict with a firm's contractual obligations to a specific client, particularly in regulated industries
- Inconsistent framework choice across engagements makes it harder to build institutional detection engineering guidance for clients afterward
Criteria for Evaluating a C2 Framework Before Use
Alignment with the Engagement's Actual Objective
Not every engagement calls for the same kind of framework. An engagement specifically designed to test a client's detection and response capability calls for a framework whose behavior is well understood and can be tuned to simulate a realistic adversary profile. An engagement focused purely on achieving a defined objective, such as reaching a specific data store, may prioritize a framework that minimizes operational noise over one designed to closely mimic a specific known threat actor's tradecraft.
Detection Footprint and Signature Maturity
Before any framework is approved for a client engagement, the red team lead should understand what public detection signatures and research already exist for that framework's default configuration. A framework with well-known default indicators may be appropriate for a detection-capability test specifically because it validates whether the client's tooling catches known-bad patterns, but the same framework would undermine an engagement meant to test whether custom, more evasive tradecraft could bypass existing controls.
Licensing, Support, and Legal Standing
Some C2 frameworks carry licensing terms that restrict commercial use, require attribution, or otherwise create legal exposure if used carelessly in a paid engagement. Reviewing licensing terms as part of the selection process, not after the fact, avoids putting the firm or the client in an awkward legal position.
Stability and Predictability Under Load
A framework that behaves unpredictably or has a history of causing instability on target systems is a poor choice for any engagement touching production infrastructure. Reviewing known issues, community-reported stability problems, and the framework's testing history against the operating systems present in the client's environment should happen before, not during, an active engagement.
Evaluation checklist template:
1. Does this framework's objective match the engagement type (detection test vs objective-based)?
2. What public detection research exists for its default configuration?
3. Does the license permit commercial, client-facing use without restriction?
4. What is the framework's documented stability history on the client's OS and patch levels?
5. Does the team have documented internal expertise operating this specific framework safely?Governance Requirements Before Deployment
Framework Approval as Part of the Rules of Engagement
The specific framework or frameworks approved for use should be documented explicitly within the rules of engagement, alongside the broader scoping details covering timing, target ranges, and data handling. This prevents an operator from substituting a different, unapproved framework mid-engagement without the client's knowledge, even if that substitution seems reasonable in the moment.
Documenting Configuration Choices, Not Just the Framework Name
Approving "framework X" without also documenting its specific configuration, such as beacon interval, jitter settings, and communication protocol, leaves too much room for variation between what was approved and what actually gets deployed. A thorough governance record specifies the configuration profile alongside the framework itself.
Approved configuration record:
Framework: [name, version]
Communication protocol: [HTTPS/DNS/other]
Beacon interval and jitter: [documented range]
Persistence mechanism: [documented, if any]
Approved by: [client security lead, engagement lead]
Date approved: [date]Change Control for Mid-Engagement Adjustments
If operational conditions require a change, such as switching communication protocols after unexpected network filtering is discovered, that change should go through the same lightweight approval process used for the original selection, logged with a timestamp and reason, rather than being made unilaterally by the operator in the field.
Testing and Validation Before Client Use
Internal Lab Validation
Any framework being introduced into a firm's operational toolkit for the first time should go through internal lab testing against a representative environment before it is ever used against a live client target. This surfaces stability issues, unexpected default behaviors, and configuration quirks in a controlled setting rather than during a billable engagement.
Building Internal Detection Baselines
Running the framework against the firm's own monitoring tools during lab validation, and documenting what does and does not get detected, gives the team a clear baseline understanding of the framework's actual stealth characteristics rather than relying on assumptions or outdated public research.
Lab validation checklist:
1. Deploy framework against isolated lab environment matching client OS baseline
2. Run standard EDR/AV product against the deployment to document detection behavior
3. Confirm cleanup and teardown process fully removes all artifacts
4. Document any unexpected crashes, instability, or resource consumption
5. Record findings in the firm's internal framework knowledge baseMaintaining a Framework Portfolio Rather Than a Single Default
Why One Framework Rarely Fits Every Engagement
Firms that standardize on a single C2 framework across every engagement eventually run into a client whose detection tooling already has strong signatures for that exact framework, undermining the value of the test. Maintaining a small, well-vetted portfolio of frameworks with different detection footprints and operational characteristics allows the team to select the right tool for each specific engagement rather than forcing every engagement through the same tool regardless of fit.
Periodically Reassessing the Portfolio
Detection research and defensive tooling evolve quickly, and a framework that was reasonably stealthy a year ago may now have well-documented signatures across major EDR platforms. Scheduling a periodic review of the firm's approved framework portfolio, retiring or reconfiguring tools that have become too well-signatured for detection-evasion engagements, keeps the portfolio genuinely useful rather than relying on outdated assumptions about what still works. This kind of ongoing internal review is part of how the operational toolkit at Sagefox Cybersecurity stays current against an evolving detection landscape.
Communicating Framework Choice to the Client
How Much Detail Clients Actually Need
Clients generally do not need or want a deep technical briefing on a specific C2 framework's internals before an engagement begins. What they need is confidence that the framework has been vetted, that its behavior is understood by the team operating it, and that its use falls within the documented rules of engagement. Over-explaining technical specifics can create noise without adding real value to the client relationship.
What Belongs in the Final Report
The final engagement report should describe, at an appropriate level of abstraction, what kind of command and control activity was used and what its detection characteristics revealed about the client's environment, without necessarily providing a step-by-step operational manual for the specific tool. The goal is giving the client's security team enough detail to build meaningful detection improvements, not publishing a tutorial.
Common Mistakes in Framework Selection and Governance
Choosing Based on Operator Preference Alone
Allowing individual operator familiarity to override a structured evaluation process leads to inconsistent engagement quality and occasionally mismatches between the framework's characteristics and what the specific engagement actually required.
Skipping Lab Validation for "Well-Known" Frameworks
Assuming a widely used, well-documented framework does not need internal validation before client use skips an important step, since the firm's own detection baseline and configuration choices may behave differently than what public documentation describes.
Failing to Document Configuration Alongside Framework Name
Approving a framework by name without documenting its specific configuration leaves too much room for interpretation and makes it harder to reconstruct exactly what happened during the engagement if a question arises afterward.
Never Retiring Frameworks From the Portfolio
Continuing to rely on a framework long after its detection footprint has become widely known and signatured produces engagements that no longer meaningfully test a client's detection capability, since the activity gets caught immediately regardless of operator skill.
Key Takeaways
Selecting and governing a C2 framework is a decision that deserves the same rigor applied to any other part of a red team engagement's planning. Matching the framework to the engagement's actual objective, documenting configuration choices alongside the framework name, validating behavior in a lab before client use, and maintaining a periodically reassessed portfolio together produce engagements that are safer, more defensible, and more genuinely useful to the client's security program than defaulting to whatever tool happens to be familiar.
If your organization is planning a red team engagement and wants a process built around this kind of deliberate, governed tool selection, the team at Sagefox Cybersecurity can walk through how engagements are scoped and structured before any technical work begins.
