Full Kill-Chain.
Realistic OPSEC.
Goal-driven adversary operations against your production environment. Designed and executed under TIBER-EU, CBEST and CREST CHECK conventions, scored against the MITRE ATT&CK Enterprise matrix, and delivered with a kill-chain narrative your SOC can replay against telemetry.
- Full kill chain
- initial access to objective
- Per-engagement C2
- no shared infrastructure
- Purple-team replay
- you keep the detections
- 60 days
- free retest window
Service overview
A red team engagement is not a deeper penetration test. The unit of measurement is the objective: a specified, business-meaningful outcome that an attacker would care about — exfiltrating the production customer database, signing a payment from a finance-team account, reaching a named industrial controller, or maintaining undetected access for a quarter. The technical findings are evidence; the headline result is whether the objective was reached, how long it took, and where in the kill chain the defenders had a credible chance to stop it but did not.
Every engagement is scoped against the cyber kill chain (Lockheed Martin's seven-stage model) and reported against the MITRE ATT&CK Enterprise matrix. The IBM Cost of a Data Breach Report 2024 puts the average global breach lifecycle — time to identify plus time to contain — at 258 days. The point of the exercise is to compress that number. Our deliverables tell you, technique by technique, where your detections fired, where they should have fired but did not, and what telemetry you would need to acquire or tune to close each gap.
We run engagements under realistic OPSEC. Infrastructure is built per-engagement: dedicated redirectors, freshly-aged C2 domains, payloads compiled and tested against your specific EDR build before deployment. Operator activity is timed against the target's working hours and traffic baseline. Coordination with your white team — usually the CISO plus head of legal plus one nominated incident contact — happens through an out-of-band channel agreed in the engagement letter, with a documented kill-switch and authorisation envelope every operator can produce on demand.
Scope
In scope by default
Internet-facing infrastructure and applications, third-party SaaS holding the target objective (with that vendor's written consent), corporate identity and email tenant, employee endpoints and the standard golden image, internal Active Directory, cloud control planes (AWS / Azure / GCP), and any privileged-access workstation supporting the named objective.
Social engineering
Spear-phishing, vishing of named roles, OAuth consent grants, MFA-fatigue and helpdesk impersonation. Limits, target lists and post-action de-brief obligations are written into the Rules of Engagement before kickoff.
Physical (on request)
Tailgating, badge cloning, USB drops, after-hours building access. Always paired with an authorisation letter that any operator can present on demand. Out of scope for engagements where building security is not part of the threat model.
Out of scope
Disruption of customer-facing services, destructive payloads against production, real exfiltration of regulated data (we use canary tokens and staged objects), and any action against assets not owned by the engaging entity unless explicit third-party authorisation has been obtained in writing.
Methodology — full kill chain
Six phases mapped to the Lockheed Martin Cyber Kill Chain and the MITRE ATT&CK Enterprise matrix. White-team coordination, operator logging and OPSEC checkpoints run continuously across all phases.
Deliverables
A single PDF report (typically 80–150 pages) plus operator-action logs and detection content. Every claim in the report is backed by a timestamped log entry the white team can verify.
Day 4 — 14:07 IST
Phase: Lateral movement
ATT&CK: T1558.003 Kerberoasting -> T1003.001 LSASS dump (via T1059.001 PowerShell)
Source: WS-FIN-027 (compromised via Day 2 spear-phish, see entry 2.4)
Action: Requested service ticket for svc_sql.prod, cracked offline in 38 min.
Result: Compromised svc_sql.prod, member of Domain Admins via nested group.
Detection signal: Sysmon EID 4769 with weak encryption flag — telemetry present in
Splunk index 'wineventlog' but no detection rule active. Recommended Sigma rule
'win_susp_kerberoast_request' shipped in detection-pack appendix B.Frameworks & standards
Engagement timeline
Calendar weeks for a typical eight-to-twelve-week mid-market engagement. TIBER-EU and CBEST engagements add four-to-eight weeks for the threat-intelligence preamble and regulator coordination.
Frequently asked questions
How is a red team engagement different from a penetration test?+
A penetration test enumerates and exploits vulnerabilities within a defined technical scope on a known schedule with the defenders aware. A red team operation is goal-driven: a specified objective (e.g. exfiltrate the customer database, sign a payment from the CFO's account, reach a specific OT controller) pursued under realistic OPSEC constraints, with only a small white team aware that the activity is authorised. The point is to test detection and response, not just preventive controls.
Who needs to be informed inside our organisation?+
A white team — typically the CISO, head of legal, and one trusted operational contact — holds the engagement letter, the Rules of Engagement and the kill-switch protocol. Nobody in the SOC, IT, or business units is told. This is what makes the detection data meaningful. We provide a sealed envelope or signed authorisation letter that any AxVeil operator can produce on demand if challenged by law enforcement, building security or an internal investigation.
What OPSEC controls do AxVeil operators apply?+
Dedicated per-engagement infrastructure (no shared C2 redirectors, no recycled domains), domain fronting or CDN-backed C2 channels where the threat model warrants it, payloads built fresh for each engagement and tested against current EDR signatures in a private detonation lab, traffic profiles tuned to blend with the target's baseline, hands-off-keyboard hours that match the target's working timezone, and full operator-action logging so every command can be replayed during the debrief.
How do you avoid causing real damage during exploitation?+
Destructive actions — encryption, mass deletion, payment authorisation — are simulated, not executed. Where impact must be demonstrated, we stage benign canary files, write timestamped marker objects to non-production paths, or capture sufficient credentials and screenshots to prove the action was reachable. Anything that could affect customer data, regulatory state or financial transactions requires written sign-off from the white team in the engagement letter.
Do you support TIBER-EU and CBEST engagements?+
Yes. For TIBER-EU we work alongside an accredited Threat Intelligence Provider to produce a Targeted Threat Intelligence (TTI) report, then execute the Red Team Test Plan under the supervision of the relevant national TIBER cyber team. For Bank of England CBEST engagements we coordinate with the firm's Control Group and produce the prescribed CBEST deliverables. Both require lead operators with current CREST CCRTS or equivalent registration, which we confirm in the proposal.
What does a golden-image and payload-channel test look like?+
We run a dedicated phase against your standard Windows / macOS / Linux build to confirm what an attacker sees on a freshly-imaged corporate endpoint: AppLocker / WDAC bypasses, EDR coverage gaps, lateral-movement primitives, credential cache exposure. Payload delivery is exercised through every realistic channel — spear-phishing with weaponised Office and PDF documents, OAuth consent abuse, removable-media drops, supply-chain package upload, watering-hole, and social engineering of the helpdesk for MFA reset.
Request a red team engagement
Send the candidate objective, the regulatory framework you operate under, and the names you nominate for the white team. We respond with a fixed-fee proposal, lead-operator biography and a sample report excerpt under NDA.
Start the conversation →