Offensive engagement / 08

Pentesting and Red-Teaming.

Evidence, from controlled attack, of what an adversary could reach in your organization and whether your defenders would stop them.

Nineteen services in eight categories, from an external penetration test to an intelligence-led red team run against live production. They are organized by attack surface and engagement depth, the way a real adversary works: probe an asset for a weakness, chain weaknesses into a path, then pursue an objective.

Every test runs on an agreed scope, explicit authorization and rules of engagement. Destructive actions and denial of service stay out unless you approve them, and exploitation proves impact without causing damage.

REQUEST AN ENGAGEMENT → See all solutions

19 Services in eight categories

1-6 weeks Typical penetration test, from small to enterprise scope

Authorized Only assets you explicitly approve are tested

TIBER-EU With CBEST, the model followed for threat-led red teaming

[ FOR EVERY TEST ]

Three commitments hold across all nineteen services.

The scope, the duration and the method change with the service. These three do not.

A

Depth matched to the question

Services are organized by attack surface and by engagement depth. At one end an asset is probed for exploitable weaknesses; at the other a complete, intelligence-led campaign is emulated. The scope buys the depth the question needs.

What it changes

The test is fitted to the question, not the question to the test.

B

Impact proven, damage avoided

Vulnerabilities are confirmed by controlled exploitation. Destructive actions and denial of service are out of scope unless approved, data exfiltration in a red team is simulated, and operations pause if a system shows instability.

What it changes

The risk is demonstrated without an outage.

C

Findings you can act on

Every finding carries an impact assessment and step-by-step remediation guidance. Developer-facing tests add reproduction steps and code references, and identity and adversary work adds detection guidance mapped to MITRE ATT&CK.

What it changes

A report that goes straight into a fix backlog and a detection queue.

Testing by attack surface

Twelve services, each aimed at one place an attacker looks.

Infrastructure, applications, wireless, containers and people are tested as separate attack surfaces. Durations are typical ranges from small to large scope.

01 / INFRASTRUCTURE TESTING

Identify and validate the weaknesses an attacker would use to gain and expand access across networks, cloud estate and identity systems.

External penetration test Adversary-style testing of the Internet-facing perimeter, from reconnaissance to controlled exploitation, to show the realistic paths to initial access.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 4 to 6 large.

Internal infrastructure penetration test Testing from inside the network, unauthenticated or from standard-user credentials, to show how an attacker escalates privilege, moves laterally and reaches Active Directory and the most sensitive systems.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 4 to 6 large.

Cloud penetration test Configuration review and active testing of AWS, Azure and Google Cloud, focused on identity and access management and on the cloud-native paths that chain misconfigurations into privilege escalation.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 4 to 5 large.

Active Directory and identity security assessment Attack-path mapping and configuration review of Active Directory, Entra ID and the trust between them: tiering, Kerberos delegation, certificate services, credential hygiene and legacy protocols. Findings map to MITRE ATT&CK.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 4 to 5 large.

02 / APPLICATION AND API TESTING

Assess the application and API attack surface where most modern breaches originate, combining deep manual testing with source-level analysis.

Web application penetration test Authenticated and unauthenticated testing of web applications, their APIs and the cloud infrastructure behind them, from injection and authentication flaws to business-logic abuse that scanners miss. Each application is sized individually.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 4 to 5 large.

Mobile application penetration test iOS and Android testing aligned to the OWASP MASTG and Mobile Top 10: static analysis, runtime analysis on instrumented devices, and the backend APIs the app depends on.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 4 to 5 large.

API security testing REST and GraphQL testing against the OWASP API Security Top 10, with depth on broken object-level and function-level authorization across roles.Typical duration: about 1 week small, 2 weeks medium, 3 to 4 large.

Security code review Manual and automated review of source code for injection flaws, hardcoded secrets, weak cryptography and access-control errors, with file and line references and a re-review of critical fixes.Typical duration: about 1 week for a small codebase, 2 to 3 medium, 4 or more large.

03 / WIRELESS AND NETWORK TESTING

Evaluate the wireless attack surface that extends beyond your physical boundaries, and the segmentation that should contain it.

Wireless security assessment An onsite assessment of authentication and encryption, rogue and evil-twin access points, client-side attacks, and whether guest, corporate and operational networks are properly segmented.Typical duration: about 1 week small, 2 weeks medium, 3 to 4 large.

04 / CLOUD-NATIVE AND CONTAINER SECURITY

Secure the containerized workloads and orchestration platforms that power modern cloud-native applications.

Container and Kubernetes security assessment Cluster configuration review against the CIS Kubernetes Benchmark, image and supply-chain analysis, and, where authorized, container-escape, service-account abuse and lateral-movement testing.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 4 to 5 large.

05 / HUMAN-FOCUSED TESTING

Measure and improve your team’s resilience against the human-focused attacks that remain a leading cause of breaches.

Phishing simulation campaigns Safe, controlled email simulations with scenarios tailored to your context. They measure open, click, data-entry and reporting rates and your phish-prone percentage, with no malware or harmful payloads.Typical duration: about 2 weeks small, 4 medium, 6 large. Domain registration and sender warm-up can add lead time before launch.

Social engineering Vishing, smishing and pretexting grounded in reconnaissance of your organization, and, where in scope and under a signed letter of authorization, physical intrusion such as tailgating.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 3 to 4 large.

06 / Adversary simulation

Four ways to test whether you would stop a real attacker.

Finding vulnerabilities shows what could be exploited. Adversary simulation shows whether your people, processes and technology detect and respond, at the depth your maturity requires.

STARTS INSIDE

Assumed breach

How far does an intruder get once past the perimeter? Starting from a standard user account or a planted foothold, the team escalates and moves laterally toward agreed objectives. Run overtly for coverage, or with limited defender awareness to gauge detection.

1 to 2 weeks small, 2 to 3 medium, 3 to 4 large.

COLLABORATIVE

Purple team

Do your detections work, and can the gaps be closed today? Offensive specialists run ATT&CK-mapped techniques in the open beside your defenders, confirm telemetry, alerts and response for each, and tune on the spot.

1 to 2 weeks small, 2 to 3 medium, 3 to 4 large.

COVERT

Red team

Would a stealthy attacker be detected and stopped? A goal-driven simulation of an advanced persistent threat that pursues agreed objectives without being caught, across technical, human and, where in scope, physical vectors.

4 to 6 weeks assumed breach, 6 to 8 full black box, 2 to 3 months for an extended campaign.

INTELLIGENCE-LED

Threat-led red teaming

Can you withstand the actors that target you, to a regulator’s standard? Bespoke threat intelligence drives the whole operation against live production under a control group, following the TIBER-EU and CBEST model.

6 to 10 weeks standard. Framework-aligned engagements typically run several months.

Red team and threat-led engagements follow the attack chain: reconnaissance, initial access, persistence and evasion, lateral movement and privilege escalation, actions on objectives, then analysis and debrief. Offensive infrastructure, aged domains and sender warm-up can add lead time before active operations begin.

Supply chain and continuous assessment

Test what you inherit, and keep measuring what you expose.

Three services cover the risk that arrives through suppliers and the exposure that builds between point-in-time tests.

07 / SUPPLY CHAIN AND THIRD PARTY

Understand and reduce the risk that reaches your organization through vendors, dependencies and integrations.

Supply-chain and third-party security testing Mapping and testing of the integrations, vendor-managed assets, software dependencies and trust relationships that give an attacker a path in without breaching you directly. A supplier’s own infrastructure is tested only with that supplier’s written authorization.Typical duration: 1 to 2 weeks small, 2 to 3 medium, 4 to 5 large.

08 / CONTINUOUS ASSESSMENT

Maintain ongoing visibility of your attack surface with fast, repeatable assessment and managed vulnerability programs.

Vulnerability scanning Automated discovery of known weaknesses and misconfigurations across external, internal and cloud assets. False positives are removed and findings are ranked by risk and business context. Scans use safe checks and do not exploit vulnerabilities.Typical duration: 2 to 3 days small, about 1 week medium, about 2 weeks large.

Vulnerability management as a service Scanning turned into a managed program: recurring authenticated and unauthenticated scans, expert triage, remediation tracking against agreed service levels and trend reporting, typically monthly or quarterly.Onboarding takes 2 to 4 weeks, then the service runs continuously for the agreed term.

How a test runs

Five phases, from scope approval to debrief.

The infrastructure and application penetration tests share this sequence. Cloud, mobile, API, container, code review and identity work keep its shape and replace the middle steps with their own, such as static and runtime analysis for mobile or IAM review for cloud.

STEP 01

Plan and reconnoiter

Objectives, scope approval and starting position are agreed. Reconnaissance then collects intelligence on the targets: network ranges, domains, applications and public information.

STEP 02

Scan and enumerate

Tools and manual technique find open ports, services and vulnerabilities, and enumerate systems and accounts to identify entry points.

STEP 03

Exploit

Identified vulnerabilities are exploited in a controlled manner to gain access or demonstrate impact. Privilege escalation and pivoting happen only where the scope allows.

STEP 04

Post-exploitation

Where access is gained, sample data is reached or persistence is shown to illustrate the extent of the compromise, within the agreed limits.

STEP 05

Report and debrief

Findings and attack paths are documented in a detailed report, then explained in a debrief covering impact and recommended fixes.

Deliverables

A report to act on, and a session to walk through it.

What the report contains depends on the service. These are the parts you can expect, and where each one applies.

Test report Each finding with evidence, impact assessment and step-by-step remediation guidance. Mobile, API and code review reports add developer-oriented detail: reproduction steps, file and line references and OWASP references.

Executive summary A management summary of risk and the most critical exposures, with mappings to compliance frameworks where required.

Debrief and Q&A The consultants walk your team through the findings, answer questions and clarify remediation.

Retest One retest of critical findings after you apply fixes, within a year, on the external, internal, cloud, web, mobile, API and container tests. A full retest of every finding is available as an add-on.

Attack paths Identity, cloud, assumed-breach and adversary work adds attack-path diagrams or a step-by-step narrative of how each objective was reached.

Detection guidance Identity, assumed-breach, purple team and red team work adds ATT&CK-mapped findings and detection guidance: a coverage matrix, new or tuned detections, and the indicators of compromise your defenders need to validate what they saw.

Bundles and add-ons

Services combined to answer one assurance question.

Attackers chain weaknesses across applications, identity, cloud and people, so testing one surface alone gives narrow assurance. Each bundle pairs services around a single question, and any combination of two or more can be built as a custom bundle.

Attack Surface Reduction For cloud-first organizations and those consolidating identity providers, concerned about initial access and lateral movement. It answers whether the external, cloud and identity attack surface can be easily exploited.Includes: external penetration test, cloud penetration test, Active Directory and identity security assessment.

Application Security For product and engineering teams shipping web, mobile and API-driven applications who want security built in, not bolted on. It answers whether the stack, from source code to running APIs, resists real-world attack.Includes: web application penetration test, mobile application penetration test, API security testing, security code review.

Adversary Readiness For security-mature organizations that want to know whether their people, processes and technology would detect and stop a real attacker. It answers whether detection and response work against a goal-driven adversary.Includes: assumed-breach assessment, red team, purple team exercise.

Human Risk For organizations whose greatest residual risk is their people, and who want a measured baseline and targeted improvement. It answers whether staff and processes resist multi-channel social engineering.Includes: phishing simulation campaigns, social engineering, targeted awareness sessions.

Cloud-Native Security For engineering organizations running containerized, Kubernetes-based workloads in the cloud. It answers whether the cloud platform and the workloads on it are both defensible.Includes: cloud penetration test, container and Kubernetes security assessment.

Continuous Assurance For organizations that need ongoing visibility and evidence of attack-surface management rather than a one-off snapshot. It answers whether exposure is continuously found, prioritized and driven down.Includes: vulnerability management as a service, recurring external penetration test, periodic cloud penetration test.

ADD-ONS TO ANY ENGAGEMENT

Full retest and remediation validation of every finding
Custom reporting and executive briefings
Compliance mapping to PCI DSS, ISO 27001, SOC 2 or regional requirements
Detection engineering hand-off, mapped to MITRE ATT&CK
Extended OSINT and attack-surface discovery, including leaked-credential research
Onsite delivery where physical presence or data residency requires it

Who this is for

Where the call usually comes from.

Attack surface worries Cloud-first organizations and teams consolidating identity providers, concerned about initial access and lateral movement.

Applications shipping Product and engineering teams releasing web, mobile and API-driven applications who want security built in.

Detection confidence Security-mature teams that want to know whether their people, processes and technology would stop a real attacker.

Independent evidence Regulated organizations, including financial institutions working to TIBER-EU or CBEST, and anyone who needs independent test evidence for PCI DSS, ISO 27001 or SOC 2.

What is needed to scope it

Four answers are enough to scope it.

Assets What is in scope: IP ranges and hosts, applications and APIs, cloud accounts, clusters, sites or users, depending on the service.

Starting position Unauthenticated, standard-user credentials or a planted foothold, and whether the test is overt or run with limited defender awareness.

Objectives What a result should show: specific systems or data, domain-administrator control, or conformance to a framework such as TIBER-EU.

Access and timing Test accounts, documentation and source code where available, and the windows in which testing may run.

Scoping starts with a conversation, not a questionnaire. When none of the standard services fits the question, a custom scope or bundle is designed for it.

REQUEST AN ENGAGEMENT → Three-page brief (PDF)

NEXT / RELATED SERVICE

Cyber Defense Assurance Program

Monthly penetration testing inside a multi-year, threat-informed program.

NEXT / SCOPING

Engage

Describe the situation and the question the test has to answer.