Guardian Offensive Security Group
Guardian's offensive security practice runs scoped penetration tests, full-scope red team operations and collaborative purple team exercises against the same infrastructure you defend every day. Every engagement ends with a reproducible attack path, a prioritised remediation plan and detection content you can deploy.
Figures drawn from Guardian Offensive Security Group engagement telemetry, January 2024 – December 2025. Client identities are never disclosed.
Engagement types
Scope a single application or commission a multi-month campaign across the estate. Each engagement type has a fixed methodology, a defined deliverable set and a named technical lead who stays with you from kickoff to retest.
Full enumeration of the internet-facing perimeter: exposed services, forgotten subdomains, expired certificate hosts, VPN concentrators and edge appliances. We attempt authenticated pivots wherever credentials are obtained legitimately during the test window.
Typical duration 5–10 days · Grey box
Assumed-breach assessment from a standard corporate workstation or a network drop. Covers Active Directory attack paths, Kerberos abuse, relay and coercion, certificate services misconfiguration and flat-network lateral movement.
Typical duration 8–15 days · Assumed breach
Manual, business-logic-led testing aligned to the OWASP Testing Guide and ASVS Level 2. Authenticated multi-role coverage, tenant isolation checks and server-side request forgery chains against cloud metadata endpoints.
Typical duration 6–12 days · Authenticated
Schema-driven testing of REST, GraphQL and gRPC surfaces. Broken object-level authorisation, mass assignment, token replay, rate-limit bypass and service-to-service trust abuse inside the mesh.
Typical duration 5–10 days · Spec-informed
Configuration review plus live exploitation across AWS, Azure and Google Cloud: over-permissive roles, cross-account trust, public storage, exposed control planes, container escape and CI/CD pipeline poisoning.
Typical duration 7–14 days · Hybrid
iOS and Android binaries assessed against the OWASP MASVS: local storage exposure, certificate pinning bypass, jailbreak and root detection resilience, deep-link abuse and backend API authorisation.
Typical duration 6–10 days · Binary + backend
Targeted phishing, vishing, MFA-fatigue and help-desk pretexting campaigns run under strict rules of engagement. Measures both human susceptibility and the technical controls that should have contained the click.
Typical duration 3–8 days · Consent-gated
Badge cloning, tailgating, unattended-port access and rogue device placement, combined with wireless assessment of corporate WPA2/3-Enterprise, guest segregation and pre-shared-key hygiene.
Typical duration 3–6 days · On-site
Purdue-model-aware testing of industrial environments. Passive-first discovery, protocol analysis for Modbus, DNP3 and OPC UA, and safety-reviewed exploitation limited to levels 3 and above unless explicitly authorised.
Typical duration 10–20 days · Safety-gated
Every engagement is retested at no additional cost. Remediation verification within 90 days of report delivery is included in the base fee. You receive an updated report with each finding marked as resolved, partially resolved or unchanged, suitable for submission to auditors and customers.
Adversarial operations
A penetration test measures exposure. An adversarial operation measures your ability to notice and respond. Choose the posture that matches your programme's maturity — or run them in sequence over a twelve-month cycle.
A small cell of operators works against a written objective — "obtain and exfiltrate the customer master database", "execute a funds transfer from the treasury workstation", "gain persistent access to the manufacturing execution system" — with only your executive sponsor and a designated white cell aware that the operation is running.
Typical shape: 6–10 weeks, 2–4 operators, one written objective per 3-week phase.
Purple team engagements drop the secrecy. A Guardian operator executes a technique, your SOC watches the console, and together you determine whether the telemetry existed, whether a rule fired, and whether the alert was actionable. Failures are fixed the same day and re-tested before moving on.
Session format
Two-week sprint: 8–12 techniques executed per day across a chosen ATT&CK tactic, with a 30-minute tuning block after each block of four.
Deliverable
A signed-off detection matrix showing, per technique, whether coverage was absent, partial or complete before and after the exercise.
Content you keep
Every rule written during the engagement is handed over in Sigma and in native Guardian Sentinel detection syntax.
Best paired with
Managed detection and response, so tuned content is monitored by the same analysts who will triage it in production.
Adversary emulation reproduces the documented tradecraft of a specific threat group that is known to target your sector. Guardian Labs maintains emulation plans for 46 tracked groups; each plan is a sequenced list of techniques, tooling characteristics and infrastructure patterns derived from incident response casework and public reporting.
Financially motivated intrusion set specialising in payment switch manipulation. Emulation covers help-desk pretexting for MFA reset, Kerberoasting of service accounts, and staged SWIFT-adjacent host access.
38 techniques · 11 tactics · 4-week plan
State-aligned group targeting IT/OT boundaries. Emulation covers edge VPN exploitation, historian credential theft, and jump-host abuse to reach level 2 supervisory systems without touching controllers.
31 techniques · 9 tactics · 5-week plan
Supply-chain-focused actor. Emulation covers CI/CD token theft, malicious build-step injection, package registry impersonation and downstream tenant access through OAuth application consent.
27 techniques · 8 tactics · 3-week plan
Group names are Guardian Labs designations. Mapping to public aliases is provided under NDA as part of the engagement brief. Read the latest tracking notes on the threat intelligence page.
Methodology
Guardian's methodology aligns to PTES, the OWASP Testing Guide, NIST SP 800-115 and CREST assessment standards. Nothing about the process is improvised, and nothing happens outside the authorisation you sign.
We agree targets, exclusions, testing windows, escalation contacts and the legal authorisation to test. Third-party hosting providers are notified where their terms require it. Nothing starts without a countersigned rules-of-engagement document.
Passive collection of DNS records, certificate transparency logs, code repositories, job postings, breach corpora and cloud tenant metadata. The output is an asset inventory that regularly surprises the client — shadow infrastructure is the single most common source of external findings.
Active service discovery, technology fingerprinting and application crawling under agreed rate limits. Every host is catalogued with its owner, exposure and business function so that later findings carry real context.
Automated scanning is used only as an input. Each candidate issue is manually verified, false positives are discarded, and exploitability is assessed against the specific configuration in front of us rather than a generic CVE score.
Controlled exploitation to prove impact. Destructive techniques, denial of service and data modification are excluded by default. Every action is logged with a timestamp, source address and command transcript.
Privilege escalation, credential harvesting, lateral movement and access to the data that matters. We stop at the point where impact is demonstrated — we take a directory listing, not the database.
Draft report within five working days of test completion, technical debrief within ten, and a free remediation retest within ninety days. Critical findings are reported within four hours of discovery, not held back for the report.
Attack path reconstruction
Findings are never presented as an isolated list. Each critical issue is drawn as the chain of steps that produced it, with the control that should have broken the chain marked at every hop.
Emulation coverage
Every operation is planned and reported against MITRE ATT&CK. This is the standard coverage set for an enterprise red team engagement; emulation plans for a named threat group narrow it to that group's observed tradecraft.
| Tactic | Representative techniques exercised | Included in | Techniques |
|---|---|---|---|
| Reconnaissance | Search of open technical databases, certificate transparency mining, victim identity gathering from public code and job listings | Red team · External test | 6 |
| Initial access | Spear-phishing with attachment or link, exploitation of public-facing applications, valid accounts from credential-stuffing corpora, trusted-relationship abuse | Red team · Social engineering | 9 |
| Execution | Command and scripting interpreters, container administration commands, scheduled task execution, user-executed malicious file | Red team · Purple team | 11 |
| Persistence | Account manipulation, boot or logon autostart execution, valid cloud accounts, event-triggered execution, implant via scheduled task | Red team · Purple team | 14 |
| Privilege escalation | Abuse of elevation control, exploitation for privilege escalation, domain policy modification, access token manipulation | Red team · Internal test | 12 |
| Defence evasion | Impair defences, indicator removal, masquerading, reflective code loading, obfuscated files or information | Red team · Purple team | 17 |
| Credential access | OS credential dumping, Kerberoasting, adversary-in-the-middle coercion, MFA request generation, unsecured credentials in repositories | Red team · Internal test | 13 |
| Discovery | Domain trust discovery, cloud infrastructure discovery, permission group discovery, remote system discovery | All engagements | 10 |
| Lateral movement | Remote services over SMB and WinRM, pass-the-hash and pass-the-ticket, internal spear-phishing, taint shared content | Red team · Internal test | 8 |
| Collection | Data from information repositories, email collection, screen capture, staged archives on an intermediary host | Red team | 7 |
| Command and control | Application-layer protocol tunnelling, web service C2, domain fronting, encrypted channel with custom certificate | Red team · Adversary emulation | 9 |
| Exfiltration | Exfiltration over C2 channel, over web service, over alternative protocol, with size-limited transfer to defeat volumetric alerting | Red team · Adversary emulation | 6 |
| Impact | Simulated only. Ransomware staging, account access removal and data destruction are demonstrated in a sandboxed replica, never in production. | Tabletop extension | 4 |
Scroll the table horizontally to see every column.
Techniques marked as simulated are executed in an isolated environment provisioned by Guardian. See incident response for full ransomware readiness exercises.
Deliverables
Two audiences, one document. The first twelve pages are written for people who approve budget; everything after that is written for the people who will fix the problem, with enough detail to reproduce each finding without contacting us.
Three pages, written in plain business language. States what an attacker could achieve, how long it took, which controls worked, and the three changes that would most reduce risk. Includes a comparison against the previous assessment where one exists, so a board can see direction of travel rather than a snapshot.
Each successful chain is documented as a numbered sequence: the action taken, the observable it produced, the control that should have stopped it, and whether an alert was generated. Screenshots are redacted of live data but retain enough detail for your team to locate the same objects.
One page per finding, structured as: identifier, title, severity with the full CVSS 4.0 vector string, affected assets, business impact, technical detail, reproduction steps, remediation guidance and references. Findings are written so that an engineer who was not on the call can act on them alone.
Findings are grouped into fixes rather than listed individually — a single Active Directory tiering project may close eleven findings at once. Each item is plotted on an effort-versus-risk-reduction grid with an owner suggestion and a target date.
Machine-readable output: indicators of compromise from the operation, Sigma rules for every technique that went undetected, and ready-to-import Guardian Sentinel detection logic. Supplied as JSON and YAML alongside the PDF.
Delivered after remediation verification. Restates each original finding with a new status — resolved, partially resolved, risk accepted or unchanged — and is signed by the engagement lead. Suitable for submission to auditors, insurers and enterprise customers running vendor assurance.
Formats included in every engagement. PDF report, editable DOCX, a CSV finding register for your ticketing system, a board-ready slide deck, and the detection content pack. There is no additional charge for any deliverable format.
Scoring and triage
Guardian scores every finding with CVSS 4.0 and then adjusts for environmental reality: an unauthenticated remote code execution on an isolated lab host is not the same risk as the same bug on a payment gateway. Both scores appear in the report.
| Severity | CVSS 4.0 base | Disclosed to you | Recommended fix window |
|---|---|---|---|
| Critical | 9.0 – 10.0 | Within 4 hours of confirmation, by phone | 7 days, with compensating control same day |
| High | 7.0 – 8.9 | Within 24 hours, in the engagement channel | 30 days |
| Medium | 4.0 – 6.9 | In the draft report | 90 days |
| Low | 0.1 – 3.9 | In the draft report | Next planned maintenance cycle |
| Informational | 0.0 | In the appendix | Discretionary — hardening opportunities |
Aggregate finding profile
Distribution across 340 enterprise engagements completed in 2025. Most risk sits in the middle bands — and most breaches start there too.
| ID | Finding | Severity | Affected surface | Retest status |
|---|---|---|---|---|
| GDN-0114 | Unauthenticated deserialisation in the partner portal permits remote code execution | Critical | External web application | Resolved |
| GDN-0118 | Certificate template allows subject alternative name specification by any domain user | Critical | Active Directory Certificate Services | Resolved |
| GDN-0121 | Service accounts with SPNs configured use passwords under 20 characters | High | Identity infrastructure | Resolved |
| GDN-0126 | Cross-account IAM role trusts a wildcard principal in the analytics organisation unit | High | AWS production account | Partially resolved |
| GDN-0133 | Object-level authorisation missing on the invoice export endpoint permits tenant crossover | High | Billing API v3 | Resolved |
| GDN-0141 | SMB signing not enforced on 214 workstations, enabling NTLM relay | Medium | Corporate workstation fleet | Partially resolved |
| GDN-0147 | Build pipeline secrets readable by all repository collaborators | Medium | CI/CD platform | Resolved |
| GDN-0152 | Verbose error responses disclose framework version and stack traces | Low | Customer web portal | Risk accepted |
Scroll the table horizontally to see every column.
The people doing the work
The Offensive Security Group is 118 full-time operators across London, Austin, Singapore and Warsaw. No engagement is subcontracted. Every consultant holds at least one hands-on practical certification and spends 20% of their year on internal research that feeds Guardian Labs intelligence.
Guardian's red team reached our core banking replica in nine days using nothing but a helpdesk phone call and a certificate template we had forgotten about. That was uncomfortable, and it was exactly what we paid for. The retest four months later took them to day thirty-one without a foothold.
Read the full account in customer case studies, or see how the same findings feed a longer programme in security consulting.
Common questions
Standard scheduling is four to six weeks from signed statement of work. Retests and targeted application tests can usually start within ten working days. If you are in an active incident, contact incident response instead — that team mobilises within one hour.
Yes, and we do so on the majority of engagements — a test against a staging clone rarely reflects production identity, network policy or data. Destructive techniques are excluded by default, rate limits are agreed in advance, and a named engagement lead is reachable throughout the test window. For OT and safety-critical environments we run passive discovery first and require sign-off from the process safety owner before any active step.
The report package is built for assurance use. It includes an attestation letter naming the tester and their certifications, the scope statement, the methodology reference, and the retest addendum. Customers routinely submit it for PCI DSS requirement 11.4, ISO 27001 Annex A 8.8, SOC 2 CC7.1 and DORA threat-led penetration testing evidence. See compliance advisory for framework mapping.
You do. Engagement data is held in an isolated, encrypted tenant, is never used to train models, and is destroyed 90 days after the retest unless you ask us to retain it for trend analysis. Anonymised technique-level statistics may contribute to aggregate benchmarks, and never include client names, addresses or asset identifiers. Details are in trust and security.
No. Offensive engagements are sold and delivered independently of the platform, and a substantial share of our clients run competing tooling. If you do run Guardian Sentinel, the detection content pack imports directly and the purple team console shows technique coverage in real time — but that is a convenience, not a requirement.
Fixed fee per engagement, based on scoped consultant-days. There are no per-host or per-IP charges, and reporting, debriefs and the 90-day retest are included. Multi-test annual programmes are discounted and can be drawn down against a prepaid day pool. See pricing or talk to the team for an estimate.
Tell us what you are worried about losing. We will scope an engagement that tries to take it, and hand you the plan to make that impossible next time.