Vulnerability Assessment
& Penetration Testing
Classification Guide

A Vulnerability Assessment is a structured, systematic process of identifying, enumerating, categorising, and prioritising security weaknesses within a defined target environment. VA operates exclusively within a passive-to-semi-active discovery mode. Under no circumstances does a VA exercise involve the confirmation of exploitability through active exploitation, payload delivery, or any action that modifies system state beyond what is inherent to authorised scanning.

The intellectual output of a VA is a ranked inventory of vulnerabilities with contextual risk ratings (typically aligned with CVSS v3.1 / CVSS v4.0), remediation guidance, and compliance gap mapping. The output does not, and must not, include exploitation evidence, session tokens captured through active attacks, or proof-of-impact artefacts.

• Identification and enumeration of vulnerabilities (CVE/CWE mapping)
• Automated and manual scanning within authorised scope
• Configuration review and misconfiguration detection
• Version fingerprinting and EOL/EOS component identification
• Compliance gap assessment (CERT-In, PCI DSS, ISO 27001, etc.)
• OSINT-based surface enumeration (passive reconnaissance only)
• Risk scoring and prioritisation using CVSS, EPSS, or SSVC
• Remediation roadmap generation

• Active exploitation of any identified vulnerability
• Delivery of attack payloads (shellcode, SQL injections to confirm RCE, etc.)
• Privilege escalation to confirm root/admin access
• Lateral movement within networks
• Data exfiltration — even as proof-of-concept
• Bypassing authentication controls to gain access
• Any action that modifies, encrypts, deletes, or corrupts data
• Social engineering of personnel

A Penetration Test is a legally authorised, adversarial simulation in which a qualified tester (or team) actively attempts to exploit identified or suspected vulnerabilities to confirm real-world impact. PT extends beyond discovery into controlled exploitation: establishing footholds, escalating privileges, moving laterally, and demonstrating tangible impact (e.g., data access, system compromise, service disruption).

Penetration Testing is governed by a mandatory, pre-signed Rules of Engagement (RoE) document, which defines the authorised scope, permitted techniques, escalation contacts, emergency stop conditions, and legal authorisation. No written RoE = No PT. Any exploitation activity without written RoE constitutes an unauthorised intrusion under applicable cybercrime law.

• Active exploitation of vulnerabilities to confirm impact (proof-of-exploitation)
• Privilege escalation from low-privilege entry points to administrative control
• Lateral movement and pivoting across network segments
• Credential theft, pass-the-hash, pass-the-ticket, token manipulation
• Controlled data access demonstration (no exfiltration of real data without explicit permission)
• Post-exploitation persistence mechanism testing
• Social engineering and phishing simulation (where explicitly in scope)
• Physical security testing (where in scope)
• Full attack chain simulation (kill-chain or MITRE ATT&CK aligned)

A Rules of Engagement document is the sole instrument that converts an otherwise illegal exploitation activity into a lawful penetration test. The following are non-negotiable minimum requirements for any RoE governing PT activity:

• Written authorisation from the asset owner (not merely IT/security staff — board-level or CIO-level sign-off is best practice for high-risk engagements)
• Explicit scope definition: IP ranges, hostnames, URLs, API endpoints, environments (production vs. staging), and cloud account IDs
• Explicit out-of-scope declaration: third-party systems, production databases, payment systems (unless specifically approved), critical infrastructure
• Permitted techniques and tools (e.g., exploitation frameworks, social engineering, physical access)
• Prohibited techniques (e.g., destructive payloads, ransomware simulation, DDoS)
• Testing window: dates, times, time zones
• Emergency stop / abort procedure and escalation contacts (24/7 reachable)
• Incident response coordination: SOC/SIEM awareness of the test (or explicit black-box blinding agreement)
• Data handling clauses: prohibition on real data exfiltration, evidence destruction post-engagement
• Jurisdiction and governing law clause
• Third-party system notification: Cloud provider approval (AWS, Azure, GCP have specific testing notification policies)

• IT Act 2000 / ITA 2008: Sections 43, 43A, 66, 66B, 66C, 66F define criminal liability for unauthorised computer access, data theft, and disruption of critical infrastructure. VAPT without authorisation is an offence regardless of intent.
• CERT-In Directions 2022: Mandatory 6-hour breach reporting timeline; security service providers must maintain audit logs for 180 days. VAPT firms empanelled with CERT-In must comply with reporting standards. VA/PT reports may be subject to regulatory inspection.
• RBI (BFSI): RBI Cybersecurity Framework (2016, updated circulars) mandates annual VAPT for regulated entities (banks, NBFCs, payment aggregators). Scope must include internet-facing and core banking systems. VAPT must be conducted by CERT-In empanelled agencies for regulated entities.
• SEBI Cyber Resilience Framework (2023): Mandates bi-annual VAPT for Market Infrastructure Institutions (MIIs) and quarterly for critical systems. Includes requirements for red team exercises (advanced PT) for Qualified Stock Brokers (QSBs).
• IRDAI Cybersecurity Guidelines (2023): Insurers and TPAs must conduct annual VAPT. Scope includes insurer portals, mobile applications, and data-sharing APIs with third parties.
• DPDP Act 2023: Data Fiduciaries must implement appropriate technical safeguards. VAPT is an expected control. Testers who access personal data during testing must operate under data processing agreements. Consent mechanisms must not be bypassed without written authorisation.

• ISO/IEC 27001:2022 (Annex A, Control 8.8): Requires management of technical vulnerabilities. VAPT is a primary mechanism. Clause 9.1 mandates monitoring and measurement, including security testing.
• ISO/IEC 27005:2022: Provides the risk assessment framework within which VA findings feed. Risk treatment decisions determine whether PT is required to confirm exploitability and business impact.
• NIST SP 800-115: The definitive technical guide to information security testing and assessment. Distinguishes between "testing" (active), "examination" (passive/VA), and "interviews." PT falls under active testing per NIST taxonomy.
• NIST SP 800-53 Rev5 (CA-8): Penetration Testing control — organisations must conduct PT at defined frequencies and following system changes. VA is addressed under RA-5 (Vulnerability Monitoring and Scanning).
• PCI DSS v4.0 (Req. 11.3 & 11.4): Requires internal and external VA scans (11.3) and annual penetration testing (11.4) with network and application layer coverage. PT must use industry-accepted methodology and be performed by qualified testers (internal or external).
• SOC 2 (Common Criteria CC7.1): Requires vulnerability management processes. PT may be required depending on risk profile and auditor expectations. PT findings must be treated as control deficiencies if unaddressed.

Web Application VA — Definition & Permitted Activities

Web application VA encompasses the systematic identification of security weaknesses in web-accessible software interfaces using passive reconnaissance, authenticated and unauthenticated scanning, manual source review (where access is granted), and automated DAST/SAST tooling — all without delivering attack payloads that exploit identified findings.

• Automated DAST scanning (OWASP ZAP, Burp Suite Professional in scan mode, Nikto, Acunetix) against authorised targets — detecting but not exploiting findings
• Manual crawling and application mapping (sitemap enumeration, endpoint discovery)
• HTTP header analysis (CSP, HSTS, X-Frame-Options, CORS policy inspection)
• Cookie attribute review (Secure, HttpOnly, SameSite flags)
• TLS/SSL configuration assessment (protocol versions, cipher suites, certificate validity)
• Error message and stack trace disclosure detection (observing, not triggering with intent to exploit)
• Third-party component version identification (JS libraries, CMS, frameworks) and CVE mapping
• Authentication mechanism review (password policy, lockout policy, MFA presence — not bypassing)
• Directory and file enumeration (non-destructive; detection of exposed admin panels, backup files, .env files)
• Robots.txt and sitemap.xml review
• OWASP ASVS-aligned checklist review
• Source code review (SAST) where source is provided under engagement terms
• OSINT — public leaks, Shodan/Censys exposure, Google dorking for information disclosure

• Submitting crafted SQL injection payloads to confirm database access
• Delivering XSS payloads that execute in victim browser sessions
• Testing CSRF with forged requests that modify application state
• File upload exploitation (uploading web shells)
• Authentication bypass (confirming access to protected resources)
• Accessing data beyond tester's own test account without explicit permission
• Business logic exploitation that results in financial or data impact

Web Application PT — Proof-of-Impact Testing

Web application penetration testing involves the controlled exploitation of identified vulnerabilities to confirm real business impact. This includes confirming data exfiltration through SQLi, session hijacking through XSS execution, file system access through path traversal, or account takeover through authentication bypass — all within authorised scope and under a signed RoE.

• SQL injection exploitation to retrieve database contents (e.g., UNION SELECT, blind/time-based injection) — confirming data exposure
• XSS exploitation to capture session tokens, demonstrate keylogging, or redirect to attacker-controlled pages
• CSRF exploitation to perform authorised actions on behalf of authenticated victims
• Authentication bypass — exploiting broken authentication to access privileged accounts
• IDOR exploitation to demonstrate unauthorised object access across accounts
• XXE injection to read local files or achieve SSRF
• SSRF exploitation to access internal services (cloud metadata endpoints, internal APIs)
• Web shell upload and execution (in isolated/staging environments only, with explicit RoE clause)
• Deserialization attack exploitation
• Business logic abuse chains demonstrating financial or data integrity impact
• OAuth/SAML implementation flaws exploitation (token theft, account takeover)

Exact Stopping Point & Tipping Points

The VA boundary for web applications is crossed at the moment a tester transitions from observing the potential for impact to actively inducing impact. The following table provides precise tipping points:

PT Entry Triggers, Required Authorisations & Consequences

• Any delivery of an exploit payload that confirms unauthorised access to application functionality
• Any attempt to access, read, or modify data belonging to accounts outside the tester's own test account
• Any attempt to escalate privileges within the application
• Any chaining of vulnerabilities to demonstrate multi-step attack paths

• Signed RoE explicitly listing target application URLs, environments (prod/staging), and testing windows
• If production testing: explicit approval for production impact, backup confirmation, change management ticket
• Third-party SaaS components in scope must be explicitly approved (vendor notification may be required)
• CDN provider approval if WAF bypass testing is in scope
• Confirmation that application logging/SOC is aware (unless black-box test is explicitly designed)

API VA — Definition & Permitted Activities

API VA involves the systematic security review of API endpoints using documentation analysis, schema validation, automated scanning, and manual inspection — without exploiting identified vulnerabilities to confirm unauthorised data access or privilege escalation. The OWASP API Security Top 10 (2023) provides the definitive vulnerability taxonomy for API VA engagements.

• API schema/specification review (OpenAPI/Swagger, WSDL, GraphQL introspection schema)
• Authentication mechanism assessment (API key management, OAuth 2.0 flow review, JWT claim analysis without forgery)
• Rate limiting and throttling control detection (observing absence, not bypassing)
• Endpoint enumeration using provided documentation and passive discovery
• HTTP method enumeration and unexpected method detection
• Response data over-exposure analysis (identifying fields returning excessive PII or sensitive data)
• CORS policy misconfiguration detection
• TLS enforcement and certificate validation checks
• Error response analysis (stack traces, verbose error codes, internal IP disclosure)
• Mass assignment vulnerability pattern identification (field enumeration without exploitation)
• Broken object-level authorisation (BOLA/IDOR) pattern identification by inspecting API patterns
• Automated scanning using tools such as 42Crunch, APIsec, OWASP ZAP API scan mode

• Exploiting BOLA to access another user's data objects
• JWT forgery or algorithm confusion attacks to gain elevated access
• Mass assignment attacks to modify privilege levels or bypass business rules
• GraphQL injection or introspection abuse to extract sensitive schema data beyond tester's permission level
• Confirming SSRF through callbacks to internal network services via API parameters

API PT — Proof-of-Impact Testing

API PT confirms the real-world exploitability of API vulnerabilities, demonstrating actual unauthorised data access, privilege escalation, or business logic abuse through controlled exploitation of identified weaknesses in API endpoints.

• BOLA/IDOR exploitation: Accessing another user's API objects by modifying resource identifiers (e.g., GET /api/users/1234/orders → /api/users/1235/orders) — confirming cross-account data access
• Broken Function-Level Authorisation (BFLA): Accessing admin-only API endpoints using non-privileged credentials
• JWT attacks: Algorithm confusion (RS256 → HS256), header injection, weak secret cracking to forge tokens with elevated privileges
• Mass assignment: Sending additional JSON fields to elevate role or bypass business rules
• GraphQL abuse: Exploiting introspection, batch query attacks, field-level authorisation bypass, nested query DoS
• SSRF via API parameters: Sending requests to internal cloud metadata services or internal APIs
• Injection attacks via API inputs: SQLi, NoSQLi, command injection confirmed through API response analysis
• Rate limiting bypass: IP rotation, header manipulation to confirm DoS potential or brute force viability
• API key/secret leakage exploitation: Using discovered keys to authenticate as service accounts

Exact Stopping Point & Tipping Points

PT Entry Triggers & Required Authorisations

• Any API request that accesses data objects belonging to accounts outside the tester's allocated test accounts
• Any attempt to forge or manipulate authentication tokens to access elevated functionality
• Any API call volume exceeding normal operational thresholds (potential DoS)
• Any exploitation of injection vulnerabilities through API inputs
• Any use of discovered API secrets/keys to authenticate as service or privileged accounts

The RoE for API PT must explicitly list: API base URLs, version identifiers, specific endpoint categories in scope, allocated test account credentials, and any rate limits imposed by the engagement. For financial APIs (payment, trading, banking), the RoE must confirm that test transactions are conducted in a sandbox environment only.

External Network VA — Definition & Permitted Activities

External network VA involves scanning and assessing all internet-facing assets of the organisation — including IP ranges, public DNS infrastructure, exposed services, and network perimeter devices — to identify vulnerabilities, misconfigurations, and exposure without active exploitation.

• IP range and port scanning using Nmap, Masscan (within authorised IP scope)
• Service version fingerprinting and banner grabbing
• Vulnerability scanning using authenticated/unauthenticated scanners (Tenable Nessus, Qualys, Rapid7)
• SSL/TLS configuration assessment (expired certs, weak ciphers, BEAST, POODLE, DROWN, Heartbleed detection)
• DNS zone transfer attempts (identifying misconfigured DNS servers)
• BGP route analysis and ASN enumeration
• Firewall rule enumeration through response analysis (not firewall rule bypass)
• OSINT-based asset discovery (Shodan, Censys, SecurityTrails, FOFA)
• Email security assessment (SPF, DKIM, DMARC record analysis)
• Exposed administrative interfaces detection (RDP, SSH, Telnet on non-standard ports)
• Default credential identification (not active use of default credentials)
• CVE mapping for identified service versions

• Exploiting identified vulnerabilities to gain access to any system
• Using discovered default credentials to authenticate
• Firewall rule bypass or evasion techniques
• DoS/DDoS testing without explicit RoE (never appropriate without a strict maintenance window)

External Network PT — Adversarial Perimeter Testing

External network PT simulates a real-world threat actor attempting to breach the organisational perimeter from the internet. This includes exploiting service vulnerabilities, credential stuffing/spraying, network protocol exploitation, and gaining an initial external foothold.

• Exploitation of CVEs in identified service versions to gain remote code execution or access
• Credential spraying against VPN gateways, OWA, or exposed authentication services
• Default or weak credential exploitation on exposed administrative services
• SSL/TLS vulnerability exploitation (Heartbleed, POODLE — on isolated test instances)
• Network protocol exploitation (SMBv1, RDP BlueKeep, etc.) — in scope only where explicitly authorised
• Establishing external C2 foothold and demonstrating perimeter penetration
• Firewall/IDS evasion techniques to establish access (TCP fragmentation, timing-based evasion)
• BGP hijacking simulation (requires extremely specific RoE and ISP coordination)

Tipping Points

PT Entry Triggers & Authorisations

• Any authentication attempt to network services (VPN, RDP, SSH, SMTP AUTH, FTP)
• Any exploitation of identified CVEs in production network services
• Any attempt to establish persistence on network perimeter devices
• Any traffic modification or man-in-the-middle activity on network segments

The RoE for external network PT must specify: exact CIDR ranges in scope, individual out-of-scope IPs (particularly shared infrastructure, co-location neighbours), ISP and hosting provider notifications (required where shared infrastructure is involved), and a specific emergency abort contact reachable 24/7. For cloud-hosted infrastructure, cloud provider notification policies must be satisfied prior to PT commencement.

Internal Network VA — Definition & Permitted Activities

Internal network VA involves the assessment of an organisation's internal network landscape — including Active Directory, network devices, internal servers, workstations, and segmentation controls — using authorised scanning from an insider vantage point, without exploiting discovered vulnerabilities.

• Internal network host discovery and asset inventory (Nmap, Nessus, Qualys agent/scanner)
• Internal vulnerability scanning (authenticated scans preferred for depth)
• Active Directory enumeration using read-only queries (BloodHound in read-only mode, LDAP queries with authorised credentials)
• Network segmentation review (identifying reachability between VLANs — not exploiting)
• SMB share enumeration (identifying accessible shares, not exploiting data within them)
• Internal DNS and WINS enumeration
• DHCP scope and ARP table analysis
• Network device configuration review (if provided: firewall rules, router ACLs)
• Patch level assessment across Windows/Linux hosts
• Internal service version fingerprinting
• Certificate authority infrastructure review
• Group Policy Object (GPO) review for security misconfigurations (read-only)

• Kerberoasting, AS-REP Roasting, or any credential-extraction attack
• Pass-the-Hash, Pass-the-Ticket, or lateral movement
• Exploiting unpatched vulnerabilities to escalate privileges
• Modifying AD objects, GPOs, or ACLs
• Accessing internal file shares beyond the tester's authorised context

Internal Network PT — Full Adversarial Simulation

Internal network PT simulates a threat actor who has achieved initial access (insider threat, breached endpoint, phished user) and is attempting to expand privileges and impact. This is one of the most sensitive engagement types due to the potential for lateral movement across critical systems.

• Active Directory attacks: Kerberoasting (SPN-based service account hash extraction), AS-REP Roasting, DCSync (domain controller sync simulation), Golden/Silver Ticket forgery, ADCS ESC attack chains
• Lateral movement: Pass-the-Hash, Pass-the-Ticket, Over-Pass-the-Hash (PTH/PTK), NTLM relay attacks (responder + ntlmrelayx)
• Privilege escalation: Local privilege escalation exploits, misconfigured services (writable service binaries, unquoted service paths, AlwaysInstallElevated)
• Network attacks: LLMNR/NBT-NS poisoning (credential capture), IPv6 rogue DHCP, ARP spoofing for MITM
• Credential access: SAM/LSASS dumping, DPAPI decryption, credential file hunting
• Persistence mechanisms: Scheduled tasks, registry run keys, WMI subscriptions — demonstrating persistence paths
• Domain dominance: Demonstrating Domain Admin compromise, DCSync capability
• Segmentation bypass: Demonstrating VLAN hopping, firewall rule abuse to reach isolated segments

Tipping Points

PT Entry Triggers & Authorisations

• Any credential extraction attempt (hash dumping, ticket extraction, credential file reading)
• Any lateral movement attempt — connecting to systems beyond the initial entry point
• Any privilege escalation attempt via exploitation
• Any modification of Active Directory objects, GPOs, or access control lists
• Any persistence mechanism installation
• Any network poisoning or MITM attack (LLMNR poisoning, ARP spoofing, rogue DHCP)

The RoE for internal network PT must include: VLAN/subnet scope map, explicit AD domain and OU scope, critical system exclusion list, Domain Admin notification chain, SOC awareness level (white/grey/black box), and a defined blast radius limitation for destructive test techniques.

AWS VA — Definition & Permitted Activities

AWS VA assesses the security posture of an organisation's AWS environment against the Shared Responsibility Model — focusing on customer-managed controls: IAM policies, resource configurations, encryption settings, network controls, logging, and compliance posture — without exploiting discovered misconfigurations to gain unauthorised access to AWS resources.

• IAM Assessment: Policy review (over-permissive policies, wildcard actions/resources), role trust relationship analysis, unused access key identification, MFA enforcement gaps, AWS IAM Access Analyzer findings review
• S3 Bucket Configuration: Public access block settings, bucket ACL review, bucket policy analysis, encryption at rest verification, versioning and logging status
• Network Configuration: Security Group rule analysis (overly permissive ingress/egress — 0.0.0.0/0), VPC flow log enablement, NACLs review, publicly exposed subnets
• EC2/Compute: AMI public exposure, instance metadata service v1 (IMDSv1) vs v2 detection, unencrypted EBS volumes, expired/unrotated key pairs
• Data Services: RDS/Aurora public accessibility, encryption status, snapshot exposure; DynamoDB public access; ElasticSearch/OpenSearch public endpoint detection
• Monitoring/Logging: CloudTrail enablement and integrity, GuardDuty status, Config rules compliance, SecurityHub findings review
• Serverless: Lambda function permission analysis, environment variable secrets exposure detection, execution role over-privilege assessment
• Automated tools: AWS Prowler, CloudMapper, ScoutSuite, Checkov (IaC scanning), AWS Config rules, AWS Trusted Advisor, Steampipe

• Exploiting over-permissive IAM roles to assume unintended permissions
• Accessing S3 bucket contents beyond authorised test data
• Exploiting EC2 IMDS to steal instance credentials
• Using discovered IAM keys/credentials to access unauthorised services
• Modifying AWS resources (security groups, IAM policies, S3 ACLs) beyond read operations

AWS PT — Cloud Environment Exploitation

AWS PT simulates a threat actor (external attacker or insider) who attempts to escalate privileges within the AWS environment, move laterally between services, access sensitive data, or establish persistence within the cloud account.

• IAM Privilege Escalation: Exploiting over-permissive policies to assume roles or create new IAM users with elevated privileges (e.g., iam:PassRole abuse, iam:CreatePolicyVersion, sts:AssumeRole chains)
• EC2 IMDS Exploitation: Accessing http://169.254.169.254/latest/meta-data/iam/security-credentials/ on IMDSv1-enabled instances to steal temporary credentials
• S3 Data Access: Accessing publicly exposed or misconfigured S3 buckets to retrieve sensitive data (within authorised scope)
• Cross-Service Privilege Escalation: Using Lambda role over-privileges to access DynamoDB, Secrets Manager, or SSM Parameter Store
• Persistence: Creating backdoor IAM users, attaching policies to existing roles, deploying persistence Lambda functions
• Shadow Access: Exploiting resource-based policies to gain cross-account access
• CloudFormation/CDK Attack: Exploiting misconfigured IaC templates to deploy unauthorised resources

Tipping Points

PT Entry Triggers & Authorisations

• Any API call that modifies AWS resource state (IAM policy attachment, security group rule changes, instance creation/termination)
• Any assumption of an IAM role beyond the tester's assigned credentials
• Any access to S3 bucket data, Secrets Manager secrets, or SSM parameters beyond the authorised test scope
• Any exploitation of IMDS to retrieve temporary credentials
• Any cross-account access attempt or resource-sharing exploitation

Azure VA — Definition & Permitted Activities

Azure VA assesses the security configuration of Microsoft Azure environments, with particular focus on Microsoft Entra ID (formerly Azure AD) identity controls, Azure RBAC, network security groups, storage account configurations, and the Microsoft Secure Score posture — without exploiting identified misconfigurations.

• Entra ID / Azure AD: Conditional Access policy review, MFA enforcement gaps, privileged role assignments (Global Admin, Application Admin, Privileged Role Admin enumeration), guest user access review, service principal secret/certificate expiry, App Registration permission scopes
• Azure RBAC: Over-privileged role assignments, Owner/Contributor role breadth, custom role misconfiguration, management group scope analysis
• Storage Accounts: Public blob access detection, HTTPS-only enforcement, shared access signature (SAS) token policy review, soft delete and versioning status
• Network: NSG rule analysis, Azure Firewall policy review, virtual network peering exposure, ExpressRoute and VPN gateway configuration
• Compute: VM extension review, Just-in-time (JIT) VM access enablement, disk encryption status, public IP exposure
• Defender for Cloud: Secure Score review, compliance posture (CIS, PCI, NIST), Defender plan enablement gaps
• Key Vault: Access policy review, soft delete enablement, key/secret expiry, network access restrictions
• Automated tools: Microsoft Secure Score, Defender for Cloud, BloodHound for Azure (AzureHound — read-only collection), Prowler, ScoutSuite, Monkey365

Azure PT — Identity and Resource Exploitation

• Entra ID attacks: Password spray against Entra ID (including legacy authentication protocols), MFA bypass via adversary-in-the-middle phishing proxy (Evilginx2), consent phishing (OAuth app grant exploitation)
• Service Principal abuse: Exploiting over-privileged app registrations, SP credential theft, Azure AD token theft via device code phishing
• RBAC exploitation: Privilege escalation via over-permissive custom roles, management group scope escalation
• Managed Identity abuse: Accessing IMDS endpoint on Azure VMs (http://169.254.169.254/metadata/identity/oauth2/token) to obtain managed identity tokens
• Storage account exploitation: Accessing publicly exposed blobs, exploiting misconfigured SAS tokens
• Azure persistence: Backdoor App Registrations, hidden role assignments, rogue service principals
• Pass-the-PRT: Exploiting Primary Refresh Tokens from Entra ID-joined devices

Tipping Points

• Any authentication attempt beyond the tester's assigned test account credentials
• Any exploitation of Managed Identity IMDS to obtain tokens
• Any modification of RBAC assignments, Conditional Access policies, or Entra ID configurations
• Any storage account data access beyond explicitly authorised test containers
• Any App Registration modification or new service principal creation

GCP VA — Definition & Permitted Activities

GCP VA evaluates the security posture of Google Cloud environments against GCP-specific security controls, with emphasis on IAM policy overpermissiveness, service account misuse risk, network exposure, GCS bucket configurations, and Workspace/Google Identity integration risks.

• IAM: Service account key proliferation detection, default service account usage identification, over-permissive IAM bindings (primitive roles: Owner, Editor on production projects), workload identity federation review
• GCS Buckets: Public access detection, IAM policy vs. ACL analysis, uniform bucket-level access enforcement, retention policy review
• Compute Engine: Instance metadata API exposure assessment, OS Login vs. SSH key management, default service account with Editor role on compute instances, firewall rule review (0.0.0.0/0 ingress)
• GKE: Cluster access control (private endpoint, public endpoint with authorised networks), RBAC review, workload identity configuration, legacy metadata API enablement check
• Logging/Monitoring: Cloud Audit Log enablement (Admin Activity, Data Access, System Event), Security Command Center findings review, Log sink configuration
• Automated tools: GCP Security Command Center, Forseti Security, Prowler (GCP module), ScoutSuite, Checkov (Terraform/GCP IaC)

GCP PT — Service Account and Resource Exploitation

• Service account key exploitation: Using leaked/discovered service account keys to authenticate as high-privilege service accounts
• Metadata API exploitation: Accessing http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/ to retrieve service account tokens from Compute Engine instances
• IAM privilege escalation: Exploiting iam.serviceAccounts.actAs, iam.serviceAccountKeys.create, or resourcemanager.projects.setIamPolicy to escalate privileges
• GCS data access: Accessing publicly exposed or misconfigured GCS bucket contents
• GKE exploitation: Exploiting misconfigured RBAC or workload identity to gain cluster-admin privileges
• Cloud Functions abuse: Exploiting over-permissive service accounts attached to Cloud Functions
• Org-level privilege escalation: Exploiting organisation-level IAM bindings to gain cross-project access

• Any API call that impersonates a service account beyond the tester's assigned identity
• Any metadata API access for credential retrieval
• Any GCS bucket data access beyond authorised test buckets
• Any modification of IAM bindings, organisation policies, or project-level resources
• Any GKE cluster access beyond the tester's authorised kubeconfig credentials

Hybrid Cloud VA — Definition & Scope Considerations

Hybrid and multi-cloud environments introduce unique VA complexity due to the intersection of multiple cloud providers' shared responsibility models, on-premises infrastructure, and cloud-to-cloud and cloud-to-on-premises connectivity. VA must address each cloud platform independently while also assessing cross-environment security controls — particularly identity federation, network transit zones, and data classification consistency.

• Oracle Cloud Infrastructure (OCI): Compartment structure and IAM policy review, VCN security list and NSG assessment, Object Storage bucket access review, Vault key management configuration, Audit Log enablement
• IBM Cloud: IAM policy and access group review, Cloud Object Storage (COS) bucket exposure, Virtual Private Cloud (VPC) security group analysis, Key Protect/HPCS configuration
• Private Cloud (VMware vSphere, OpenStack, Nutanix): Hypervisor patch level, vCenter/vSphere access control review, inter-VM network segmentation, snapshot and backup exposure, management network isolation
• Multi-Cloud Connectivity: Transit gateway and peering configuration review, cloud-to-on-premises VPN/ExpressRoute/Direct Connect encryption and routing assessment, cross-cloud identity federation (SSO/SAML integration weaknesses)
• Cloud Security Posture Management (CSPM): Centralised CSPM tool coverage (Wiz, Orca, Prisma Cloud, Defender for Cloud multi-cloud) — findings review and gap analysis
• Container Orchestration: Kubernetes configuration review (API server exposure, RBAC, network policies, Pod Security Standards, admission controllers) across all cloud platforms
• Hybrid Identity: Azure AD Connect / Entra Connect sync configuration review, ADFS security assessment, LDAP-to-cloud bridge misconfiguration detection

Hybrid Cloud PT — Cross-Environment Attack Simulation

Hybrid cloud PT is among the most complex engagement types, as it may involve attack chains that traverse on-premises Active Directory, cloud identity systems, network transit zones, and multiple cloud environments. The attack surface is the intersection of all connected environments.

• Hybrid identity attacks: Exploiting Azure AD Connect sync accounts (MSOL account, ADSyncAccount) to move from on-premises to Azure cloud; ADFS golden SAML attacks
• Cloud-to-on-premises pivoting: Using cloud-hosted resources with site-to-site VPN access to pivot into on-premises networks
• Cross-cloud trust exploitation: Abusing cross-cloud federated identity trust relationships to gain access from one cloud provider to another
• Container escape and cluster takeover: Pod breakout to node-level access, RBAC privilege escalation to cluster-admin across any Kubernetes deployment
• Private cloud hypervisor exploitation: vCenter credential attack, VM escape (theoretical; only in isolated lab environments), snapshot and backup access
• CSPM tool access exploitation: If CSPM platforms have read-all permissions across clouds, gaining access to CSPM credentials grants visibility across the entire multi-cloud estate — high-value target in PT

• Any attempt to traverse cloud boundaries using identified trust relationships or transit paths
• Any exploitation of hybrid identity mechanisms (ADFS, Azure AD Connect, SAML trusts)
• Any container escape or Kubernetes cluster-admin exploitation
• Any hypervisor-level access attempts in private cloud environments

Multi-cloud PT requires a consolidated RoE that is acknowledged by the security lead at each constituent cloud provider account, the network team responsible for transit connectivity, and the on-premises infrastructure owner. Missing acknowledgement from any of these parties creates legal exposure for the tester if activities in that environment are subsequently challenged.

AI/ML VA — Definition & Scope

AI/ML security VA is an emerging discipline that applies security assessment principles to machine learning models, training pipelines, inference infrastructure, and LLM-integrated applications. The threat model for AI/ML systems differs significantly from traditional software — attacks may target model behaviour (adversarial inputs, prompt injection) rather than underlying infrastructure, and impacts may include model output manipulation, training data extraction, or model theft.

VA in this domain focuses on identifying attack surfaces and misconfigurations without actively conducting adversarial attacks that manipulate model behaviour or extract training data.

• Model Exposure Assessment: Identifying publicly exposed model APIs, model card information disclosure, model versioning policy review
• MLOps Pipeline Review: Training data storage access controls (S3/GCS/Azure Data Lake for training datasets), model registry access controls (MLflow, Vertex AI, SageMaker Model Registry), CI/CD pipeline security for ML workflows
• Inference Infrastructure: API authentication enforcement on model inference endpoints, rate limiting, input validation controls, logging and monitoring of inference requests
• LLM Application Review: Identifying prompt injection vulnerability patterns in system prompts, reviewing LLM output handling for downstream injection risks, assessing tool/function call authorisation in agentic LLM systems
• Data Security: Training data access controls, PII presence in training datasets (DPDP Act / GDPR relevance), embedding and vector database security
• Supply Chain: Third-party model provenance review (Hugging Face model card review, pickle file safety), dependency scanning for ML frameworks (PyTorch, TensorFlow, scikit-learn CVE mapping)
• Compliance: EU AI Act risk tier assessment, NIST AI RMF alignment review, OWASP LLM Top 10 (2023) gap analysis

AI/ML PT — Adversarial Model & Pipeline Exploitation

AI/ML PT involves controlled adversarial testing of model behaviour and ML infrastructure to confirm real-world attack viability. This is a rapidly evolving domain and engagement scopes must be defined with precision — model behavioural attacks are fundamentally different from infrastructure exploitation and require specialist expertise.

• Prompt Injection (Direct & Indirect): Crafting inputs that override system prompts, manipulate LLM behaviour, exfiltrate context window data, or cause the model to perform unintended actions (OWASP LLM01)
• Jailbreaking: Systematic attempts to bypass safety guardrails and content filters in LLMs using adversarial prompt engineering techniques (DAN, many-shot jailbreaking, etc.) — confirming that guardrail bypass is achievable
• Training Data Extraction: Using membership inference and extraction attacks to reconstruct training data from model outputs (requires strict RoE limiting extracted data volume and type)
• Model Inversion: Reconstructing input characteristics from model outputs — relevant for models trained on sensitive data (medical records, financial profiles)
• Adversarial Examples: Crafting perturbed inputs that cause systematic model misclassification (relevant for image recognition, fraud detection, security monitoring ML models)
• Supply Chain: Malicious Model Loading: Demonstrating pickle-based RCE through malicious model file loading (in isolated test environment only)
• Agentic System Exploitation: Exploiting tool-calling, RAG retrieval, or agent orchestration mechanisms to achieve unintended actions in agentic LLM systems
• MLOps Pipeline Exploitation: Exploiting misconfigured CI/CD pipelines to inject malicious code into training workflows or model serving infrastructure

• Any active prompt injection or jailbreaking attempt against a deployed LLM
• Any adversarial example generation targeting production model behaviour
• Any training data extraction or membership inference attack
• Any agentic system manipulation that causes the AI agent to perform unintended actions
• Any malicious model file loading or ML supply chain attack simulation

The RoE for AI/ML PT must additionally specify: the model version and deployment environment, maximum number of inference requests permitted (to prevent unintended model fine-tuning effects in online learning systems), data extraction volume caps, and researcher/tester qualification requirements.

IoT/OT VA — Definition & Permitted Activities

IoT/OT/Embedded security VA is the highest-risk assessment domain due to the potential for physical harm, operational disruption, and safety system failure. VA in this domain must be conducted with extreme caution — many VA-level activities that are routine in IT environments may be dangerous or damaging in OT/ICS environments due to the real-time operational nature of these systems. The principle of least-disruptive assessment governs all OT VA activities.

• Asset Inventory & Discovery: Passive network monitoring using OT-safe discovery tools (Claroty, Dragos, Nozomi Networks in passive sensor mode — NOT active scanning) to identify OT assets without sending crafted packets
• Architecture Review: Network diagram analysis, IT/OT segmentation (Purdue Model level assessment), DMZ design review, historian and SCADA communication path analysis
• Protocol Analysis (Passive): Monitoring industrial protocols (Modbus, DNP3, IEC 60870-5-104, PROFINET, EtherNet/IP, OPC-UA) via network tap without injecting traffic
• Configuration Review (Offline/Provided): PLC/RTU configuration file review (where provided), HMI software configuration assessment, engineering workstation review
• Firmware Analysis (Offline): Binary firmware extraction and analysis using Binwalk, FACT, Ghidra — identifying hardcoded credentials, backdoors, vulnerable components without running modified firmware on production devices
• Physical Security: Visual inspection of physical access controls, console port exposure, debug port accessibility (JTAG, UART — without connecting)
• Wireless: RF spectrum survey to detect unauthorised wireless devices, Zigbee/Z-Wave/LoRa protocol enumeration (passive)
• Compliance: IEC 62443 security level assessment, NERC CIP compliance gap review (for energy sector), ISA/IEC 62443 SL-1 to SL-4 gap analysis

IoT/OT PT — Controlled Adversarial Testing

OT/ICS PT is the most heavily constrained PT domain due to physical safety implications. In most cases, PT against live production OT systems is not recommended. Instead, PT should be conducted against: isolated lab replicas, offline test environments, or decommissioned equipment. Where live system PT is unavoidable (e.g., commissioned by critical infrastructure operators under regulatory mandate), it must follow NIST SP 800-82 and IEC 62443 testing guidelines with operations team co-presence and an immediate abort mechanism.

• IoT Device PT (Consumer/Enterprise IoT — non-OT):
  • Hardware exploitation: JTAG/UART debug port access for root shell, SPI/I2C flash extraction and analysis
  • Firmware extraction from physical device (flash chip reading) and emulation for further analysis
  • Bootloader security bypass (U-Boot unauthenticated console, secure boot bypass)
  • Default credential exploitation on device web interfaces and telnet/SSH
  • API backend PT (same as Domain 2 — APIs, but against the device's cloud backend)
  • Radio protocol exploitation: Zigbee network join without authentication, Z-Wave S0 downgrade, BLE pairing bypass, WiFi deauthentication attacks
• OT/ICS PT (Lab Environment Only):
  • Modbus command injection to test for unauthorised register read/write (on isolated hardware)
  • DNP3 protocol exploitation (authentication bypass, function code abuse)
  • HMI exploitation (client-side attacks on engineering workstations)
  • Historian server exploitation (OSIsoft PI, GE Proficy — known CVE exploitation in lab)
  • SCADA software exploitation (WinCC, iFIX, Ignition — in isolated environment)
  • Network zone bridging demonstration (confirming IT-to-OT lateral movement path)

• Any traffic injection into OT/ICS networks (even for testing purposes)
• Any authentication attempt against production OT devices
• Any physical hardware interface connection (JTAG, UART, SPI) without hardware-specific RoE
• Any radio protocol attack in operating frequency bands (must comply with Wireless Telegraphy Act / DoT regulations in India)
• Any firmware modification on production or operational devices

IoT/OT PT requires: dedicated hardware test environment provision in the RoE, OT engineering team co-presence during testing, defined system state monitoring and abort triggers (e.g., process alarm thresholds), Wireless Telegraphy authorisation for RF testing, and — for Critical Information Infrastructure in India — NCIIPC coordination prior to engagement.

11A — Social Engineering & Phishing

VA scope: Email gateway security configuration review (SPF, DKIM, DMARC, sandboxing), phishing simulation platform configuration review, security awareness programme gap analysis, OSINT-based staff profile enumeration (LinkedIn, WHOIS, breach database correlation — passive), pretexting scenario design documentation review.

PT scope: Spear phishing campaigns against target employees (credential harvesting, malware delivery simulation), vishing (voice phishing) against help desk, pretexting for physical access, business email compromise (BEC) simulation. MANDATORY: Social engineering PT requires individual-level or role-level written authorisation from HR and Legal (not just IT). Without this, employees may have legal recourse. Under DPDP Act 2023, phishing simulations that capture employee credentials must operate under data processor agreements and data must be deleted post-engagement.

11B — Mobile Applications (iOS & Android)

VA scope: Static application analysis (APK/IPA analysis using MobSF, jadx, Frida-based static hooking analysis), OWASP MASVS/MASTG compliance review, certificate pinning implementation review, application permission model review, sensitive data at rest/in transit analysis (metadata only — not decrypting protected data), third-party SDK security review.

PT scope: Runtime manipulation (Frida-based hooking to bypass certificate pinning, root/jailbreak detection bypass), traffic interception (MitM via Burp with pinning bypass), authentication token theft from device storage, deep link exploitation, inter-app communication (Intent) exploitation on Android, keychain/keystore exploitation on iOS.

11C — CI/CD Pipelines & DevSecOps Supply Chain

VA scope: GitHub/GitLab/Bitbucket repository secret scanning (TruffleHog, GitLeaks — for exposed credentials), branch protection policy review, CI/CD pipeline configuration review (GitHub Actions, Jenkins, GitLab CI, Azure DevOps), container image scanning (Trivy, Grype — CVE mapping), Infrastructure-as-Code (IaC) security scanning (Checkov, tfsec, Semgrep), dependency vulnerability scanning (Snyk, OWASP Dependency-Check), SBOM generation and third-party component risk review.

PT scope: Pipeline injection (injecting commands via vulnerable pipeline configuration — e.g., GitHub Actions expression injection), secrets extraction from CI environment variables, artifact tampering to inject malicious code into build outputs, dependency confusion attack simulation, container escape from CI runner environments, exploitation of OIDC token misconfiguration in cloud-connected pipelines.

11D — Physical Security Testing

VA scope: Physical security policy review, CCTV coverage gap analysis (from documentation/floor plans), access control system configuration review (badge reader placement, tailgating prevention design), server room and data centre physical access review (policy and documentation-based), visitor management process review.

PT scope: Tailgating attempts to breach access-controlled zones, badge cloning (HID/RFID clone attacks using authorised test equipment), lock picking and physical bypass of door controls (where explicitly in scope), dropping rogue devices (HID devices, network taps) — requires on-person authorisation letter at all times. CRITICAL: Physical PT testers must carry a signed, timestamped authorisation letter identifying them as security testers. Without this document, physical access attempts are criminal trespass. Premises security personnel must have an escalation contact available 24/7.

11E — Third-Party / Supply Chain Risk (Vendor VAPT)

VA scope: Third-party vendor security questionnaire review (SIG Lite, CAIQ), vendor SOC 2 Type II and ISO 27001 certificate review, publicly available security posture assessment (Bitsight, SecurityScorecard, UpGuard — passive scanning of vendor perimeter), contractual security obligation review (DPA, MSA security clauses), fourth-party risk identification.

Performing PT against vendor systems requires explicit written authorisation from the vendor — client authorisation alone is insufficient. If the vendor's systems are part of an integrated platform serving the client, a three-party RoE (client, vendor, testing team) is required. PT of vendor systems without vendor authorisation constitutes an attack on a third party's computer systems regardless of the client's data processing relationship with the vendor.

The following principles supersede all other guidance in this document and must be treated as absolute constraints across all domains, all engagement types, and all jurisdictions:

• No written RoE = No PT. This is a legal absolute, not a best practice recommendation. Any exploitation activity without a signed RoE is an unauthorised intrusion, regardless of client verbal authorisation, existing relationship, or good faith intent.
• Scope is a legal boundary, not a technical constraint. The ability to reach a system does not create the right to test it. IP adjacency, shared infrastructure, and network connectivity to out-of-scope systems do not authorise testing.
• VA stops at confirmation of impact. The moment an action confirms that a vulnerability is exploitable by producing a measurable effect (data retrieved, access granted, command executed), the VA boundary has been crossed. This is true regardless of the tool used.
• Cloud testing requires cloud provider compliance, not just client authorisation. AWS, Azure, and GCP each have testing policies that operate independently of client authorisation. Violation of these policies may result in account suspension regardless of the client relationship.
• OT/ICS systems must never be actively scanned or tested in production without a safety engineer present and an immediate abort mechanism. This is a safety requirement, not a security preference.
• Personal data accessed during VAPT is subject to DPDP Act 2023 and GDPR obligations. The testing context does not create a lawful basis for processing personal data beyond what is strictly necessary. RoEs must address data minimisation, synthetic data use, and evidence destruction procedures.
• Classification uncertainty = treat as PT. When any activity falls in a grey zone and the tester is uncertain of its classification, it must be treated as PT-level and proceed only with written RoE authorisation.