How We Work

Penetration Testing Methodology

Every NullStrike engagement follows a structured attack-path methodology. Manual testing, compliance-mapped findings, and a report your auditor can actually use. Here's exactly what we do and how we do it.

Phase Structure

Six Phases. No Scanner Shortcuts.

We follow the Penetration Testing Execution Standard (PTES) and OWASP Testing Guide (WSTG), adapted for compliance-driven engagements. Every phase produces documented evidence your auditor can verify.

PHASE 01

Pre-Engagement

Scope definition, rules of engagement, authorization documentation, NDA, and compliance framework selection. Nothing starts without written authorization.

PHASE 02

Reconnaissance

Passive and active information gathering. Subdomain enumeration, technology fingerprinting, exposed endpoints, and public attack surface mapping.

PHASE 03

Threat Modeling

Data flow analysis, trust boundary identification, and attack vector prioritization based on your compliance framework and data classification.

PHASE 04

Active Testing

Manual exploitation of identified vulnerabilities. Authentication bypass, authorization flaws, injection attacks, business logic abuse, and attack-path chaining.

PHASE 05

Post-Exploitation

Lateral movement, privilege escalation, data exposure validation, and impact demonstration. We show what an attacker does after initial access, not just how they get in.

PHASE 06

Reporting & Debrief

Full written report with compliance control mapping, proof-of-concept evidence, CVSS scores, business impact, and remediation guidance. Debrief call included.

Web Application & API Testing

OWASP WSTG — What We Actually Test

We test against the OWASP Web Security Testing Guide (WSTG v4.2) — the industry standard for web application penetration testing. Coverage is manual, not automated. Here's what that means in practice.

  1. Authentication Testing

    Credential brute-force controls, account enumeration, password reset flaws, multi-factor authentication bypass, session fixation, and OAuth/OIDC misconfiguration.

  2. Authorization & Access Control

    Broken Object Level Authorization (BOLA/IDOR), privilege escalation, horizontal access between user accounts, admin endpoint exposure, and role enforcement validation.

  3. Input Validation & Injection

    SQL injection, NoSQL injection, command injection, SSTI, XXE, SSRF, and stored/reflected XSS. We test all input vectors including headers, cookies, and file uploads.

  4. Business Logic Abuse

    Workflow bypass, price manipulation, race conditions, quantity tampering, and abuse of application-specific logic. Scanners cannot find this — only manual testing does.

  5. API Security (OWASP API Top 10)

    Excessive data exposure, broken function-level authorization, mass assignment, improper asset management, and API rate limiting failures across REST, GraphQL, and gRPC.

  6. Session Management

    Token entropy, secure flag validation, HttpOnly enforcement, session invalidation on logout, concurrent session handling, and JWT implementation review.

  7. Cryptography & Data Exposure

    Weak cipher suites, TLS configuration, sensitive data in transit and at rest, key management review, and certificate validation.

Tools Used

Burp Suite Pro (primary proxy), ffuf, nuclei (manual-verified only), SQLmap, nikto, nmap, dirsearch, jwt_tool, and custom scripts for business logic testing. Tool output is always manually validated before reporting.

Burp Suite Pro ffuf nuclei SQLmap nmap jwt_tool dirsearch Metasploit Custom Scripts
Cloud Security Testing

AWS · Azure · GCP · Oracle Cloud

Cloud penetration testing requires a fundamentally different approach than web app testing. We focus on IAM, resource exposure, privilege escalation paths, and trust boundary abuse — the attack vectors that break cloud-native environments.

  1. IAM Configuration Review

    Overly permissive roles, wildcard policies, unused credentials, cross-account trust relationships, and privilege escalation paths via IAM misconfiguration.

  2. Resource Exposure Assessment

    Public-facing S3/Blob/GCS buckets, exposed snapshots, misconfigured security groups, open ports on cloud instances, and public API Gateway endpoints.

  3. Privilege Escalation Paths

    Chaining IAM permissions to escalate from low-privilege user to admin. Lambda abuse, EC2 metadata SSRF, managed identity exploitation, and service account key exposure.

  4. Network Segmentation Validation

    VPC peering misconfiguration, security group rule review, NACLs bypass, internal service exposure, and cross-service lateral movement paths.

  5. Secrets & Key Management

    Hardcoded credentials in EC2 user data, Lambda environment variables, public repositories, and CloudFormation templates. AWS Secrets Manager and Azure Key Vault access review.

  6. Logging & Detection Gaps

    CloudTrail, Azure Monitor, and GCP Audit Log coverage gaps. Detection of attack actions that bypass logging, and assessment of SIEM alerting configurations.

Certification Basis

Our cloud testing methodology is grounded in our Multi-Cloud Red Team Analyst (MCRTA) certification from CyberWarFare Labs, covering cross-cloud attack paths, trust boundary abuse, and privilege escalation across AWS, Azure, GCP, and Oracle Cloud.

Pacu (AWS) ScoutSuite Prowler CloudSploit AWS CLI Azure CLI gcloud CLI Enumerate-IAM
AI & LLM Security Testing

OWASP LLM Top 10

AI-integrated applications introduce attack surfaces that don't exist in traditional software. We test LLM-powered products against the OWASP LLM Top 10 — the security standard specifically designed for AI systems in production.

  1. Prompt Injection

    Direct and indirect prompt injection attacks that override system instructions, bypass safety guardrails, or cause the model to execute unintended actions.

  2. Sensitive Data Exfiltration

    Extracting training data, system prompts, user data from other sessions, or confidential context via crafted adversarial inputs.

  3. Safety Bypass & Content Policy Evasion

    Techniques to bypass content filters, jailbreaks, role-play attacks, and encoding-based evasion of safety mechanisms.

  4. AI Agent Trust Boundary Abuse

    Testing multi-agent systems for privilege escalation between agents, unauthorized tool use, and trust relationship exploitation in agentic workflows.

  5. Retrieval-Augmented Generation (RAG) Attacks

    Poisoning retrieval databases, extracting documents outside user permissions, and testing data isolation between tenants in RAG-based applications.

  6. Model Denial of Service

    Resource exhaustion via malicious inputs, context window flooding, and recursive prompt structures that degrade model availability or trigger excessive costs.

Compliance Mapping

Every Finding Mapped to Your Framework

We don't just find vulnerabilities — we document exactly how each finding maps to the compliance control your auditor needs to see satisfied. Here's how we cover each framework.

HIPAA §164.308(a)(8)

Technical evaluation of safeguards protecting ePHI. Each finding references the specific HIPAA control it violates and what remediation satisfies the rule.

SOC 2 CC6.1 / CC7.1

Logical access controls and monitoring. Findings documented with Trust Service Criteria references so auditors can close controls without follow-up questions.

PCI DSS Req. 11.3

External and internal penetration testing per requirement 11.3.1. OWASP coverage documented. Segmentation testing included where applicable.

ISO 27001 A.8.8 / A.8.29

Technical vulnerability management and security testing in development. Findings mapped to Annex A controls for Stage 2 auditor review.

DPDP Act Section 8(5)

"Reasonable security safeguards" documented with evidence of authentication, access control, encryption, and monitoring testing against data subject protection obligations.

ISO 27001 Clause 9.1

Performance evaluation and ISMS monitoring. Penetration testing results feed directly into management review evidence and continual improvement records.

Deliverable

What the Report Contains

Every NullStrike report follows the same structure so your auditor knows exactly where to find the evidence they need. No hunting through PDF appendices.

Executive Summary
Risk overview for leadership and board. Written for non-technical readers. Includes overall risk rating, critical findings count, and compliance posture assessment.
Scope & Methodology
Exact targets tested, testing dates, tester credentials, methodology references (OWASP WSTG, PTES), and compliance framework in scope.
Findings Detail
Every vulnerability documented with: CVSS v3.1 score, affected component, proof-of-concept steps, screenshot/video evidence, business impact, and compliance control reference.
Attack Path Narrative
How individual findings chain into complete attack paths. Shows auditors and your team what an attacker could actually do — not just what's broken in isolation.
Remediation Guidance
Specific fix guidance for each finding — code-level recommendations, configuration changes, and architectural improvements. Priority-ordered by risk.
Compliance Control Map
Table mapping each finding to the specific compliance control it addresses. Your auditor can close controls directly from this section.
Retest Attestation
After you remediate, we verify fixes and issue a signed attestation letter confirming critical and high findings are closed. Required for many audits.
Report Format

Delivered as a password-protected PDF within agreed timeframe. A debrief call walks your team and auditors through findings. The sample report shows exactly what you receive.

Standards

What We Don't Do

Most "penetration tests" in the market are automated scanner reports with a consultant's name on them. Here's what separates a NullStrike engagement from that.

  1. No automated scanner output as findings

    Every finding in our report is manually verified. We use scanners as recon tools — not as the test itself. Scanner-generated reports without manual verification are not penetration tests.

  2. No CVSS scores without business context

    A CVSS 9.8 in an internal-only admin panel is not the same as a CVSS 9.8 on your public patient portal. Every finding includes business impact analysis relevant to your environment.

  3. No destructive actions without explicit approval

    We scope every engagement to avoid unintended impact on production systems. Destructive testing (data deletion, service disruption) only happens when explicitly approved in the rules of engagement.

  4. No untested systems in scope

    If it's in scope, we test it. We don't include systems in the report that weren't actually tested. If something was excluded mid-engagement, we document why.

Ready to See This in Action?

Download our sample AWS penetration testing report or book a free scoping call to discuss your environment.