// service-data.jsx — content for the six live service pages, keyed by slug. const SERVICES = { 'vapt': { tag: 'Full-scope testing', title: 'Penetration Testing.', lead: 'Full-scope, manual penetration testing across web, API, network, and identity in one coordinated engagement. We combine smaller findings into the path an attacker would take to your data, then prove it.', bullets: [ 'Web, API, external and internal network, Active Directory, cloud identity', 'Manual exploitation, chained across surfaces', 'Executive and technical reports, plus a full evidence pack', 'Free retest of every High and Critical within 90 days', ], mockupKind: 'vapt', stats: [ { v: '4', l: 'Surfaces per engagement', s: 'web, API, network, identity in one scope' }, { v: '15d', l: 'Median engagement', s: 'kickoff to final report' }, { v: '8 in 10', l: 'End in an exploit chain', s: 'individually low findings, chained' }, { v: '94%', l: 'Closed by retest', s: 'verified fixed within 90 days' }, ], vectorsTitle: 'One engagement across every surface an attacker would touch', vectorsSub: 'Testing one surface at a time misses the connections between them. Full-scope testing follows the path from an exposed service to the data that matters, across every boundary it crosses.', vectors: [ { id: 'PT-01', icon: 'globe', t: 'External network', d: 'Asset discovery beyond the list you give us, service enumeration, exposed authentication, and known-vulnerable software.' }, { id: 'PT-02', icon: 'code', t: 'Web and API', d: 'Authentication, authorization, injection, and business-logic flaws across every role and tenant.' }, { id: 'PT-03', icon: 'server', t: 'Internal network', d: 'Assumed-breach testing from a low-privilege foothold: lateral movement, privilege escalation, and the path to Domain Admin.' }, { id: 'PT-04', icon: 'fingerprint', t: 'Identity', d: 'Active Directory, Entra ID, federation, and the trust relationships between them.' }, { id: 'PT-05', icon: 'cloud', t: 'Cloud footprint', d: 'IAM roles, storage exposure, and the credentials your on-premise systems hold for the cloud.' }, { id: 'PT-06', icon: 'target', t: 'Exploit chaining', d: 'Findings combined across surfaces into a single, demonstrated path to business impact, with impact rated in your terms.' }, ], phases: [ { dur: 'Days 1–2', t: 'Scope and threat model', d: 'Asset inventory, roles, in-scope and out-of-scope boundaries, rules of engagement, emergency contacts.' }, { dur: 'Days 3–4', t: 'Reconnaissance', d: 'Public footprint, leaked credentials, exposed services, and shadow IT, collected into one asset ledger.' }, { dur: 'Days 5–12', t: 'Manual exploitation', d: 'Surface-by-surface testing, then chaining across them toward the agreed objectives.' }, { dur: 'Days 13–14', t: 'Reporting', d: 'Executive summary and per-finding technical report, written by the tester who found each issue.' }, { dur: 'Day 15', t: 'Readout and retest', d: 'Live walkthrough with your engineers. Free retest of every High and Critical within 90 days.' }, ], deliverables: [ { icon: 'layers', format: 'PDF + HTML', t: 'Executive summary', d: 'Attack narrative from first foothold to impact, risk by asset class, and regulatory exposure in plain language.' }, { icon: 'code', format: 'Markdown', t: 'Technical findings', d: 'Per finding: reproduction steps, evidence, root cause, remediation, and retest criteria.' }, { icon: 'terminal', format: 'cURL + Burp', t: 'Evidence pack', d: 'Burp project, cURL bundle, command transcripts, and screenshots so your team can reproduce every finding offline.' }, { icon: 'shield', format: 'CSV + JSON', t: 'Ticket export', d: 'Findings pre-formatted for Jira, Linear, or ServiceNow, with CVSS, CWE, and MITRE ATT&CK mappings.' }, { icon: 'check', format: 'Letter', t: 'Attestation letter', d: 'Compliance-ready letter referencing scope, methodology, and outcome for SOC 2, ISO 27001, PCI DSS, and HIPAA reviews.' }, ], faq: [ { q: 'How is this different from your web or cloud engagements?', a: 'Those go deep on one surface. This one covers all of them and connects the findings. If you have one critical application, choose a web engagement. If you want to know how an attacker gets from the internet to your data, choose this.' }, { q: 'Do you use scanners?', a: 'We use them to help with coverage, but every issue in the report was reproduced by hand by the tester who signs it. Nothing reaches your backlog unverified.' }, { q: 'Will testing disrupt production?', a: 'Enumeration is read-only. Exploitation is coordinated with your team, marked in logs, and uses reversible techniques. Destructive proofs of concept run against staging or isolated copies.' }, { q: 'How do you scope it?', a: 'A 30-minute call. We agree the surfaces, roles, and objectives, and send a fixed-fee statement of work within 48 hours. The price does not move unless the scope does.' }, ], closeTitle: 'Find out how far an attacker could get', closeBody: 'One engagement, every surface, and a report your engineers will use. Scoping takes a 30-minute call.', }, 'web': { tag: 'Application security', title: 'Web Application Pentesting.', lead: 'Manual testing for production web applications, including the business logic automated tools cannot reach. We combine low-severity findings into account takeover, access-control bypass, and cross-tenant exposure, the same way an attacker would.', bullets: [ 'OWASP ASVS Level 2/3 coverage as the baseline', 'Authenticated, multi-role, multi-tenant testing', 'Business logic, race conditions, and state-machine flaws', 'Free retest of every High and Critical within 90 days', ], mockupKind: 'web', stats: [ { v: '92%', l: 'Find chained exploits', s: 'beyond what SAST and DAST surface' }, { v: '14d', l: 'Median engagement', s: 'kickoff to draft report' }, { v: '0', l: 'False positives', s: 'every finding is reproduced by hand' }, { v: '4.8/5', l: 'Engineer rating', s: 'for report usefulness' }, ], vectorsTitle: 'Every layer of the request', vectorsSub: 'We test session state, cache layers, browser context, and the trust assumptions built into your authentication flow, as well as the parameters themselves.', vectors: [ { id: 'WEB-01', icon: 'lock', t: 'Authentication & session', d: 'OAuth flows, MFA bypass, JWT tampering, session fixation, token leakage to logs and analytics.' }, { id: 'WEB-02', icon: 'fingerprint', t: 'Authorization & multi-tenancy', d: 'Horizontal IDOR, vertical privilege escalation, tenant breakouts, SSRF into private cloud metadata.' }, { id: 'WEB-03', icon: 'code', t: 'Injection & rendering', d: 'SQLi, NoSQLi, server-side template injection, XSS variants, prototype pollution, deserialization.' }, { id: 'WEB-04', icon: 'refresh', t: 'Business logic', d: 'Coupon abuse, race-conditions on transactional endpoints, workflow skipping, anti-automation bypass.' }, { id: 'WEB-05', icon: 'globe', t: 'Browser & client', d: 'CSRF, CORS misconfiguration, postMessage abuse, clickjacking, supply-chain risk via third-party scripts.' }, { id: 'WEB-06', icon: 'server', t: 'Infrastructure exposure', d: 'Header analysis, debug endpoints, environment leakage, default credentials, exposed admin panels.' }, ], phases: [ { dur: 'Day 1', t: 'Scoping & threat model', d: 'Asset inventory, role matrix, in-scope endpoints, out-of-scope guardrails.' }, { dur: 'Days 2–3', t: 'Recon & mapping', d: 'Crawl, content discovery, JS analysis, parameter mining, framework fingerprinting.' }, { dur: 'Days 4–9', t: 'Manual exploitation', d: 'Authenticated testing across roles, chaining, pivoting, business-logic abuse.' }, { dur: 'Days 10–11', t: 'Reporting', d: 'Engineering replay packs and an executive summary, written by the tester who found the issues.' }, { dur: 'Day 12', t: 'Readout & retest', d: 'Live walkthrough with engineering. Free retest of every High and Critical within 90 days.' }, ], deliverables: [ { icon: 'layers', format: 'PDF + HTML', t: 'Executive summary', d: 'Risk narrative, board-ready language, mapped to business impact and regulatory exposure.' }, { icon: 'code', format: 'Markdown', t: 'Technical findings', d: 'Per finding: reproduction, evidence, root cause, remediation, and references, written for the engineer who has to fix it.' }, { icon: 'terminal', format: 'cURL + Burp', t: 'Replay pack', d: 'Burp project file, cURL bundle, and Postman collection so your team can reproduce every finding offline.' }, { icon: 'shield', format: 'JSON + CSV', t: 'SARIF + ticket export', d: 'Findings as SARIF for SAST tooling and pre-formatted Jira/Linear CSV for ingestion.' }, { icon: 'check', format: 'Letter', t: 'Attestation letter', d: 'Compliance-ready letter (SOC 2, PCI, HIPAA, ISO 27001) referencing scope, methodology and outcome.' }, ], faq: [ { q: 'Do you test in production or staging?', a: 'Both. Default is staging for destructive tests and production for read-only verification, but we adapt to whatever mirrors your real risk surface. Production tests are coordinated with your on-call and bracketed by IP allowlists.' }, { q: 'How do you handle authentication for SaaS apps with custom SSO?', a: 'We support SAML, OIDC, custom JWT issuers, magic links, and impersonation flows. We also build automated re-auth so testing tools maintain valid sessions across hour-long token windows.' }, { q: 'What does the free retest cover, and is there a time limit?', a: 'Within 90 days of the final report we retest every High and Critical finding plus a sample of Mediums, and update the attestation letter accordingly.' }, { q: 'Can you test single-page apps and complex client-side state?', a: 'Yes. We instrument the browser via Playwright/Puppeteer and CDP for tests that scanners cannot reach: WebSocket abuse, IndexedDB tampering, service-worker hijacking, in-memory secret extraction.' }, { q: 'How do you avoid breaking our analytics or polluting our database?', a: 'We use distinct test accounts and tagged payloads. Findings that mutate data are reproduced once, evidence captured, and rolled back. We coordinate with your team for any state changes that cannot be undone.' }, ], closeTitle: 'Ship with proof your app holds up', closeBody: 'Whether it is a pre-launch pentest, a SOC 2 cycle, or a new feature you want tested before release, we can scope it in a 30-minute call.', }, 'mobile': { tag: 'Application security', title: 'Mobile Application Pentesting.', lead: 'iOS and Android apps tested against OWASP MASVS. Static, dynamic, and runtime analysis on real devices, including jailbreak-detection bypass, SSL-pinning circumvention, and IPC abuse.', bullets: [ 'OWASP MASVS L1/L2 coverage on real devices', 'Static, dynamic, and runtime instrumentation (Frida, Objection)', 'Backend API tested in the same engagement', 'Reverse engineering of obfuscated and packed binaries', ], mockupKind: 'mobile', stats: [ { v: 'iOS', l: 'Real devices', s: 'iPhone 12+ on iOS 16/17, jailbroken and stock' }, { v: 'AOSP', l: 'Android coverage', s: 'Android 11–14, rooted and user builds' }, { v: '10d', l: 'Median engagement', s: 'one app, one platform' }, { v: '9 in 10', l: 'SSL pinning bypassed', s: 'plus jailbreak and root detection' }, ], vectorsTitle: 'Device, network, and backend', vectorsSub: 'Mobile apps are three attack surfaces stacked together: the device, the channel, and the API. We test all three in a single engagement.', vectors: [ { id: 'MOB-01', icon: 'lock', t: 'Storage & cryptography', d: 'Keychain/Keystore misuse, hardcoded keys, plaintext databases, biometric bypass, PIN re-derivation.' }, { id: 'MOB-02', icon: 'globe', t: 'Network & transport', d: 'SSL pinning bypass, cleartext fallbacks, certificate validation gaps, proxy detection circumvention.' }, { id: 'MOB-03', icon: 'fingerprint', t: 'Authentication & identity', d: 'OAuth flows, refresh-token storage, biometric integration, device-binding bypass.' }, { id: 'MOB-04', icon: 'code', t: 'Code & runtime', d: 'Reverse engineering, anti-debug bypass, jailbreak/root-detection bypass, hooking via Frida & Objection.' }, { id: 'MOB-05', icon: 'network', t: 'IPC & deeplinks', d: 'Intent fuzzing, exported activities, content provider abuse, custom URL scheme hijacking, App Links.' }, { id: 'MOB-06', icon: 'server', t: 'Backend API', d: 'The API that serves the app, tested against the OWASP API Top 10 and scoped to mobile-specific endpoints.' }, ], phases: [ { dur: 'Day 1', t: 'Scoping & build', d: 'Receive IPA/APK, define test devices, agree jailbreak/root posture and bypass exclusions.' }, { dur: 'Days 2–3', t: 'Static analysis', d: 'Decompile, secret scan, manifest review, dependency CVE check, control-flow review.' }, { dur: 'Days 4–8', t: 'Dynamic + runtime', d: 'Network MITM, Frida hooking, IPC fuzzing, storage inspection, biometric/PIN testing.' }, { dur: 'Day 9', t: 'Backend API testing', d: 'Mobile-specific endpoint testing by the same tester who found the on-device issues.' }, { dur: 'Day 10', t: 'Report & retest', d: 'Engineering replay pack (with annotated APK/IPA). Free retest of every High and Critical within 90 days.' }, ], deliverables: [ { icon: 'layers', format: 'PDF + HTML', t: 'Executive summary', d: 'Risk roll-up mapped to MASVS controls and store-policy implications.' }, { icon: 'code', format: 'Markdown', t: 'Technical findings', d: 'Per finding: code reference, screenshot, Frida snippet, remediation, MASVS mapping.' }, { icon: 'terminal', format: 'Frida + APK', t: 'Replay pack', d: 'Annotated APK/IPA, Frida scripts, and Objection commands to reproduce every dynamic finding.' }, { icon: 'shield', format: 'JSON', t: 'MobSF + SARIF export', d: 'MobSF-compatible JSON and SARIF for ingestion into your scanning pipeline.' }, { icon: 'check', format: 'Letter', t: 'Attestation letter', d: 'Compliance-ready letter for app-store reviews, banking regulators, and SOC 2.' }, ], faq: [ { q: 'Do you need a jailbroken/rooted device or can you test on stock?', a: 'Both. We use jailbroken/rooted devices to look at storage and runtime behavior deeply, but we always re-test critical findings on stock devices to confirm real-world exploitability.' }, { q: 'Can you bypass our jailbreak detection?', a: 'Almost always, which is exactly why we test it. We document the bypass and discuss with your team whether a stronger detection layer is worth the cost for your threat model.' }, { q: 'Do you test cross-platform frameworks like React Native and Flutter?', a: 'Yes. They have their own quirks (JS bundle extraction for React Native, snapshot files for Flutter) and we have testers with deep experience in each.' }, { q: 'Will the app be modified during testing?', a: 'Only on the test device, and only for instrumentation. Your distributed binary is never altered.' }, { q: 'How do you handle apps with strong DRM or attestation?', a: 'We coordinate with your team to allowlist test devices, use Play Integrity / DeviceCheck staging modes, or work from a debuggable build for portions where production attestation cannot be bypassed within scope.' }, ], closeTitle: 'Test the app your users install', closeBody: 'We test the app as it ships, on the devices your customers use, against the backend that serves it, all in one engagement and one report.', }, 'cloud': { tag: 'Infrastructure', title: 'Cloud Pentesting.', lead: 'AWS, Azure, GCP, and Kubernetes, tested against CIS benchmarks, the control planes, and the identity and access setup that ties everything together. We review the configuration, then actively exploit what we find.', bullets: [ 'AWS, Azure, GCP, OCI across compute, storage, identity, and network', 'Kubernetes: cluster, supply chain, runtime, CIS benchmark', 'IAM trust-graph analysis (PMapper, IAMSpy)', 'Demonstrated compromise chains, with the configuration changes to fix them', ], mockupKind: 'cloud', stats: [ { v: '4', l: 'Providers covered', s: 'AWS, Azure, GCP, OCI in one engagement' }, { v: 'CIS', l: 'Benchmark coverage', s: 'CIS Foundations plus service-specific' }, { v: '12d', l: 'Median engagement', s: 'one cloud, one Kubernetes cluster' }, { v: '80%+', l: 'Incidents start in IAM', s: 'so we graph trust before touching services' }, ], vectorsTitle: 'Cloud breaches start with identity', vectorsSub: 'More than 80% of cloud incidents start with a permissions issue. We map your trust relationships before we touch a single service.', vectors: [ { id: 'CLD-01', icon: 'fingerprint', t: 'IAM & identity', d: 'Role-assumption chains, cross-account trust, federation abuse, OIDC trust-policy flaws, service-principal sprawl.' }, { id: 'CLD-02', icon: 'kubernetes', t: 'Kubernetes', d: 'RBAC misconfiguration, pod escapes, supply-chain admission, cluster-admin paths, etcd exposure, node compromise.' }, { id: 'CLD-03', icon: 'server', t: 'Compute & runtime', d: 'EC2/VM hardening, instance metadata abuse, snapshot exposure, IMDSv1 fallback, container runtime escape.' }, { id: 'CLD-04', icon: 'cloud', t: 'Storage & data', d: 'S3/Blob/GCS bucket policies, KMS key sharing, signed-URL abuse, encryption at rest, replication misconfiguration.' }, { id: 'CLD-05', icon: 'network', t: 'Network controls', d: 'VPC peering, security groups, NACLs, private endpoint coverage, egress filtering, transit gateway routing.' }, { id: 'CLD-06', icon: 'eye', t: 'Logging & detection', d: 'CloudTrail/Activity Log coverage, GuardDuty/Defender posture, log-tampering capability, detection-evasion testing.' }, ], phases: [ { dur: 'Days 1–2', t: 'Read-only enumeration', d: 'PMapper, ScoutSuite, Prowler, and custom analyzers. We map IAM trust before we touch anything.' }, { dur: 'Days 3–5', t: 'Trust-graph analysis', d: 'Manual review of high-impact roles and cross-account trust; identify exploitable paths.' }, { dur: 'Days 6–9', t: 'Active exploitation', d: 'Demonstrate the path from a low-privilege principal to sensitive data, signing infrastructure, or admin equivalence.' }, { dur: 'Days 10–11', t: 'Kubernetes deep dive', d: 'Cluster review, pod escape testing, supply-chain admission, runtime detection.' }, { dur: 'Day 12', t: 'Report & retest', d: 'Engineering replay, infrastructure-as-code remediation snippets, and a free retest within 90 days.' }, ], deliverables: [ { icon: 'layers', format: 'PDF + HTML', t: 'Executive summary', d: 'Risk roll-up by service, identity-graph diagrams, business-impact mapping.' }, { icon: 'code', format: 'Markdown', t: 'Technical findings', d: 'Per finding: AWS CLI, az, or gcloud reproductions, IaC remediation snippets, IAM policy diffs.' }, { icon: 'terminal', format: 'IaC', t: 'Remediation pack', d: 'Terraform, CloudFormation, or Bicep snippets to remediate every finding, ready for a pull request.' }, { icon: 'shield', format: 'JSON', t: 'Trust graph', d: 'IAM graph data and Kubernetes RBAC graph for ongoing analysis.' }, { icon: 'check', format: 'Letter', t: 'Attestation letter', d: 'Compliance-ready letter referencing scope, methodology, and CIS coverage.' }, ], faq: [ { q: 'Do you need root or owner credentials in our cloud account?', a: 'No. We work from a read-only audit role and request short-lived elevated credentials only for specific demonstrations, and only after written approval.' }, { q: 'Can you test live production cloud environments?', a: 'Yes. Read-only enumeration is non-disruptive. Active exploitation is coordinated with your team and kept to agreed change windows.' }, { q: 'Do you test Kubernetes Operator and Helm chart supply chains?', a: 'Yes, including registry-pull permissions, admission webhooks, OPA and Gatekeeper effectiveness, and signed-image verification.' }, { q: 'Will you find issues our posture tools already report?', a: 'Some. We also find the chains they miss: sequences of individually low-severity findings that end in full compromise.' }, ], closeTitle: 'Test your cloud the way it gets attacked', closeBody: 'We map your trust relationships before touching a service, then show you how few steps stand between a low-privilege user and your data.', }, 'ptaas': { tag: 'Continuous testing', title: 'Continuous Pentesting.', lead: 'A rolling program of manual testing that keeps pace with your releases. Priced per asset, per surface, or per quarter, and run by the same team every cycle, so nobody has to re-learn your stack.', bullets: [ 'Per-asset, per-surface, or per-quarter pricing', 'The same team across engagements, so context is retained', 'Findings delivered as they are confirmed, into your ticket system', 'Attestation letter refreshed quarterly for SOC 2 and ISO 27001', ], mockupKind: 'ptaas', stats: [ { v: '4×/yr', l: 'Attestation refresh', s: 'quarterly, not annual' }, { v: '1 hr', l: 'Critical finding SLA', s: 'disclosed in your channel' }, { v: 'Same', l: 'Testing team', s: 'no re-onboarding every cycle' }, { v: '30%', l: 'Cycles catch a regression', s: 'before the release reaches production' }, ], vectorsTitle: 'Test at the speed you release', vectorsSub: 'An annual pentest is out of date by the second quarter. Continuous testing matches the testing cycle to your release cycle.', vectors: [ { id: 'CP-01', icon: 'refresh', t: 'Per-feature engagements', d: 'Test new features before launch, typically a three-to-five day engagement scoped to the feature.' }, { id: 'CP-02', icon: 'layers', t: 'Quarterly scope refresh', d: 'A full retest of high-risk surfaces every quarter, with the attestation letter refreshed on the same cadence.' }, { id: 'CP-03', icon: 'sparkle', t: 'Threat-driven testing', d: 'Triggered engagements when an in-the-wild attack affects your stack, within 48 hours of the advisory.' }, { id: 'CP-04', icon: 'chat', t: 'Shared channel', d: 'Our testers in your Slack or Teams during engagements, discussing findings with your engineers in real time.' }, { id: 'CP-05', icon: 'check', t: 'Rolling attestation', d: 'An attestation letter refreshed quarterly, so customer security questionnaires never stall a deal.' }, { id: 'CP-06', icon: 'shield', t: 'Team continuity', d: 'A core team that keeps context across engagements, so there is no re-onboarding every cycle.' }, ], phases: [ { dur: 'Onboarding', t: 'Program design', d: 'Scope shape (per asset, per quarter, or per feature), team selection, and communication channels.' }, { dur: 'Always-on', t: 'Testing backlog', d: 'Upcoming engagements scheduled against your release calendar.' }, { dur: 'Per cycle', t: 'Engagement', d: 'Testing runs in your channel with daily standups; findings are delivered ticket by ticket.' }, { dur: 'Quarterly', t: 'Attestation & review', d: 'Refreshed attestation letter, program review, and scope adjustment for the next quarter.' }, ], deliverables: [ { icon: 'activity', format: 'Dashboard', t: 'Program dashboard', d: 'Engagement schedule, findings pipeline, attestation status, and time-to-fix trend.' }, { icon: 'code', format: 'Tickets', t: 'Findings stream', d: 'Each finding lands in your ticket system with full reproduction steps and remediation guidance.' }, { icon: 'layers', format: 'PDF', t: 'Per-engagement report', d: 'A full report for each engagement, typically one to three weeks of testing depending on scope.' }, { icon: 'check', format: 'Letter', t: 'Rolling attestation', d: 'Quarterly-refreshed attestation letter sized for customer security questionnaires.' }, { icon: 'sparkle', format: 'Email', t: 'Threat advisories', d: 'Same-day advisories on relevant in-the-wild attacks, with a triaged view of your exposure.' }, ], faq: [ { q: 'Is this an unlimited scanner subscription?', a: 'No. This is a rolling schedule of manual engagements. We use scanning to help with coverage, and every finding you receive has been confirmed by one of our testers.' }, { q: 'How is per-asset pricing structured?', a: 'You commit to a fixed number of asset-days per quarter, where an asset is one application, one network range, or one cloud account, and consume them as you schedule engagements.' }, { q: 'Does this replace our annual pentest?', a: 'Usually. The quarterly attestation refresh covers the same compliance need, more often. If you want a separate signed annual report, we scope it as one of the engagements in the program.' }, { q: 'Can we pause or scale up?', a: 'Yes. Quarterly review windows let you adjust scope in either direction. Most teams scale up after their first incident or audit cycle.' }, ], closeTitle: 'Test as often as you ship', closeBody: 'Per quarter or per asset, with the same team, in your channel, with one rolling attestation letter. Tell us your release cadence and we will shape the program around it.', }, 'red-team': { tag: 'Adversary simulation', title: 'Red Teaming.', lead: 'Full-scope adversary simulation with a real objective. We combine email, phone, physical, network, and cloud routes to test how your detection and response perform against a determined adversary.', bullets: [ 'Objective-based, typically access to sensitive data or payment capability', 'Full scope: email, phone, physical, network, cloud', 'TIBER-EU, CBEST, and iCAST aligned where required', 'Joint readout and detection engineering with your defenders', ], mockupKind: 'redteam', stats: [ { v: '6w', l: 'Median engagement', s: 'including phased recon and pursuit' }, { v: '1', l: 'Agreed objective', s: 'measured by outcome' }, { v: '18', l: 'Techniques per operation', s: 'each mapped to MITRE ATT&CK' }, { v: 'Joint', l: 'Detection readout', s: 'every technique becomes a detection rule' }, ], vectorsTitle: 'A real adversary uses every route at once', vectorsSub: 'A red team operation tests your whole organization: people, process, technology, vendors, and the gaps between them.', vectors: [ { id: 'RT-01', icon: 'mail', t: 'Initial access: phishing', d: 'Targeted spear-phishing with credential harvesters, OAuth consent attacks, and device-code abuse.' }, { id: 'RT-02', icon: 'phone', t: 'Initial access: phone', d: 'Helpdesk impersonation, MFA fatigue, and pretext-driven credential elicitation. Always coordinated with leadership.' }, { id: 'RT-03', icon: 'fingerprint', t: 'Initial access: physical', d: 'Tailgating, badge cloning, and device drops, where in scope and legally permitted.' }, { id: 'RT-04', icon: 'network', t: 'Lateral movement', d: 'The same techniques as our internal testing, run with stealth-aware tooling and operational discipline.' }, { id: 'RT-05', icon: 'eye', t: 'Detection evasion', d: 'Detection-aware command and control, in-memory execution, and slow exfiltration where in scope.' }, { id: 'RT-06', icon: 'sparkle', t: 'Detection engineering', d: 'A joint session with your defenders after the operation. Every technique we used becomes a detection rule we help write.' }, ], phases: [ { dur: 'Weeks 1–2', t: 'Recon and objective', d: 'Public research, supply-chain mapping, target research, and objective agreement with leadership.' }, { dur: 'Week 3', t: 'Initial access', d: 'Multi-vector attempts, sustained long enough to establish a stable foothold.' }, { dur: 'Weeks 4–5', t: 'Objective pursuit', d: 'Stealth lateral movement, escalation, and access to the objective. Optional impact demonstration.' }, { dur: 'Week 6', t: 'Stand-down and readout', d: 'Technique timeline, MITRE ATT&CK mapping, and a joint detection-engineering session with your defenders.' }, ], deliverables: [ { icon: 'layers', format: 'PDF + HTML', t: 'Executive narrative', d: 'The story of the operation: how access was gained, escalated, and used. Written for board and CISO audiences.' }, { icon: 'code', format: 'Markdown', t: 'Technique timeline', d: 'Hour-by-hour log of techniques used, with screenshots, command transcripts, and ATT&CK mapping.' }, { icon: 'terminal', format: 'CSV', t: 'Detection opportunities', d: 'Every technique mapped to a detection idea: log sources, query stubs, and ATT&CK reference for your detection team.' }, { icon: 'shield', format: 'JSON', t: 'Indicators', d: 'Indicators of attack, Sigma rules, and YARA signatures where applicable, to seed your threat-hunting backlog.' }, { icon: 'check', format: 'Letter', t: 'Attestation letter', d: 'Compliance-ready letter aligned with TIBER-EU, CBEST, or iCAST where requested.' }, ], faq: [ { q: 'How is this different from a network pentest?', a: 'A pentest finds vulnerabilities in a system. A red team operation tests whether your people, process, and technology together can detect and respond to a real adversary pursuing a real objective.' }, { q: 'Will you phish our employees?', a: 'Yes, under written authorization, with a tightly scoped target list, and with leadership informed. We never target individuals outside your organization, and we never harm reputations.' }, { q: 'What if your team gets caught?', a: 'That is a successful outcome. The point is to measure detection. When we are caught we record the time to detect, capture how the alert fired, and pivot to another route. All of it goes in the report.' }, { q: 'Do you run physical or on-site engagements?', a: 'Yes, where in scope and legally permitted. Physical tests are run by named team members carrying signed authorization letters, with a single point of contact at your organization who can stop the operation at any time.' }, ], closeTitle: 'Test your response to a real attack', closeBody: 'A red team operation is the clearest way to find out whether your detection and response work against an adversary trying to win. Most engagements are scoped in two calls.', }, }; window.SERVICES_DATA = SERVICES;