# Vantage Point Security Group, full content index > Full-content variant of llms.txt. Complete copy from every service page on the site, intended for AI-agent ingestion when a deeper context is required than the curated llms.txt summary. Last updated: 2026-06-28 Canonical site: https://www.vpsec.io/ Curated summary: https://www.vpsec.io/llms.txt Company: Vantage Point Security Group, founded February 2014 in Singapore. Offices: Singapore (HQ) · Indonesia (Jakarta) · Thailand (Bangkok) Consultants: 50+ CREST-registered consultants Annual testing hours: 80,000+ Velocity test cases: 4,000+ mapped to 100+ standards --- ## Capture The Flag, competitive record Live CTFtime team profile: https://ctftime.org/team/158703. Real-time JSON endpoint (24h edge cache): https://vpsec-sendgrid-email.azurewebsites.net/api/ctf-results. Snapshot baked at build time: 2026-06-28T06:48:54.904Z. Total events competed in: 30 Top-10 placements: 6 Podium finishes (1st / 2nd / 3rd): 1 Per-event list, newest first, best placements first within each year: ### 2025 - **Hack The System - Bug Bounty CTF**, placed #5 of 520 teams (ctftime event 2829) - **CrewCTF 2025**, placed #25 of 667 teams (ctftime event 2704) - **BrunnerCTF 2025**, placed #39 of 1,158 teams (ctftime event 2835) - **DownUnderCTF 2025**, placed #62 of 1,664 teams (ctftime event 2669) - **corCTF 2025**, placed #104 of 473 teams (ctftime event 2763) - **FortID CTF 2025**, placed #131 of 553 teams (ctftime event 2893) - **Hack.lu CTF 2025**, placed #180 of 299 teams (ctftime event 2842) - **SekaiCTF 2025**, placed #194 of 1,054 teams (ctftime event 2683) - **ImaginaryCTF 2025**, placed #368 of 1,414 teams (ctftime event 2799) - **Metared Argentina 2025**, placed #412 of 485 teams (ctftime event 3003) - **Cyber Apocalypse CTF 2025: Tales from Eldoria**, placed #603 of 4,035 teams (ctftime event 2674) ### 2024 - **TCP1P CTF 2024: Exploring Nusantara's Digital Realm**, placed #5 of 385 teams (ctftime event 2256) - **NahamCon CTF 2024**, placed #8 of 2,632 teams (ctftime event 2364) - **HTB Business CTF 2024: The Vault Of Hope**, placed #13 of 656 teams (ctftime event 2315) ### 2023 - **TCP1P CTF 2023: First Step Beyond Nusantara**, placed #3 of 499 teams (ctftime event 2001) - **Cyber Apocalypse 2023: The Cursed Mission**, placed #10 of 4,488 teams (ctftime event 1889) - **NahamCon CTF 2023**, placed #10 of 1,682 teams (ctftime event 2023) - **HTB Business CTF 2023: The Great Escape**, placed #27 of 698 teams (ctftime event 1989) - **TetCTF 2023**, placed #34 of 600 teams (ctftime event 1842) - **1337UP LIVE CTF**, placed #42 of 690 teams (ctftime event 2134) - **IrisCTF 2023**, placed #78 of 730 teams (ctftime event 1774) - **Tenable CTF 2023**, placed #637 of 1,183 teams (ctftime event 2055) ### 2021 - **HTB Business CTF 2021**, placed #13 of 297 teams (ctftime event 1386) - **Hacker's Playground 2021**, placed #24 of 733 teams (ctftime event 1396) - **RaRCTF 2021**, placed #29 of 845 teams (ctftime event 1342) - **InCTF 2021**, placed #37 of 603 teams (ctftime event 1370) - **FwordCTF 2021**, placed #84 of 428 teams (ctftime event 1405) - **corCTF 2021**, placed #96 of 904 teams (ctftime event 1364) - **UIUCTF 2021**, placed #169 of 657 teams (ctftime event 1372) - **BSides Noida CTF**, placed #321 of 411 teams (ctftime event 1397) --- ## CREST Approved Penetration Testing URL: https://www.vpsec.io/en/services/penetration-testing/ Eyebrow: Penetration Testing > CREST-accredited penetration testing across mobile, web, API, network, wireless, Active Directory, and thick-client environments, tailored to your technical environment and compliance needs. Penetration testing is ethical hacking under legal authorisation: simulating realistic attacks against systems before adversaries find their way in. Vantage Point delivers that capability at enterprise scale across Southeast Asia, with 50+ CREST-registered consultants, over a decade of regional experience, and the Velocity platform underpinning every engagement. CREST accreditation is the global benchmark for penetration testing quality. It validates not just consultant credentials, but the methodologies, evidence handling, and reporting standards behind the work. Every engagement we deliver under this service line meets those requirements. Where traditional penetration testing varies tester-to-tester, Velocity gives our consultants a structured, test-case-driven path through each engagement. Findings are reproduced, scored, and traced back to specific regulatory or technical requirements, so the report you receive is built for audit defensibility, not just remediation backlog. ### Why it matters, Why penetration testing is non-negotiable for regulated organisations. - **Regulators expect it, and increasingly specify how.** CSA Singapore, OJK Indonesia, and Bank of Thailand all reference penetration testing as a control expectation for financial services and critical infrastructure. Tests must be appropriate, scoped to the environment, and executed by competent providers. - **Vulnerability scanners only see what they have signatures for.** Most real-world breaches start with business-logic flaws, chained misconfigurations, and identity-driven attack paths, exactly the category of issues automated tools cannot reliably find. - **Boards are asking the questions auditors used to.** Quantified risk, traceable evidence, and remediation timelines now show up in board packs. Penetration testing that produces audit-defensible evidence, not just a PDF, is what lands at that level. ### What we test Vantage Point covers the full breadth of modern penetration testing. Engagements are usually combined: a mobile app rarely sits alone, there is a backend API, a cloud account, and an identity layer all in scope at once. **Application layer** Where most attack surface lives today, and where our roots as the original authors of OWASP MASTG and MASVS are most directly relevant. - Mobile applications (iOS, Android) - Web applications - REST and SOAP APIs - Thick-client desktop applications - Browser extensions and embedded SDKs **Infrastructure Layer** External-facing infrastructure, internal lateral-movement paths, wireless rollouts, and the Active Directory environments most regional enterprises still run on. - External and internal network testing - Wireless and Wi-Fi networks - Active Directory and identity environments - Network segmentation validation - Cloud-hosted infrastructure (where in scope) **Hardware** IoT and embedded devices tested in our regional hardware lab, covering hardware interfaces, firmware, communications, and the supporting cloud / mobile ecosystem. - Hardware interfaces, UART, JTAG, SWD, SPI, I²C, eMMC, NAND - Debug pads, USB, serial consoles, boot-mode access - Firmware extraction, unpacking, binary and filesystem analysis - Bootloader, kernel, and embedded Linux / RTOS review - Hardcoded secrets, certificates, and update-package analysis - Secure boot, signing, and rollback protection - Wireless and radio, Wi-Fi, BLE, Zigbee, Z-Wave, LoRa, cellular - Device-to-cloud and device-to-mobile flows - Tamper resistance and physical attack surface ### What we typically find - **Authentication & authorisation gaps.** Broken access control between user roles, insecure password reset flows, JWT signature weaknesses, and IDOR exposing other tenants' data. - **Business logic abuse.** Bypassing payment flows, race conditions in account creation, replay-attack tolerance, and workflow shortcuts the application was never designed to permit. - **Sensitive data exposure.** PII or financial data in error messages, in debug endpoints, in client-side JavaScript, or in mobile application bundles. - **Identity & privilege escalation.** Domain user to domain admin in a few hops via Kerberoasting, ACL abuse, or service-account password reuse. - **Configuration weaknesses.** Default credentials still present, deprecated TLS, exposed management interfaces, weak segmentation between production and corporate networks. - **Third-party and integration risk.** Vulnerable libraries with known CVEs, insecure SSO integrations, leaked API keys, supply-chain dependencies running with excessive permissions. ### Deliverables - Cryptographically signed final report - Findings mapped to Velocity test cases - CVSS 3.0, 3.1, and 4.0 scoring - Reproduction steps, payloads, screenshots - Remediation guidance and configuration examples - Executive and technical reporting - Standards / regulator coverage matrix ### Frequently asked questions **Q: How long does a typical engagement take?** A: Before engaging with a client we hold a scoping session to better understand your application and environment. Most penetration testing engagements take 2–3 weeks from start to completion. **Q: What is the difference between a vulnerability assessment and a penetration test?** A: A vulnerability assessment identifies known weaknesses, usually with automated tools. A penetration test goes further: exploiting weaknesses (where safe), chaining them together, and demonstrating real business impact. Penetration testing typically combines both approaches. **Q: Do you test in production, or in a non-production environment?** A: Wherever possible we prefer to test in non-production environments, UAT, staging, dedicated test platforms, or representative pre-production builds. That removes the risk of customer-facing impact and lets us run deeper, more aggressive techniques than a live system would safely tolerate. When non-production isn't feasible, which is common for external network testing, cloud control-plane work, identity testing, and red-team scopes, we test production under written Rules of Engagement: agreed change windows, abort criteria, throttled scan intensity, and your incident-response team briefed in advance so detection signals can be correlated with our activity rather than triaged as a live incident. **Q: Do you provide retesting after we fix findings?** A: Yes. A retest cycle on remediated findings is included in every engagement so that fixes are verified, not just claimed, before the report is closed. **Q: How does your reporting support regulatory audit?** A: Each engagement produces a complete compliance report that records, per test case and per standard, what was executed, what passed, what failed, and the evidence captured, so auditors can map our work directly to their control matrix rather than relying on a generic "we did a penetration test" summary. ### Call to action **Test your defences the way attackers actually test them.**, Speak to a CREST-accredited consultant about scoping your next penetration testing engagement. --- ## Mobile Application Penetration Testing URL: https://www.vpsec.io/en/services/penetration-testing/mobile-application/ Eyebrow: Penetration Testing → Mobile Application > CREST-accredited mobile application penetration testing for iOS and Android, aligned with OWASP MASTG and MASVS, the standards Vantage Point originally authored. Mobile applications carry a disproportionate share of customer trust: banking, healthcare, government identity, payment. They also concentrate risk in a way few other interfaces do, running on uncontrolled devices, accessing sensitive backends, and storing data the user is rarely aware of. Mobile penetration testing is what tells you whether that risk has been managed or merely assumed. Vantage Point's mobile application testing combines static and dynamic analysis with extensive manual penetration testing across the full mobile attack surface. Engagements are MASTG-driven, meaning every test maps back to a published procedure in the global standard we originally helped author. Coverage spans both the application and its supporting environment, backend APIs, network communication, platform integrations, certificate pinning and anti-tamper controls, and the resilience of the application against reverse engineering. Findings are reproducible on the device or emulator they were discovered on. ### Why it matters - **Mobile sits on uncontrolled devices.** Unlike server-side code, a mobile app runs on whatever device the customer owns, potentially rooted, jailbroken, instrumented, or running on an emulator. Threat model has to assume the attacker has full control of the runtime. - **Regulatory pressure is intensifying.** Singapore's Safe App Standard, MAS expectations on financial mobile apps, and similar moves regionally all push mobile security from "nice to have" to "evidence required". - **Backend exposure compounds the risk.** Mobile applications are typically the noisiest, most-attacked entry into otherwise well-protected backend APIs. Testing the app without testing what it talks to misses most of the real risk surface. ### What we test **Application controls** On-device controls covering data, authentication, cryptography, and platform integration, the MASVS L1/L2/R requirements. - Data storage and privacy - Authentication and session management - Cryptography implementation - Platform interaction (intents, schemes, permissions) - Resilience against reverse engineering and tampering **Backend & transport** The surfaces the application talks to. Often where the highest-impact findings live. - Backend API security - Network communication and certificate pinning - WebView and embedded-browser security - Inter-process communication - Code quality, obfuscation, and anti-tamper ### What we typically find - **Insecure data storage.** PII and tokens cached in shared preferences, sensitive data in WebView storage, keychain misuse, leaking via screenshots or system logs. - **Broken cryptography.** Hardcoded keys, weak algorithms (DES, ECB), home-grown crypto, missing IV randomisation, predictable session generation. - **Insecure communication.** Missing or weak certificate pinning, mixed-content channels, vulnerable handshake configurations, insecure WebSocket fallbacks. - **Authentication weaknesses.** Step-up bypassed, fallback to weaker auth, biometric prompt UX defeating its security purpose, session not bound to device. - **Backend authorisation flaws.** IDOR exposing other users' data through mobile-API endpoints, missing tenant checks, debug endpoints reachable in production builds. - **Reverse-engineering exposure.** No root/jailbreak detection, anti-debug controls trivially defeated, sensitive logic in client where it belongs server-side. ### Standards and frameworks - OWASP MASTG - OWASP MASVS - Singapore Safe App Standard (where applicable) - NIST mobile guidance ### Frequently asked questions **Q: Do you need a rooted or jailbroken device?** A: Yes, MASTG manual testing requires instrumented test devices. We use our own test devices; client devices are not modified. **Q: How do you test apps that use strong anti-tamper / RASP?** A: Resilience testing under MASVS-R is explicitly part of the methodology. We evaluate whether those controls do what they claim, in coordination with the development team, rather than treating bypass as the goal. **Q: Can you test the backend API at the same time?** A: Strongly recommended, most high-impact findings live in the API. Combined mobile + API engagements are the common pattern. **Q: What about React Native, Flutter, Xamarin?** A: All supported. Cross-platform frameworks have their own peculiarities (bundled JavaScript, asset packaging, native bridges) which we have specific test cases for. --- ## Web Application Penetration Testing URL: https://www.vpsec.io/en/services/penetration-testing/web-application/ Eyebrow: Penetration Testing → Web Application > CREST-accredited web application penetration testing, manual depth beyond automated scanning, mapped to OWASP WSTG and the OWASP Top 10. Web applications are the front door of the modern enterprise, and the most consistently attacked layer. Almost every reported breach of the last decade has had a web application step in the chain. Manual web penetration testing is what catches the categories of flaw that scanners cannot. Vantage Point web application engagements combine automated scanning to cover breadth with extensive manual testing for the business-logic flaws, authorisation issues, and chained vulnerabilities that scanners cannot reliably surface. Every engagement follows the OWASP WSTG methodology, mapped to the OWASP Top 10 and ASVS where verification-level evidence is required. Findings are reproduced with request/response captures, payloads, and screenshots, built so engineering can fix them without re-discovering them, and so audit can verify them without re-testing them. ### Why it matters - **Web is where breaches actually start.** Year over year, web application vulnerabilities feature in the largest single share of public breach reports. Network controls cannot compensate for an exposed application endpoint. - **Scanners do not find authorisation flaws.** IDOR, broken access control, and multi-role abuse are the most common high-impact findings in real engagements. None of them are reliably found by automated tools. - **PCI DSS and ASVS evidence is increasingly expected.** Regulators, banks, and large enterprise customers ask for OWASP-aligned web testing evidence as part of vendor onboarding and audit cycles. ### What we test **Common vulnerability classes** Coverage of the OWASP Top 10 and the broader WSTG procedure set. - SQL, NoSQL, command, and template injection - Cross-site scripting (XSS), stored, reflected, DOM - CSRF and SSRF - XML external entity (XXE) - Insecure deserialisation - Server-side request forgery **Logic, access & configuration** The categories most engagements actually deliver value on, and where manual testing is decisive. - Authentication and session management - Authorisation, role enforcement, and IDOR - Business logic and workflow abuse - Input validation and output encoding - Crypto and data-at-rest handling - Configuration management ### What we typically find - **Broken access control.** IDOR on tenant-scoped resources, missing authorisation on internal API endpoints reached from the front-end, admin functions accessible to standard users by URL manipulation. - **Authentication weaknesses.** Username enumeration via response timing or error messages, insecure password reset, predictable session tokens, MFA bypass on legacy flows. - **Injection.** SQL injection on legacy reporting endpoints, SSRF in URL-fetching features reaching cloud metadata, server-side template injection in admin UIs. - **XSS.** Stored XSS in user-content fields, DOM-based XSS in client-side routing, reflected XSS reachable via document.location. - **Sensitive data exposure.** PII in error messages, secrets in JavaScript bundles, internal hostnames leaking in HTTP responses, full account objects returned to UIs that need a name only. - **Misconfigured security headers / cookies.** Missing HSTS, weak CSP, cookies without HttpOnly or Secure, SameSite still set to None on session cookies. ### Standards and frameworks - OWASP WSTG - OWASP Top 10 - OWASP ASVS - PCI DSS v4.0 (web application requirements) ### Frequently asked questions **Q: Do you provide test accounts, or do we?** A: Typically you. We test under representative roles, at minimum standard user and administrator, so authorisation enforcement can be properly evaluated. **Q: Will scanning affect application performance?** A: We tune scan intensity to your environment. For sensitive production systems we throttle and exclude known-fragile endpoints; for staging we are more aggressive. **Q: Do you cover GraphQL and modern API patterns?** A: Yes. GraphQL, gRPC, and message-driven backends have specific test cases, including introspection, depth-limit bypass, and broken object-level authorisation. **Q: How is this different from your API penetration testing service?** A: Web testing focuses on the browser-facing application; API testing focuses on the underlying service contract. Many engagements scope both together because real-world attack chains span the two. --- ## API Penetration Testing URL: https://www.vpsec.io/en/services/penetration-testing/api/ Eyebrow: Penetration Testing → API > CREST-accredited API penetration testing across REST, GraphQL, gRPC, and SOAP services, aligned with the OWASP API Security Top 10 and NIST guidance. APIs are the operational substrate of the modern enterprise. They tie applications to backends, integrate SaaS, connect mobile to cloud, and increasingly carry the highest-value business logic in any organisation. They also concentrate risk in ways the surrounding UI layer rarely makes visible, which is why API-specific testing now consistently outproduces web testing for high-impact findings. Vantage Point's API engagements combine threat modelling against the documented contract with deep manual exploitation against the running service. We test authentication, authorisation, data exposure, and business-logic flaws across REST, GraphQL, gRPC, and legacy SOAP services. Findings map to the OWASP API Security Top 10 and to the specific test cases in Velocity's API library. Where APIs are mobile or browser-facing, engagements typically combine with the corresponding web or mobile testing service so authorisation can be tested end-to-end from the client through to the backend. ### Why it matters - **APIs concentrate authorisation risk.** A web UI gives one URL per page. An API gives hundreds of endpoints, each with their own authorisation contract. A single missing check on one of them is enough for a high-impact breach. - **Documentation rarely matches reality.** API specs drift from running services. Endpoints get added during emergencies, parameters acquire new meanings, undocumented paths persist for years. Testing against the running service finds what spec review cannot. - **Mobile and partner integrations magnify exposure.** APIs were often built for "the mobile app" or "this trusted partner". Once published, they get hit by everyone, including attackers reverse-engineering client code to find them. ### What we test **Authentication & authorisation** Where most API breaches actually start. Coverage maps to OWASP API Top 10 #1, #3, and #5. - Broken object-level authorisation (BOLA / IDOR) - Broken authentication - Broken function-level authorisation - JWT signature confusion and algorithm abuse - OAuth flow weaknesses and consent abuse **Data, infrastructure & abuse** Categories that scale with API surface, and where consistent test cases catch what ad-hoc testing misses. - Excessive data exposure - Mass assignment - Unrestricted resource consumption - API injection (SQL, NoSQL, command, XML, JSON) - Security misconfiguration and management endpoints - Insufficient logging and monitoring ### What we typically find - **BOLA / IDOR.** Endpoints returning data scoped only by user-supplied identifier; numeric IDs incremented to enumerate other tenants; cross-tenant reads via internal reference fields. - **Broken function-level authorisation.** Admin endpoints reachable by any authenticated user; role checks present on UI but absent on the API; verb-based bypass (POST vs PUT) on protected paths. - **JWT / token flaws.** Tokens accepted with "none" algorithm, RS-to-HS confusion, missing audience claim validation, refresh tokens valid for far longer than session security warrants. - **Excessive data exposure.** Endpoints returning full user objects when only name and avatar are needed, internal IDs, computed flags, or backend system fields leaked to the client. - **Mass assignment.** POST/PUT bodies accepting fields the UI never sends, role, is_admin, balance, and silently updating sensitive attributes. - **Rate limiting & abuse.** Login endpoints without throttling, OTP endpoints reusable, expensive query endpoints with no quota allowing DoS via crafted requests. ### Standards and frameworks - OWASP API Security Top 10 - OWASP API Security Testing Guide - NIST SP 800-204 - PCI DSS v4.0 (where applicable) ### Frequently asked questions **Q: Can you test if we only have OpenAPI / Swagger / GraphQL schema?** A: Yes. Documentation is a starting point, we then enumerate the running service, including endpoints not in the spec, before manual testing. Most real-world findings come from this enumeration step. **Q: How do you handle authenticated testing?** A: You provide tokens or credentials for each role we should test under. We always test with at least two distinct roles to evaluate authorisation properly, typically standard user, administrator, and any tenant-scoped roles. **Q: Do you test third-party APIs we depend on?** A: Testing third-party APIs is typically prohibited by their terms of service. We focus on your own services, including the integration layer that consumes external APIs (where vulnerabilities are still your problem). **Q: How does your testing differ for GraphQL vs REST?** A: GraphQL has its own attack model: introspection, depth and complexity, batching abuse, broken object-level authorisation on type relationships. We test all of it with GraphQL-specific tooling and methodology. --- ## Network Penetration Testing URL: https://www.vpsec.io/en/services/penetration-testing/network/ Eyebrow: Penetration Testing → Network > CREST-accredited external and internal network penetration testing, across routers, switches, servers, endpoints, firewalls, email servers, and exposed systems. Network penetration testing simulates how a capable attacker would move through your infrastructure, from the public internet at the perimeter, through any toehold that exists, and into the internal systems that hold the data and operational capability that matter. Vantage Point delivers network engagements in two complementary forms. External tests focus on perimeter-exposed services, asking "what can be done from outside the firewall?". Internal tests focus on the worst-case scenario most organisations should be testing for, "if an attacker is already inside, what is the path to domain admin, to crown-jewel data, and to operational impact?". Both engagement types follow a disciplined methodology, reconnaissance, enumeration, exploitation, post-exploitation, lateral movement, and impact analysis, under Rules of Engagement that protect operations while keeping the test realistic. ### Why it matters - **The perimeter is more porous than most diagrams show.** Cloud migrations, VPN appliances, shadow IT, and SaaS integrations all create exposure outside the textbook perimeter. Network testing is what catches it. - **Internal movement is where damage actually scales.** Once inside, most networks present a flat blast radius. A single workstation compromise frequently becomes domain admin in hours, and the controls to stop that path were never tested. - **PCI DSS and ISO 27001 ask for it explicitly.** Both standards require periodic network penetration testing as a control. Most regional regulators expect the same for critical-information infrastructure. ### What we test **External & perimeter** Systems exposed to the public internet, intentional and accidental. - Exposed services and systems - Firewall and routing controls - Email infrastructure (SPF, DKIM, DMARC, gateway) - DNS infrastructure and subdomain takeover - Configuration weaknesses and weak protocols - VPN gateways and remote-access services **Internal & lateral** The worst-case scenario most organisations should be testing for, assumed breach, working inwards from an internal foothold. - Access control flaws - Network segmentation testing - Privilege escalation paths - Lateral movement opportunities - Endpoint and EDR effectiveness - Internal service exposure ### What we typically find - **Unpatched perimeter services.** Internet-facing services running versions with known RCE; legacy VPN gateways with public exploits; management interfaces published to the internet. - **Flat internal networks.** Workstation subnets that can talk freely to production servers; no segmentation between corporate and OT; PCI scope undefined in practice. - **Weak protocols.** SMBv1, NTLM, LLMNR/NBNS poisoning surface, telnet on management interfaces, deprecated TLS still accepted. - **Credential reuse.** Local admin password reused across thousands of endpoints, service-account passwords shared with regular users, credentials cached in Group Policy preferences. - **Missing egress controls.** Workload subnets able to reach the internet freely, no DNS filtering, no controls on outbound on ports other than 80/443. - **Detection blind spots.** No SIEM coverage on critical segments, EDR exclusions covering common attacker tooling paths, alerting on commodity malware only. ### Methodology 01. **Reconnaissance**, Open-source intelligence and surface enumeration. 02. **Scanning & enumeration**, Service discovery and version mapping. 03. **Exploitation**, Manual exploitation of identified weaknesses. 04. **Post-exploitation**, Privilege escalation, lateral movement, impact analysis. 05. **Reporting & debrief**, Risk-ranked findings with reproduction and remediation. ### Standards and frameworks - CIS - NIST SP 800-115 - ISO 27001:2022 - PCI DSS v4.0 - SOC 2 ### Frequently asked questions **Q: External or internal, which should we start with?** A: For most organisations, the highest-value engagement is an internal / assumed-breach test, because that mirrors the post-phishing reality. External tests are still important and usually run annually; internal tests reveal where most damage actually scales. **Q: Will this disrupt production?** A: External testing is generally non-disruptive. Internal testing under assumed-breach is designed not to impact business operations, with abort criteria defined upfront. We never run intentionally destructive techniques unless explicitly scoped. **Q: Can you validate our segmentation for PCI DSS?** A: Yes, segmentation testing is a defined service. PCI DSS v4.0 requires it at least every 12 months for organisations using segmentation to reduce scope; we structure the engagement to produce the evidence the QSA needs. **Q: Do you provide retesting?** A: Yes. Every engagement includes a retest cycle on remediated findings so fixes are validated before the report is closed. --- ## Wireless Network Penetration Testing URL: https://www.vpsec.io/en/services/penetration-testing/wireless-network/ Eyebrow: Penetration Testing → Wireless > CREST-accredited wireless and Wi-Fi penetration testing, surfacing encryption, authentication, and segmentation weaknesses across corporate wireless deployments. Wireless networks are the most frequently-overlooked entry point in regional enterprises. They reach beyond the physical perimeter, often use legacy authentication, and are routinely deployed by facilities teams without security review. Wireless penetration testing is what turns that surface from "we have Wi-Fi" into a quantified security position. Engagements typically combine remote pre-engagement work, checking 802.1X / RADIUS configuration, certificate handling, and policy posture, with on-site wireless capture and active attack-path testing within the radio range of your facilities. Coverage spans the corporate SSID, guest networks, BYOD segments, and operational technology wireless deployments where in scope. Findings include both immediate vulnerabilities and longer-term posture issues like segmentation, monitoring, and rogue-AP detection. ### Why it matters - **Wireless reaches outside your physical perimeter.** Adjacent buildings, car parks, lobbies, wireless signal frequently extends well beyond where physical security ends. The attack surface is uncontrolled by design. - **Authentication missteps compound quickly.** 802.1X / RADIUS misconfigurations, missing certificate validation on clients, and weak passphrase policies are routine, and they each give an attacker corporate-credential equivalent access. - **Segmentation between wireless and core often does not exist.** Once on the wireless network, can the attacker reach domain controllers, production servers, or OT systems? The answer is too often "yes, with no further authentication required". ### What we test **Encryption & authentication** How the network proves who clients are and how their traffic is protected, including the 802.1X / RADIUS pathway most enterprises actually rely on. - WPA2 / WPA3 implementation weaknesses - Weak passphrases and PSK exposure - WPS PIN vulnerabilities - 802.1X / RADIUS configuration - Certificate handling and validation **Attack vectors & segmentation** Active attack-path testing within radio range, plus how access to wireless translates into access to the rest of the network. - Evil twin and rogue access points - MAC spoofing and bypass of MAC filtering - Deauthentication and downgrade attacks - Man-in-the-middle on wireless clients - Segmentation between wireless and core - Logging, monitoring, and rogue-AP detection ### What we typically find - **Weak certificate validation on corporate Wi-Fi.** Clients accepting any certificate signed by any CA, no certificate pinning to the RADIUS server, evil-twin attack paths trivially available. - **Passphrase leakage.** Pre-shared keys handed out via reception desks, on training-room whiteboards, or via help-desk tickets without rotation. - **No segmentation post-association.** Once associated to corporate Wi-Fi, full reachability to internal services with no further authentication required. - **Guest network bridging.** Guest networks accidentally bridged to corporate VLANs through misconfigured controllers or shared infrastructure. ### Standards and frameworks - IEEE 802.11 - NIST SP 800-153 - CIS Benchmarks ### Frequently asked questions **Q: Do you need to be on-site?** A: For active wireless testing, yes, testing happens within radio range. Configuration review and policy assessment is done remotely. Most engagements combine both. **Q: Will testing disrupt our wireless users?** A: Deauthentication and similar techniques are disruptive by design. We schedule disruptive testing in agreed windows or in low-occupancy times, and avoid critical operational segments unless explicitly scoped. **Q: Can you cover multiple sites?** A: Yes. Multi-site engagements are common, typically one anchor site with full coverage and lighter targeted testing at remote sites for consistency checks. --- ## Active Directory Penetration Testing URL: https://www.vpsec.io/en/services/penetration-testing/active-directory/ Eyebrow: Penetration Testing → Active Directory > CREST-accredited Active Directory penetration testing, exposing privilege escalation paths, credential weaknesses, and configuration flaws across enterprise domain environments. Active Directory is still the identity backbone of most regional enterprises. It is also the single most consistent weak point in real-world breaches, the place where a phished workstation becomes domain admin in hours, not weeks. Active Directory penetration testing measures how short that path actually is in your environment. Engagements run as authenticated assumed-breach tests from a standard domain user position. From there, our consultants enumerate the domain, map privilege escalation paths, and exercise the attack chains that real adversaries use, Kerberoasting, ACL abuse, ADCS misconfiguration, delegation flaws, and credential reuse. Hybrid identity is increasingly part of scope. Where your environment federates on-prem AD with Azure AD / Entra ID, engagements can cover the cross-environment trust paths that real attacks now exploit. ### Why it matters - **Domain compromise is operational impact.** Once an attacker holds domain admin, every workstation, every file server, every line-of-business system that authenticates against AD is owned. There is no remediation short of recovery. - **Most paths to DA are years old and undetected.** ACL flaws, service-account password reuse, and ADCS misconfigurations have existed in most environments since they were deployed. They have never failed because they have never been tested. - **Hybrid identity multiplies the surface.** Federating AD with Azure AD / Entra adds new attack paths, token theft, consent phishing, federated escalation, that traditional AD testing alone does not cover. ### What we test **Credentials & authentication** - Password policy weaknesses - Kerberoasting and AS-REP roasting - Service account abuse - NTLM relay and downgrade attacks - Pass-the-hash and pass-the-ticket - LAPS coverage and gaps **Domain, policy & hybrid** - ACL flaws and BloodHound-style attack paths - Unprotected admin groups and Tier-0 boundaries - GPO misconfigurations - Active Directory Certificate Services (ESC1–ESC11) - Domain and forest trust relationships - Azure AD / Entra hybrid identity (where in scope) - Logging and monitoring gaps ### What we typically find - **Path to domain admin in hours.** Domain user to DA via Kerberoasting on a weak service-account password; ACL abuse on a Tier-0 group; ADCS ESC1 template still enabled. - **Credential reuse and exposure.** Local admin password identical across thousands of endpoints, service-account credentials in GPP, cleartext credentials in scripts on file shares. - **Tier-0 boundary erosion.** Domain admins logging into workstations for daily work, helpdesk accounts with DA-equivalent ACLs, service accounts running as DA "temporarily". - **ADCS misconfiguration.** Vulnerable certificate templates (ESC1 / ESC4 / ESC8), CA configured with NTLM-enabled HTTP endpoints, EDITF_ATTRIBUTESUBJECTALTNAME2 still set. - **Detection blind spots.** Kerberoast not alerted on, AdminSDHolder modification not monitored, DCSync attempts not flagged, golden-ticket use undetected. ### Standards and frameworks - MITRE ATT&CK - Microsoft Securing Privileged Access - NIST SP 800-53 - CIS Microsoft Active Directory ### Frequently asked questions **Q: What level of access do you need?** A: A standard domain user account at minimum, that is the realistic starting point after a phishing compromise. We do not need elevated access provided in advance; demonstrating the path from standard user to higher privilege is the point of the exercise. **Q: Is this safe to run in production?** A: Yes, with care. AD testing techniques are non-destructive by design; we avoid known-fragile activity. We brief detection and IR teams on the engagement timeline so internal alerts can be correlated to our activity, not investigated as a real incident. **Q: Do you cover Azure AD / Entra ID and hybrid identity?** A: Yes, increasingly the bigger source of findings. Hybrid identity engagements cover federation paths, conditional access bypass, token theft, and consent-phishing surfaces in addition to on-prem AD. --- ## Thick Client Penetration Testing URL: https://www.vpsec.io/en/services/penetration-testing/thick-client/ Eyebrow: Penetration Testing → Thick Client > CREST-accredited thick client penetration testing for desktop applications, covering local storage, communication, authentication, cryptography, and reverse engineering risks. Thick client applications, desktop trading platforms, banking workstations, healthcare records systems, industrial control software, remain the backbone of many regulated environments. They are also poorly understood from a security standpoint, often relying on assumptions that no longer hold: that the user is trusted, that the network is internal, that the binary cannot be inspected. Thick client testing combines static analysis of the binary, dynamic analysis of the running application, and inspection of the communication protocols it uses to talk to backend services. Common environments include .NET (WPF / WinForms), Java (Swing / JavaFX), Electron, native Windows / macOS / Linux applications, and Citrix-published desktops. Most thick client engagements end up surfacing two distinct categories of risk: local-machine weaknesses (data at rest, credential storage, escalation paths) and protocol-level weaknesses in how the application talks to its server (authentication, authorisation, replay protection). ### Why it matters - **Server-side assumptions get tested differently here.** Thick clients ship logic to the user's machine. Anything assumed to be "trusted client behaviour" can be modified by an attacker who can run their own debugger. - **Legacy protocols often persist.** Thick client backends often run on older protocols, custom TCP, deprecated SOAP, raw socket frames, with security characteristics that have never been formally reviewed. ### What we test **Application controls** - Local storage weaknesses - Authentication flaws - Improper cryptography - Improper authorisation (server-side checks bypassable from client) - Sensitive data exposure in memory or disk **Runtime, protocol & build** - Communication protocol weaknesses - Insecure communication - Security misconfiguration - Known vulnerable components - Reverse engineering exposure - Insufficient logging - Update / auto-update integrity ### What we typically find - **Trusted client logic.** Authorisation enforced only on the client; price or permission checks done in the GUI but not on the server; admin features hidden by UI but reachable by direct protocol message. - **Credentials and tokens at rest.** Cached credentials in local files unprotected, tokens in registry, embedded credentials in the binary for legacy service accounts. - **Protocol weaknesses.** Custom protocols without integrity protection, replay-tolerant authentication, deprecated TLS still accepted on management channels. - **Update channel risk.** Auto-update over HTTP without signature verification, update server reachable without authentication, downgrade attacks possible. ### Standards and frameworks - OWASP ASVS - OWASP Top 10 - NIST guidance - Vendor framework guidance (Microsoft, Oracle, Electron) ### Frequently asked questions **Q: Do you need source code?** A: Helpful but not required. Thick client engagements commonly proceed from binary only, disassembly, debugging, and protocol analysis. Source access accelerates findings for static-code categories. **Q: Will you test the backend service too?** A: Usually yes, the value of testing the client without testing what it talks to is limited. Combined engagements are standard. --- ## IoT Hardware Testing URL: https://www.vpsec.io/en/services/iot-hardware-testing/ Eyebrow: IoT Hardware Testing > Security testing for connected devices, firmware, embedded systems, and hardware attack surfaces, aligned with the EU Cyber Resilience Act (CRA), the CSA Singapore Cybersecurity Labelling Scheme, and regional IoT and critical-infrastructure expectations across Southeast Asia. Connected devices create attack surfaces that span hardware, firmware, wireless protocols, mobile applications, cloud APIs, supply chains, and physical interfaces. Vantage Point's IoT Hardware Testing service helps product teams, manufacturers, and enterprises identify exploitable weaknesses before devices are deployed into customer, enterprise, industrial, or critical environments. IoT and embedded products often combine physical access, firmware, wireless communications, cloud management, mobile applications, and long device lifetimes. A weakness in any layer can expose credentials, enable device takeover, compromise customer data, bypass product controls, or create a foothold into enterprise and operational environments. Engagements are evidence-led and consultant-driven. Findings are reproduced, scored, and mapped to the standards that apply to your product, market, and deployment environment, including the CRA and ETSI EN 303 645 for European market access, and the CSA Singapore Cybersecurity Labelling Scheme (CLS) for consumer devices entering the Singapore market. ### Why it matters, Connected hardware expands the attack surface beyond software. - **Firmware exposure.** Hardcoded credentials, insecure update packages, leaked keys, vulnerable libraries, unsafe bootloaders, and unauthenticated services routinely surface in firmware that has never been independently reviewed. - **Hardware attack surface.** Exposed UART, JTAG, SWD, SPI, eMMC, NAND, USB, debug pads, removable storage, and insecure production interfaces give physical attackers direct access to secrets and trust boundaries. - **Wireless and protocol risk.** Weak BLE, Wi-Fi, Zigbee, MQTT, CoAP, and proprietary radio implementations, insecure pairing, replay, downgrade, and unauthenticated command channels are common in shipping products. - **Cloud and mobile ecosystem risk.** Device APIs, mobile apps, onboarding flows, access tokens, telemetry, cloud storage, and fleet management platforms are often the easiest path to large-scale device compromise. - **Lifecycle and update risk.** Insecure OTA updates, lack of signed firmware, weak rollback protection, poor vulnerability handling, and limited product support all turn into long-tail security debt for shipped devices. - **Regulatory and market access risk.** Product teams increasingly need evidence that devices were designed, tested, maintained, and updated against recognised cybersecurity expectations, the CRA for European market access, the CSA Singapore Cybersecurity Labelling Scheme for consumer IoT entering Singapore, and MAS, OJK, and Bank of Thailand frameworks where devices touch regional financial or critical-infrastructure workflows. ### What we test Coverage spans hardware, firmware, communications, companion applications, and cloud. Engagements scope which layers are in play based on the device, deployment, and standards alignment required. **Hardware interfaces** Physical access changes the threat model. We inspect the device, locate debug and storage interfaces, and validate whether they can be used to extract secrets or modify trust. - UART, JTAG, SWD, SPI, I²C - eMMC, NAND, removable storage - USB and serial consoles - Debug pads and boot-mode access - Physical tamper points and casing **Firmware and embedded software** Firmware contains the operational logic, credentials, libraries, and trust decisions that determine whether the device can be compromised end-to-end. - Firmware extraction and unpacking - Filesystem, bootloader, kernel review - Embedded Linux / RTOS analysis - Binary and library analysis - Hardcoded secrets and configuration - Update mechanism and secure boot review **Device communications** Pairing, provisioning, and runtime communications often carry weaker security than the equivalent enterprise channels, and authenticate fewer things than they appear to. - Wi-Fi, BLE, Zigbee, Z-Wave - MQTT, CoAP, HTTP(S), proprietary protocols - Pairing and provisioning flows - Replay and downgrade resistance - Encryption and authentication **Companion applications** Mobile apps and web portals frequently hold the credentials, tokens, and onboarding logic that an attacker needs to compromise the device. - iOS and Android applications - Local storage and token handling - API communication and transport security - Onboarding and pairing workflows - Cryptographic implementation **Cloud and fleet management** Device identity, registration, and management platforms are increasingly where large-scale device compromise actually happens. - Device identity and registration - Cloud APIs and access control - Firmware delivery and telemetry - Tenant isolation and storage permissions - Administrative and support interfaces **Product lifecycle** The CRA and modern product security expectations look beyond the device itself, at how vulnerabilities are handled, how updates are delivered, and how risk is managed over the product's life. - Vulnerability disclosure and handling - Patching and secure update process - SBOM and third-party component risk - Production hardening - Factory reset and decommissioning - Logging and auditability ### What we typically find - **Debug interfaces in production.** Unauthenticated UART shell exposed on production devices; JTAG/SWD enabled without lock; recovery / boot modes reachable without authentication. - **Firmware secrets.** Hardcoded credentials, embedded private keys, API tokens, and signing material extracted from production firmware images. - **Update mechanism weaknesses.** OTA update packages can be modified or downgraded; devices accept unsigned firmware; rollback protection missing or bypassable. - **Secure boot gaps.** Secure boot disabled in shipped builds; signature verification bypassable; firmware readout protection not enabled on flash. - **Wireless and protocol abuse.** BLE pairing replayed or hijacked; MQTT topic permissions overly broad; proprietary radio commands accepted without authentication. - **Ecosystem compromise paths.** Cloud API allows horizontal access to other devices; mobile app exposes device tokens in local storage; factory reset does not remove sensitive data. ### Methodology 01. **Scope and threat model**, Define the device, deployment environment, interfaces, data flows, companion services, user roles, cloud dependencies, and realistic attacker profiles. 02. **Hardware reconnaissance**, Inspect PCB, components, chips, flash storage, debug interfaces, test pads, radio modules, boot modes, external ports, and physical trust boundaries. 03. **Firmware acquisition and analysis**, Extract or obtain firmware, unpack images, inspect filesystems, review binaries, identify secrets, assess update packages, and map vulnerable components. 04. **Interface and protocol testing**, Assess local, wireless, serial, debug, cloud, mobile, and management interfaces for authentication, encryption, replay resistance, command validation, and access control. 05. **Exploit path validation**, Safely validate realistic attack paths, firmware modification, debug access, secure boot bypass, command injection, credential extraction, API abuse, privilege escalation, or device takeover, where authorised. 06. **Evidence, reporting, and remediation**, Document findings with test-case mapping, reproducible evidence, CVSS scoring, business impact, affected components, remediation guidance, and standards alignment through Velocity. ### Deliverables - Executive summary - Technical findings report - Firmware analysis summary - Hardware interface findings - Ecosystem (cloud / mobile) risk summary - Standards mapping and CRA readiness observations - Reproduction steps, screenshots, serial logs, packet captures - CVSS scoring and CWE mapping where appropriate - Prioritised remediation roadmap - Retesting on remediated findings - Optional JSON, XML, CSV exports for downstream tooling ### Frequently asked questions **Q: What is IoT Hardware Testing?** A: IoT Hardware Testing is a security assessment of connected devices and their supporting ecosystem, including hardware interfaces, firmware, wireless protocols, mobile applications, cloud APIs, device management platforms, and update mechanisms. **Q: Is this the same as application penetration testing?** A: No. Application testing focuses on software such as web, mobile, and APIs. IoT Hardware Testing includes physical device review, firmware analysis, debug interface testing, protocol testing, and hardware-based attack paths, while also assessing companion applications and cloud services where relevant. **Q: Does this provide CRA, Singapore CLS, or any other certification?** A: The service provides aligned security testing, evidence, findings, and remediation guidance that can support readiness for the CRA, the CSA Singapore Cybersecurity Labelling Scheme (CLS), and similar frameworks. **Q: How does this map to the Singapore Cybersecurity Labelling Scheme (CLS)?** A: The CLS is a voluntary CSA Singapore labelling scheme for consumer IoT, with four levels of progressively stronger requirements. Levels 1 and 2 are largely a self-declaration against ETSI EN 303 645, the testing baseline already covered by our methodology. Levels 3 and 4 require independent assessment, including penetration testing of the device. Our engagements can be scoped to produce evidence aligned with the CLS level you are targeting and to support a third-party laboratory submission where required. **Q: What devices can be tested?** A: Examples include consumer IoT devices, industrial IoT devices, smart sensors, gateways, routers, appliances, healthcare devices, access control devices, payment-adjacent devices, building automation devices, wearables, and custom embedded products. **Q: Do you need physical access to the device?** A: Yes, physical access is mandatory for hardware and firmware testing, and engagements typically require multiple device samples (often 3 or more) to allow concurrent disassembly, instrumentation, and side-by-side comparison. Devices must be shipped to one of our offices (Singapore, Indonesia, or Thailand) where they are tested in a controlled lab environment. **Q: What does firmware testing include?** A: Firmware testing may include extraction, unpacking, filesystem analysis, binary analysis, credential discovery, update mechanism testing, secure boot review, vulnerable component analysis, and configuration review. **Q: Can you test device cloud platforms and mobile apps?** A: Yes. IoT security often depends on mobile applications, cloud APIs, provisioning workflows, device identity, update services, and fleet management platforms. These can be included in scope. **Q: What standards can the assessment be mapped to?** A: Depending on product type, market, and deployment environment: EU Cyber Resilience Act and ETSI EN 303 645 for European market access; CSA Singapore Cybersecurity Labelling Scheme (CLS) for consumer IoT entering Singapore; Singapore Cybersecurity Act and CCoP requirements where devices are deployed into Critical Information Infrastructure; IEC/ISA 62443 for industrial and OT deployments; EN 18031 (EU's Radio Equipment Directive) for radio equipment cybersecurity; and OWASP IoT, OWASP FSTM, and NISTIR 8259. **Q: What do we receive at the end?** A: You receive an executive summary, technical report, evidence, reproduction steps, affected components, risk scoring, standards mapping, and remediation guidance. Where supported, findings can be exported in PDF, JSON, XML, or CSV. ### Call to action **Test your connected products before attackers do.**, Whether you are preparing for CRA readiness, targeting the CSA Singapore Cybersecurity Labelling Scheme, or testing hardware deployed into enterprise environments, Vantage Point Security Group can help identify practical exploit paths and prioritise remediation. --- ## Cloud Security URL: https://www.vpsec.io/en/services/cloud-security/ Eyebrow: Cloud Security > Cloud compliance assessments, configuration reviews, and platform-specific penetration testing across AWS, Azure, GCP, and AliCloud, anchored to the shared responsibility model and mapped to your regulatory environment. Cloud is now the default control plane for modern enterprises. It is also where the most damaging breaches of the last decade have started: a misconfigured storage bucket, an over-privileged role, a forgotten access key in a CI pipeline, a service exposed to the public internet by accident. Cloud security testing has to keep pace with how quickly the environment changes, and how easily a single configuration error can become a data exposure event. Vantage Point delivers cloud security through two complementary engagement types. Configuration and compliance assessments give you auditor-grade visibility into IAM, posture, segmentation, and governance. Platform-specific penetration testing then validates whether those controls hold up against an authenticated adversary moving through the environment. Engagements run on the Velocity platform, with cloud test cases mapped to CIS Benchmarks, sector regulators, and the security baselines published by each cloud provider. Every finding is reproduced, scored, and traced back to a specific control, built for audit defensibility, not just a list of risks. ### Why it matters, No endpoint agents. No SOC. Just your production estate exposed to the internet. - **Configuration drifts faster than governance.** Every infrastructure change is a potential security change. Without continuous testing, posture decays between audits, and a single broken IAM policy can undo months of hardening work. - **The shared responsibility model has sharp edges.** Cloud providers secure the platform; you remain accountable for identity, configuration, data, and workload security. Most cloud breaches sit squarely on the customer side of that line. - **The standards exist, and we benchmark to them.** CIS Benchmarks publish line-by-line hardening baselines for every major cloud provider, AWS, Azure, GCP, AliCloud. We review your environment against them, so you get a consistent industry-standard assessment that confirms you are using the security features your cloud provider already gives you, and that your configuration matches the consensus best practice that the industry has already agreed on. ### What we test Cloud engagements look across three concurrent layers, identity, configuration, and runtime, because that is where real-world cloud compromises chain together. **Identity & access** IAM is where most cloud compromises actually escalate. We map permissions, trust paths, and lateral movement opportunities the way an attacker would. - Least-privilege validation across roles, groups, and users - Cross-account and cross-tenant trust paths - Service-to-service identity boundaries - Dormant credentials, long-lived access keys, and key-rotation gaps - Privilege escalation paths via misconfigured policies **Configuration & posture** Auditor-level configuration review against CIS Benchmarks and provider baselines, then a sense-check from an offensive-security perspective. - Public storage exposure (S3, Blob, GCS, OSS) - Network segmentation, VPCs, security groups, NSGs - Encryption at rest and in transit, key management - Logging, monitoring, and alerting coverage - Secrets management and pipeline credential hygiene **Workloads & data** Where in-scope, we test the workloads and data flows that sit on top of the platform, because configuration alone never tells the full story. - Cloud-hosted application and API surfaces - Container, Kubernetes, and serverless workloads - Data protection across storage, databases, and warehouses - Backup and disaster-recovery posture - Cloud-native incident response readiness **Serverless Functions** We review AWS Lambda, Azure Function Apps, and GCP Cloud Functions against the CIS Benchmark controls for function-as-a-service, execution-role privilege, environment-variable encryption, authentication, networking, and audit logging, and surface which functions sit outside the baseline. - AWS Lambda, execution roles, KMS env vars, function URL auth, VPC, CloudWatch - Azure Function Apps, managed identity, HTTPS-only, VNet integration, storage hardening - GCP Cloud Functions, service-account scope, KMS env vars, VPC connector, audit logs - Cross-provider, public reachability, secrets, supply-chain, abuse paths ### What we typically find - **Over-privileged identities.** Production roles with wildcard permissions, human users with administrator policies attached "temporarily", service accounts with cross-account trust they no longer need. - **Public exposure of internal data.** Storage buckets with object-level public ACLs, internal services published through load balancers without an authentication layer, debug endpoints reachable from the internet. - **Pipeline & secret leakage.** Long-lived static keys in CI/CD variables, secrets committed to repositories, build agents with broader cloud permissions than the workloads they deploy. - **Network segmentation gaps.** Flat VPC topology, overly permissive security-group rules, peered networks that allow lateral movement, missing egress restrictions on workload subnets. - **Logging & detection blind spots.** Audit logging disabled on critical services, log retention shorter than incident-response requirements, alerts that exist but are not routed to anyone on-call. - **Recovery & resilience weaknesses.** Backups stored in the same account they protect, missing immutability, untested restore procedures, single-region dependencies for tier-1 workloads. ### Standards and frameworks Cloud test cases in Velocity are mapped against both technical baselines and the regulatory requirements that drive most engagements in the region. - CIS Benchmarks (AWS, Azure, GCP, AliCloud) - Vendor Security Guidance - NIST SP 800-53 / 800-204 - ISO 27001:2022 - PCI DSS v4.0 - GDPR (where applicable) ### Deliverables - Cryptographically signed final report - Per-finding test-case mapping and CVSS scoring - Reproduction steps, payloads, and screenshots - Configuration remediation with policy and code examples - Executive summary and risk heatmap - Standards / regulator coverage matrix - Stakeholder debrief and retest cycle ### Frequently asked questions **Q: How is a cloud penetration test different from a network penetration test?** A: A traditional network penetration test focuses on perimeter exposure and lateral movement across hosts. Cloud engagements add identity-driven attack paths, configuration drift, control-plane access, and provider-specific service abuse. We typically combine the two when a workload is partially on-prem and partially in cloud. **Q: Do you need full admin access to the cloud account?** A: No. We tailor access to the engagement, anything from black-box external testing, to read-only audit credentials for configuration review, to a scoped identity for authenticated attack-path testing. Rules of Engagement define exactly what is in scope and what is not. **Q: Can you test production safely?** A: Yes, with controls. Configuration and identity review is non-disruptive by design. Active attack-path testing in production runs under written Rules of Engagement, change windows, and pre-agreed abort criteria so that there is no operational impact. **Q: How does this map to PCI DSS or ISO 27001 audit requirements?** A: Every test case in Velocity is mapped to the standards it supports. Reports include a coverage matrix you can hand directly to auditors, with traceability from a finding back to the specific control it relates to. **Q: Do you handle multi-cloud environments?** A: Yes. Most regional enterprises now run multi-cloud, typically AWS plus Azure, with GCP for analytics or AliCloud for China workloads. Engagements can cover a single platform or stitch multiple platforms into one assessment with cross-platform attack-path mapping. **Q: Will the test trigger your cloud provider's abuse detection?** A: Cloud providers expect customer-initiated security testing. For invasive testing we file the appropriate provider notifications and operate within published terms of service. Your incident-response team is briefed in advance so any internal detections can be correlated to our activity. ### Call to action **Test the cloud the way it actually fails.**, Talk to a CREST-accredited consultant about scoping a cloud engagement, configuration, identity, and attack-path testing built around your regulatory environment. --- ## Cloud Compliance Assessments URL: https://www.vpsec.io/en/services/cloud-security/compliance-assessments/ Eyebrow: Cloud Security → Compliance Assessments > Auditor-level review of cloud posture against regulatory and industry standards, built around the shared responsibility model. Cloud compliance assessments produce the evidence regulators, auditors, and customers increasingly expect for cloud-hosted workloads. Where a generic cloud "health check" lists everything that scanners flag, our compliance assessments cross-reference findings against the specific standards your organisation is held accountable to, and produce a coverage matrix you can hand directly to your auditor. Engagements typically cover one tenant or account family per cloud platform, with the configuration of identity, services, networking, logging, encryption, and governance assessed against CIS Benchmarks and provider-specific guidance. Where regulators (CSA Singapore, OJK Indonesia, Bank of Thailand) publish cloud-specific expectations, findings are also mapped to those frameworks. These assessments are non-disruptive by design, read-only access is sufficient. They produce evidence for audit, but also create a working remediation roadmap that engineering can act on. ### Why it matters - **Auditors want cloud-specific evidence.** Generic ISO 27001 evidence is no longer enough for cloud-hosted workloads. Auditors increasingly ask for CIS or CCM-aligned cloud-specific posture evidence. - **Configuration is the new compliance baseline.** Most cloud breaches start with a configuration error. Compliance assessments make that surface visible, and produce the evidence trail to prove it has been managed. ### What we test **Areas of assessment** - IAM permissions and identity posture - Service configuration - Public storage and data exposure - Low-privileged access to sensitive resources - Misconfigurations against CIS Benchmarks - Logging, monitoring, and key management **Compliance mapping** - CIS Benchmarks (AWS, Azure, GCP, AliCloud) - CSA Cloud Controls Matrix - GDPR, HIPAA, PCI DSS, where applicable - Regional regulator requirements - Internal policy and control mapping ### Standards and frameworks - CIS Benchmarks - CSA CCM - ISO 27001:2022 - PCI DSS v4.0 - CSA Singapore - OJK Indonesia - Bank of Thailand ### Frequently asked questions **Q: How is this different from your AWS / Azure / GCP penetration test?** A: Compliance assessments are read-only, audit-focused, and benchmark-driven. Platform-specific penetration tests are active, they exercise attack paths. Most clients run a compliance assessment annually and a penetration test on top, periodically. **Q: What level of access do you need?** A: Read-only audit credentials are sufficient. We do not need write access, do not modify configuration, and do not impact running services. --- ## AWS, Azure & GCP Assessments URL: https://www.vpsec.io/en/services/cloud-security/aws-azure-gcp/ Eyebrow: Cloud Security → AWS, Azure & GCP > Platform-specific cloud security assessments across AWS, Azure, and GCP, combining configuration review with penetration testing where in scope. Each major cloud platform has its own attack model. AWS IAM, Azure AD / Entra, and GCP Workload Identity look superficially similar but behave very differently under attacker pressure. Platform-specific assessments combine deep configuration review with active attack-path testing using the techniques that platform-specialist consultants, not generic cloud testers, actually exercise. Engagements typically cover one tenant or account family per platform. We work from authenticated credentials provisioned for the engagement and exercise the realistic attack chains: IAM privilege escalation, cross-account trust abuse, service-account compromise, container and serverless escape paths, and exfiltration to attacker-controlled storage. Where you run multi-cloud, engagements can stitch platforms together, important because the most damaging recent cloud breaches have involved attackers moving across platforms. ### Why it matters - **Configuration testing alone misses attack paths.** A configuration review tells you what is misconfigured. An attack-path test tells you what an attacker can do with those misconfigurations, usually more than the standalone findings would suggest. - **Each platform fails differently.** AWS escalation typically runs through IAM trust paths; Azure through Entra and consent grants; GCP through workload identity and service-account impersonation. Platform-specific testing matters. ### What we test **Platform review** Deep configuration analysis aligned to CIS Benchmarks and provider-published security baselines. - IAM and identity - Service configuration - Network segmentation - Storage and database posture - Logging and monitoring - Key management and encryption **Attack-path testing** Active testing of the chains real attackers actually exercise, including cross-account, cross-tenant, and cross-region paths. - Privilege escalation - Lateral movement (where permitted) - Data exfiltration paths - Cross-account / cross-tenant exposure - Container and serverless escape - Pipeline / CI-CD trust abuse ### Standards and frameworks - CIS Benchmarks - AWS Well-Architected Security Pillar - Azure Security Benchmark - GCP CIS Benchmark - MITRE ATT&CK Cloud - PCI DSS - ISO 27001 ### Frequently asked questions **Q: Will you actually exploit findings in our production cloud?** A: Under written Rules of Engagement, with abort criteria, and with the white team briefed in advance, yes, where exploitation is the only way to validate the finding. Where the risk is acceptable from review alone, we do not. **Q: Do we need to file a notification with the cloud provider?** A: For most invasive testing, yes, we handle filings on your behalf where required. Each provider publishes its own customer security-testing policy; we operate within those terms. **Q: Can you test multi-cloud and hybrid environments?** A: Yes. Most regional enterprises now run multi-cloud, typically AWS plus Azure, with GCP for analytics. Multi-cloud engagements add cross-platform attack-path testing as a deliberate scope element. --- ## AliCloud Assessments URL: https://www.vpsec.io/en/services/cloud-security/alicloud/ Eyebrow: Cloud Security → AliCloud > AliCloud security assessments covering the same depth and rigour as our AWS, Azure, and GCP reviews, built for Alibaba Cloud deployments across the region. Alibaba Cloud is the dominant cloud platform across mainland China and an increasingly common deployment target for regional enterprises serving Chinese markets or operating in PRC jurisdiction. Its security model, RAM identity, RDS, OSS, VPC, has its own conventions that mainstream cloud testers rarely understand in depth. Our AliCloud engagements apply the same configuration-plus-attack-path methodology used for AWS, Azure, and GCP, adapted to AliCloud-specific services and to the regulatory environment AliCloud workloads typically operate within (CSL, PIPL, MLPS). ### Why it matters - **AliCloud has its own attack model.** Generic cloud testing methodologies miss AliCloud-specific service behaviour, RAM trust paths, and provider-specific defaults. Specialist coverage matters. - **PRC compliance has sharp edges.** Workloads running in mainland China are subject to CSL, PIPL, and MLPS requirements that shape testing methodology, including how data is handled during the engagement itself. ### Standards and frameworks - CIS Alibaba Cloud Benchmark - AliCloud Security Best Practices - CSL - PIPL - MLPS --- ## Infrastructure Security URL: https://www.vpsec.io/en/services/infrastructure-security/ Eyebrow: Infrastructure Security > Infrastructure-layer security across networks, servers, endpoints, and devices, including network vulnerability assessment and security configuration review benchmarked against CIS, vendor baselines, and your security policy. Most enterprises still run on infrastructure built over many years, a mix of on-prem, cloud-hosted, virtualised, and edge environments stitched together by network controls and a security configuration that has rarely been reviewed end-to-end. Infrastructure security focuses there: identifying exploitable weaknesses and posture drift before attackers do. Our infrastructure security service covers two complementary work types. Network vulnerability assessment provides broad, automated coverage with consultant triage, useful for ongoing posture monitoring and audit evidence. Security configuration review is deeper, comparing the actual configuration of devices, servers, and platforms against established hardening baselines. Both engagement types map findings to CIS Benchmarks, vendor guidance (Microsoft, Cisco, Red Hat, VMware), and the technical control sets in ISO 27001:2022, PCI DSS, and regional regulator frameworks. ### Why it matters - **Posture drift is invisible without testing.** Configurations change with every patch, role rotation, and emergency fix. Without periodic testing, hardening achieved 12 months ago may no longer reflect production reality. - **Vulnerability scanning alone misses context.** A scanner flags a CVE. Whether that CVE is exploitable in your environment depends on configuration, network position, and what else an attacker can reach from there. Consultant triage closes that gap. - **Auditors increasingly ask for benchmark-aligned evidence.** CIS-aligned configuration evidence is becoming the de-facto standard auditors and customers expect, particularly in regulated sectors. ### What we test **Network vulnerability assessment** Broad-coverage scanning of network-accessible assets, with consultant triage to separate signal from noise. - Network devices, servers, endpoints - External and internal coverage - Configuration errors and missing patches - Risk-prioritised vulnerability identification - Compliance-aligned reporting **CIS Benchmarks** Deep configuration analysis comparing live posture against established CIS hardening baselines. - Operating systems (Windows, Linux, macOS) - Network devices (firewalls, switches, routers) - Hypervisors and virtualisation platforms - Databases (SQL Server, Oracle, PostgreSQL, MySQL) - Endpoint and EDR configuration ### What we typically find - **Missing patches on exposed services.** Internet-facing services running versions with known RCE, internal services months behind on critical updates, legacy systems with no remediation path. - **Weak protocols still enabled.** SSLv3 / TLS 1.0 on external services, SMBv1 on internal segments, deprecated cipher suites accepted on management interfaces. - **Configuration drift from baseline.** Hardening reverted after troubleshooting, default credentials never rotated, audit settings disabled "temporarily", local admin accounts proliferating. - **Network segmentation gaps.** Flat networks with no segmentation between user and server subnets, overly broad firewall rules, missing egress controls. - **Logging and monitoring blind spots.** Critical infrastructure not forwarding to SIEM, log retention shorter than incident response requires, alerts firing without anyone subscribed. - **Forgotten exposures.** Decommissioned-but-still-running services, test environments reachable from production, legacy VPN endpoints with weak authentication. ### Standards and frameworks - CIS Benchmarks - NIST SP 800-53 - ISO 27001:2022 - PCI DSS v4.0 - Vendor hardening guides ### Deliverables - Cryptographically signed final report - Vulnerability findings with exploitability triage - Configuration deviations against benchmarks - CVSS-scored prioritised remediation - Executive summary and risk heatmap - Retest cycle on remediated findings ### Frequently asked questions **Q: How is this different from running our own vulnerability scanner?** A: Scanning is one input. The value of an engagement is in consultant triage: validating findings, filtering false positives, contextualising exploitability against your environment, and translating output into prioritised remediation a board can read. **Q: Will this affect production systems?** A: Vulnerability scanning is designed to be non-disruptive at normal intensity. We agree scanning windows and exclusion lists with you before the engagement, and avoid known-fragile assets unless they are explicitly in scope. **Q: How often should infrastructure be tested?** A: Most regulated organisations run an external scan quarterly, an internal scan and configuration review annually, and ad-hoc reviews after significant changes. Engagements can be configured as one-off or as a continuous programme. **Q: Can you cover both on-prem and cloud-hosted infrastructure?** A: Yes. Hybrid environments are the norm. Cloud-specific identity and configuration testing is handled under our Cloud Security service line, and the two are usually combined in a single engagement. --- ## Network Vulnerability Assessment URL: https://www.vpsec.io/en/services/infrastructure-security/network-vulnerability-assessment/ Eyebrow: Infrastructure Security → Network Vulnerability Assessment > Automated scanning of network devices, servers, and systems, vulnerability identification, risk analysis, and compliance verification, with consultant triage on top. Network vulnerability assessment is the breadth instrument for infrastructure security. It produces broad coverage across your estate using authenticated and unauthenticated scanning, then layers consultant triage on top to validate findings, contextualise exploitability, and prioritise remediation. Where penetration testing answers "can this be exploited and what is the impact?", a vulnerability assessment answers "where do we have known weaknesses, and which ones matter most?". Most regulated organisations run vulnerability assessments at higher frequency (monthly or quarterly) and penetration tests at lower frequency (annual or after change). ### Why it matters - **Scanning surfaces what scales.** Vulnerability assessment is how you keep a continuous view of known-CVE exposure across the estate. Penetration testing tells you about depth; vulnerability assessment tells you about breadth. - **Consultant triage is the difference.** Raw scanner output is noise. The value is in the triage: validating findings, separating exploitable from theoretical, and prioritising what should consume remediation time. ### What we test **Scan coverage** - Network devices - Servers and endpoints - Configuration errors - Missing patches - Software issues - Security protocol gaps **Output** - Vulnerability identification - Consultant triage and exploitability ranking - Risk analysis with CVSS scoring - Compliance check against CIS / PCI / ISO - Prioritised remediation recommendations ### Standards and frameworks - CIS Benchmarks - NIST SP 800-115 - PCI DSS v4.0 - ISO 27001:2022 ### Frequently asked questions **Q: How often should we scan?** A: PCI DSS requires quarterly external ASV scanning and on significant change. Most regulated organisations run external scans monthly and internal scans quarterly, with a deeper consultant-led assessment annually. **Q: Will scanning affect production?** A: At normal intensity, no. We agree scanning windows and exclusion lists in advance, and avoid known-fragile devices unless they are explicitly in scope. --- ## Security Configuration Review URL: https://www.vpsec.io/en/services/infrastructure-security/security-configuration-review/ Eyebrow: Infrastructure Security → Security Configuration Review > Hardening review of network devices, servers, and platforms, benchmarked against CIS, vendor baselines, and your security policy. Configuration review goes deeper than vulnerability scanning: it compares the actual running configuration of devices and platforms against established hardening baselines, item by item. Where scanners surface "you have a vulnerability", configuration review surfaces "this control should be on, and it is off". Reviews typically cover a mix of asset types, Windows and Linux servers, network devices, hypervisors, databases, endpoint security platforms, sampled across the estate. Findings map to CIS Benchmarks or to your internal hardening standard, with remediation guidance built around the platform's own configuration model. ### Why it matters - **Hardening decays without measurement.** Configuration drift is the slow erosion that happens between audits. Without periodic review, the hardened build from two years ago no longer reflects production reality. - **Auditors increasingly ask for CIS-aligned evidence.** CIS-Benchmark-aligned evidence is becoming the de-facto baseline auditors and customers expect, particularly in regulated sectors. ### Standards and frameworks - CIS Benchmarks - Vendor hardening guides (Microsoft, Cisco, Red Hat, VMware) - ISO 27001:2022 - PCI DSS v4.0 --- ## Regulatory Red Team Exercises URL: https://www.vpsec.io/en/services/red-team-operations/ Eyebrow: Regulatory Red Team Exercises > Realistic cyberattack simulation across technology, people, and process, validating detection, incident response, and resilience under controlled adversarial conditions. Penetration testing answers "are these assets vulnerable?". Red teaming answers a different and harder question: "if a capable adversary targeted us, would we see it, respond, and contain it before it became a business-impacting incident?". That question is what a regulator, an insurer, or a board ultimately wants answered. Vantage Point runs CREST-approved red team operations across the full attack lifecycle, reconnaissance, initial access, persistence, privilege escalation, lateral movement, and exfiltration or impact, under strict Rules of Engagement that protect operations while keeping the test realistic. Engagements align to MITRE ATT&CK so that activity, detections, and gaps can be mapped to a common framework defenders already use. Where required by a regulator or insurer, we structure engagements to meet all applicable compliance requirements. ### Why it matters - **You will not stop attacks you cannot detect.** Most organisations have a clear view of what controls they have deployed. Far fewer know how those controls behave under real adversary pressure, and which gaps an attacker would exploit. - **Compliance is moving past component testing.** Financial regulators globally, including in Singapore, Hong Kong, Australia, and the EU, are mandating threat-intelligence-led testing for systemically important institutions. The trend is one-way. - **Insurance and M&A diligence ask different questions now.** Cyber insurers and acquirers increasingly want evidence of operational defensive capability, not just policies. A red team report is what answers that question credibly. ### What we test **Full attack lifecycle** End-to-end testing across the MITRE ATT&CK matrix, built to mirror how real adversaries actually move through an environment. - Reconnaissance and OSINT - Initial access (phishing, supply chain, exposed services) - Persistence and command-and-control - Credential access and privilege escalation - Lateral movement across networks and identities - Exfiltration or simulated business impact **Scenario-based testing** Where time, scope, or risk tolerance preclude a full red team, we run scenario engagements starting from a defined assumed-breach position. - Compromised SSO / identity provider - Compromised cloud tenant or service account - Compromised endpoint (typical workstation) - Supply-chain compromise scenario - Insider threat (malicious or compromised user) **Phishing / Social Engineering** People remain the most reliable initial-access vector in the real world, and the one that traditional vulnerability scanning never tests. We run targeted, written-Rules-of-Engagement campaigns that measure how an organisation actually responds when a credible attacker reaches into employee inboxes, phone lines, and meeting links. Engagements range from broad awareness simulations to highly tailored operations against named individuals, designed to stress-test detection, response, training, and downstream technical controls in a realistic and safe way. - Mass and targeted phishing (general · spear · whaling) - MFA-bypass phishing, reverse-proxy and session-token capture (Evilginx-class) - Business email compromise (BEC) and executive impersonation - Vishing (voice / phone) and smishing (SMS) where in scope - Pretexting and tailored social engineering against named targets **Darkweb Leaks** Attackers do not usually guess passwords or session tokens, they buy them. Infostealer logs, criminal forums, paste sites, and Telegram leak channels are awash with corporate credentials, session cookies, and access tokens harvested from compromised personal devices, third-party breaches, and supply-chain incidents. Most organisations have no visibility into what is already exposed about them. Working with our intelligence partners, we surface those secrets and feed them into the engagement, so the red team operates with the same starting material a real attacker would, and you finally see what attackers have been seeing for months. - Employee credential leaks across corporate email, SSO, and third-party SaaS - Session cookies and authentication tokens from infostealer logs - API keys, OAuth tokens, and secrets in paste sites and code dumps - Mentions of your domain, brand, or executives in criminal forums - Compromised customer or partner data exposing internal context - Cross-referenced re-use of leaked passwords against current systems ### What we typically find - **Detection coverage gaps.** SIEM rules that flag noisy events but miss credential abuse, EDR catching commodity malware but blind to LOLBins (Living off the Land Binaries), no detection on cloud control-plane actions. - **Identity-driven lateral movement.** Domain user to domain admin in a handful of hops; service-account password reuse; cloud admin paths reachable from any compromised laptop. - **Phishing resilience weaknesses.** MFA bypass via consent phishing, session token theft via reverse proxies, BEC flows the technical team had not seen tested. - **Response process breakdowns.** Alerts firing but no on-call routing, escalation paths that depend on a single individual, incident-response runbooks last reviewed years ago. - **Forgotten attack surface.** Decommissioned-but-running services, exposed dev environments, legacy VPN gateways, abandoned cloud subscriptions still federated to identity. - **Exfiltration paths.** No DLP on encrypted egress channels, sanctioned SaaS used for staging, missing controls on personal cloud-storage uploads. ### Engagement model - **Scoping.** Define objectives, in-scope assets, Rules of Engagement, white-team contacts, abort criteria, and the threat profile the engagement should emulate. - **Intelligence.** Threat intelligence shapes who we emulate. We profile the adversaries most likely to target your industry and footprint, then test against their TTPs, not a generic playbook. - **Execution.** Controlled adversary emulation by CREST-accredited operators, low-and-slow against the agreed scope. Activity is logged and mapped to MITRE ATT&CK in real time so defender response can be measured precisely. - **Reporting.** Adversary narrative report with ATT&CK technique mapping, defender response gap analysis, cryptographically signed deliverable, executive summary, and a board-ready briefing. - **Regulatory Acceptance.** We make sure the report format, methodology, and evidence depth meet what your regulator or insurer expects, TIBER-EU, GL20 / AASE, MAS, central bank, so the deliverable is accepted, not just delivered. - **Debrief.** We walk your detection and response teams through the full engagement timeline, what we did, when we did it, where you saw us, and where you didn't. The output is a prioritised list of detection and process gaps to close, framed as actions your team can take rather than abstract findings. ### Standards and frameworks - MITRE ATT&CK - TIBER-EU - CBEST - GL20 / HKMA Compliance - AASE - MAS TRM Guidelines - BNM RMiT - CORIE ### Deliverables - Adversary narrative and timeline - Per-finding ATT&CK technique mapping - Detection / response gap analysis - Cryptographically signed final report - Executive summary and board-ready briefing - Defender debrief with prioritised detection and response gaps - Regulatory acceptance support for TIBER-EU, GL20 / AASE, MAS, and similar frameworks ### Frequently asked questions **Q: Who in our organisation needs to know about a red team engagement?** A: A small "white team", usually CISO, head of detection, and an executive sponsor, is briefed on the engagement to authorise activity and act as escalation point. The wider security operations team is left blind so detection capability can be measured honestly. **Q: What is the difference between red teaming and penetration testing?** A: Penetration testing measures vulnerability in a defined scope. Red teaming measures detection and response across people, process, and technology, usually with much broader scope, longer duration, and intentionally low-and-slow activity. **Q: Will you actually exfiltrate our data?** A: No. Where exfiltration is in scope we use synthetic data or simulate the action with a marker file. Rules of Engagement explicitly forbid removing real client data from the environment. **Q: How do you avoid operational disruption?** A: Rules of Engagement define abort criteria, exclusion lists, and "ceasefire" conditions in advance. Our consultants pull back from any activity that risks operational impact, and the white team can call a halt at any point. **Q: Can red teaming support TIBER-EU, FEER, GL20, or similar regulatory tests?** A: Yes. We structure engagements to align with threat-intelligence-led testing frameworks where required by regulator, insurer, or board mandate. Scoping confirms specific framework alignment before engagement. ### Call to action **Test the way real adversaries operate.**, Speak to a CREST-accredited red team lead about scoping a threat intelligence led red team or scenario-based engagement. --- ## Red Team Assessment URL: https://www.vpsec.io/en/services/red-team-operations/red-team-assessment/ Eyebrow: Red Team → Assessment > An adversary-perspective assessment designed to identify vulnerabilities across digital, physical, and human vectors and to validate detection and response. A red team assessment is the most realistic test of operational security an organisation can run. It is goal-oriented, end-to-end, and intentionally low-and-slow, designed to mirror how a capable adversary actually behaves rather than how penetration testers behave with a two-week deadline. Engagements start from a defined objective, usually access to a specific business-critical system or dataset, and exercise the full attack lifecycle to get there: reconnaissance, initial access, persistence, lateral movement, and impact. The blue team is typically not informed; the engagement is treated as a real attack until the post-engagement debrief. The deliverable is not a list of vulnerabilities. It is a narrative of what an adversary did, what was detected, what was missed, and what the response process actually looked like in practice, combined with a defender-side debrief workshop to convert findings into improvements. ### Why it matters - **Detection capability is the question that matters.** You know what controls you have deployed. A red team tells you what those controls actually catch, and what they miss when an adversary operates with intent. - **Boards and regulators increasingly ask about it.** Penetration testing is table stakes. Threat-intelligence-led red team operations are increasingly what differentiates a mature security programme from one that just hits compliance. ### What we test **Attack vectors** - Network and system breaches - Identity and credential attacks - Social engineering and phishing - Physical security testing (where in scope) - Insider threat simulation **Outcomes** - Evaluate incident response - Enhance security posture - Raise organisational awareness - Validate detection coverage - ATT&CK gap analysis ### Methodology 01. **Reconnaissance**, OSINT and target profiling. 02. **Planning & threat modelling**, Define scenarios and Rules of Engagement. 03. **Attack execution**, Controlled, ethical execution against the agreed scope. 04. **Reporting & debrief**, Findings, defender narrative, remediation roadmap. ### Standards and frameworks - MITRE ATT&CK - CREST STAR / RT - TIBER-EU principles - GL20 / AASE ### Frequently asked questions **Q: How is this different from a penetration test?** A: Penetration tests assess vulnerability in a defined scope. Red team assessments assess detection and response across the broader organisation, longer duration, deliberate stealth, goal-oriented rather than coverage-oriented. **Q: How do we get value if the blue team is not told?** A: The blue team is briefed afterwards in a structured debrief, we walk them through the timeline, what they detected, and what they missed. The value is in measuring detection honestly, a forewarned team performs differently to a normal day, and that performance gap is exactly what we are testing. --- ## Phishing Campaigns URL: https://www.vpsec.io/en/services/red-team-operations/phishing-campaigns/ Eyebrow: Red Team → Phishing Campaigns > Targeted phishing simulation, measure employee susceptibility, validate detection and response, and drive targeted training improvement. Phishing remains the single most common initial-access vector in real-world breaches. A phishing campaign measures how an organisation actually performs against it, not just the percentage of users that click, but what happens next when credentials, MFA codes, or session tokens are captured. Engagements range from awareness-style campaigns (broad, lower-sophistication, training-focused) to targeted red-team-aligned campaigns (MFA bypass, session-token capture, BEC-style impersonation, payload delivery for follow-on activity). Sophistication, scope, and visibility to the blue team are all defined upfront. Most clients pair an annual targeted campaign with regular awareness campaigns delivered by their own teams, measuring susceptibility over time while keeping the technical-side test honest. ### Why it matters - **Most breaches start with phishing.** Year over year, phishing remains the single most common initial-access vector, including for MFA-protected environments where attackers now routinely capture session tokens rather than passwords. - **Awareness training without testing is hope.** Training programmes feel productive. Without periodic measurement, there is no evidence they are changing behaviour. ### What we test **Campaign types** - General phishing - Spear phishing - Whaling - MFA bypass / session token theft - BEC-style impersonation - Vishing and smishing (where in scope) **Programme phases** - Pre-engagement planning - Campaign design and development - Execution and monitoring - Analysis and reporting - Post-engagement debriefing and training ### What we typically find - **MFA bypass success.** Session-token capture via reverse-proxy phishing kits succeeding against TOTP and push-based MFA flows. - **Process breakdowns post-click.** Reported phishes routed to a generic mailbox no one monitors; no automatic credential reset on reported exposure; help-desk re-issuing MFA tokens without verification. - **High-privilege susceptibility.** Senior or privileged users with higher click rates than the general population, a particularly dangerous distribution. ### Frequently asked questions **Q: Do you test MFA bypass?** A: Yes, increasingly the default. Modern adversaries bypass MFA routinely via reverse-proxy phishing kits. Testing against pre-2020 phishing models without MFA bypass is no longer realistic. **Q: How is the campaign approved internally?** A: Pre-engagement planning includes legal, HR, and communications stakeholders. Rules of Engagement define explicit lists of who is in/out of scope, what content is acceptable, and how disclosure happens after the campaign. --- ## Scenario-Based Testing URL: https://www.vpsec.io/en/services/red-team-operations/scenario-based-testing/ Eyebrow: Red Team → Scenario-Based Testing > Controlled scenario testing, starting from an assumed compromise, to validate detection, response, and recovery across realistic attack chains. Scenario-based engagements answer a more focused question than a full red team: "if a specific assumed-breach event happened, would we contain it before it became a business-impacting incident?". They are shorter, cheaper, and easier to schedule than a full red team, and often produce more actionable findings because the scope is narrower. Most clients run scenario-based engagements on a yearly cycle, rotating through realistic threat scenarios: compromised SSO, compromised cloud tenant, compromised endpoint, compromised supply chain. The goal is to keep detection and response capability honest against the threat patterns that genuinely matter, not just commodity malware. ### Why it matters - **Most breaches start with an existing foothold.** A phished workstation, a stolen partner credential, a compromised SaaS account, all are "assumed breach" starting points. Scenario testing measures detection from exactly where real attacks begin. - **Targeted scenarios produce sharper findings.** Full red team engagements produce broad narratives. Scenario engagements produce targeted operational fixes against specific threat patterns. ### What we test **Common scenarios** - Compromised SSO / identity provider - Compromised cloud tenant - Compromised endpoint (standard workstation) - Supply-chain scenario - Insider threat simulation **Outcomes** - Detection validation - Incident response evaluation - Containment and recovery testing - Tabletop and live execution variants - ATT&CK technique coverage assessment ### Standards and frameworks - MITRE ATT&CK - NIST IR --- ## Source Code Security URL: https://www.vpsec.io/en/services/source-code-security/ Eyebrow: Source Code Security > Static analysis (SAST) and software composition analysis (SCA), securing your code and its dependencies before they reach production. Source code is where security issues are cheapest to fix and most expensive to leave. A weakness caught at commit time costs minutes to remediate; the same weakness in production costs orders of magnitude more, and may already have been exploited by the time it surfaces in a penetration test. Vantage Point's source code security service combines static application security testing (SAST), analysing your own code, with software composition analysis (SCA), analysing the dependencies you pull in. Together they cover the full code-supply chain that ships to production. Engagements are usually delivered as part of a secure SDLC programme, but we also run them as standalone assessments for pre-release sign-off, M&A technical due diligence, and post-acquisition codebases inherited without security history. ### Why it matters, Fixing in code is cheaper than fixing in production. - **The supply chain is part of your codebase.** A typical modern application is 80–90% third-party code. SCA is the only practical way to keep that surface visible and actionable. - **Static analysis surfaces what runtime testing cannot.** SAST sees code paths that DAST never reaches, error handlers, batch jobs, scheduled tasks, internal admin functions. Combined they cover dramatically more attack surface. - **Compliance is moving towards SSDF / SLSA.** NIST SSDF and SLSA are reframing what evidence regulators and customers will expect about secure development. SAST and SCA results are core inputs to that evidence. ### What we test **SAST, static application security testing** Source-level analysis identifying weaknesses early in the SDLC, where they are cheapest to remediate. - Authentication and authorisation logic - Input validation and output encoding - Session management and crypto - Sensitive-data handling paths - Pipeline integration where applicable **SCA, software composition analysis** Surface known-vulnerable third-party components, license-compliance risk, and supply-chain exposure across direct and transitive dependencies. - Component inventory across the codebase - Known vulnerabilities with exploitability triage - License compliance and obligation analysis - Direct and transitive dependency mapping - Outdated or unmaintained components ### What we typically find - **Known-vulnerable dependencies.** High-severity CVEs in widely-used libraries the team did not know they were using transitively, typical of Log4Shell-style supply-chain exposure. - **Insecure cryptography.** Hardcoded keys, weak hashing for credentials, deprecated ciphers, ECB-mode encryption used on PII. - **Injection-prone code paths.** String-concatenated SQL queries, command execution with user-controlled input, deserialisation of untrusted data. - **Authorisation flaws in code.** Endpoints lacking role checks, business-logic paths that trust client-supplied identity, admin functions reachable without the expected guard. - **Secrets and credentials in source.** API keys checked into repositories, .env files in build artefacts, database credentials in configuration committed to public branches. - **License & legal exposure.** GPL/AGPL-licensed dependencies pulled into proprietary distribution, unclear-license code shipped to customers, missing attribution. ### Standards and frameworks - OWASP ASVS - OWASP Top 10 - NIST SSDF - SLSA - ISO 27001:2022 - PCI DSS v4.0 ### Deliverables - Cryptographically signed final report - Per-finding code location and reproduction - Severity, exploitability, and CVSS scoring - Developer-ready remediation guidance - Component inventory and license register - Pipeline integration recommendations - Retest on remediated findings ### Frequently asked questions **Q: Do you need access to our full source tree?** A: For SAST, yes, within agreed Rules of Engagement and confidentiality terms. We can work on cloned repositories provided to a temporary engagement environment, or in your environment under controlled access. **Q: Which languages and frameworks do you cover?** A: All commonly-used enterprise languages, Java, .NET, JavaScript/TypeScript, Python, Go, C/C++, Swift, Kotlin. Where you use less common stacks we confirm coverage during scoping. **Q: Will you flag every SAST tool finding, or triage first?** A: We triage first. Raw SAST output is noisy by nature. Findings are validated, contextualised against the application, and prioritised by exploitability before they hit the report, so engineering time goes to issues that actually matter. ### Call to action **Catch flaws where they are cheapest to fix.**, Speak to a consultant about scoping SAST, SCA, or a combined source code security programme. --- ## SAST, Static Application Security Testing URL: https://www.vpsec.io/en/services/source-code-security/sast/ Eyebrow: Source Code Security → SAST > Static analysis of source code, surfacing vulnerabilities early in the SDLC, before they reach production. SAST analyses source code rather than the running application. That gives it visibility into code paths runtime testing cannot reach, error handlers, batch jobs, scheduled tasks, internal admin functions, and lets it surface findings before they ever ship. As with DAST, the value of SAST is what surrounds the tool. Raw scanner output is noisy by nature and most teams that have tried "just run SAST" abandon it within a release cycle. Our SAST engagements layer consultant triage, contextualisation against the application, and exploitability prioritisation on top, so the output is something engineering can act on. SAST works best as part of a secure-SDLC programme: gated in CI/CD, with deeper periodic reviews driven by consultants. ### Why it matters - **Static analysis finds what dynamic cannot.** Code paths never reached during DAST scans still exist in the binary and can be invoked by an attacker. SAST is the only practical way to see them. - **Cost-to-fix scales sharply with time.** A finding caught at commit time costs minutes. The same finding caught in production may already have been exploited and requires incident response. ### What we test **Vulnerability detection** - Authentication and authorisation logic - Input validation and output encoding - Configuration and secrets handling - Session management - Cryptography and key handling **Programme support** - Secure SDLC integration - CI/CD pipeline policy gating - Compliance verification (PCI DSS, ISO 27001) - Developer-friendly remediation reporting - Tool tuning to your stack and false-positive reduction ### Standards and frameworks - OWASP ASVS - OWASP Top 10 - NIST SSDF - ISO 27001:2022 ### Frequently asked questions **Q: Will SAST find authorisation flaws?** A: Partially. SAST can catch missing role checks and obvious data-flow patterns, but logic-driven authorisation flaws (multi-step, role-confused, business-logic) still require manual testing. **Q: Which SAST tooling do you use?** A: Engagement-dependent, selected to match the language ecosystem and integration model. We are tool-agnostic; what matters is the triage and methodology, not the brand of scanner. --- ## SCA, Software Composition Analysis URL: https://www.vpsec.io/en/services/source-code-security/sca/ Eyebrow: Source Code Security → SCA > Identify and manage the risk in your open-source and third-party dependencies, known vulnerabilities, license compliance, transitive risk. A typical modern application is 80–90% third-party code. SCA is the only practical way to keep that surface visible. It produces a component inventory, maps known vulnerabilities to those components, and triages which ones are actually exploitable in your specific application, the difference between a 4,000-finding scanner output and a prioritised remediation list engineering can deliver against. Beyond vulnerability tracking, SCA carries license-compliance value. Many open-source licenses carry legal obligations (attribution, source disclosure, downstream restrictions) that get lost when components are pulled in by transitive dependency. SCA surfaces those obligations before they become legal risk. SCA is typically the easiest source-code service to integrate continuously, it runs against build manifests rather than the codebase, and modern tooling fits into most CI/CD pipelines with minimal friction. ### Why it matters - **Supply-chain risk is now everyone's problem.** Log4Shell, XZ Utils, polyfill.io, recent years have made it clear that a single open-source component can become an organisation-wide incident overnight. SCA is the inventory you need to even know whether you are affected. - **License compliance has teeth.** GPL/AGPL obligations have been litigated. License-incompatible distribution can carry material commercial and legal cost, and is usually invisible to engineering until SCA is run. ### What we test **Component analysis** - Known vulnerability detection (CVE, GHSA) - Component scanning across direct and transitive dependencies - Dependency mapping and supply-chain visualisation - Container and base-image inventory **Compliance & monitoring** - License compliance and obligation analysis - Security risk assessment and exploitability triage - Mitigation and remediation guidance - Continuous monitoring via CI/CD ### Standards and frameworks - SLSA - NIST SSDF - ISO 27001:2022 - PCI DSS v4.0 - SBOM (CycloneDX / SPDX) ### Frequently asked questions **Q: Can SCA produce an SBOM?** A: Yes, Software Bill of Materials in CycloneDX or SPDX format. Increasingly required by enterprise customers and regulators as a deliverable for software supply-chain assurance. **Q: Do you check container images?** A: Yes. Container engagements typically combine SCA on the application dependencies with container-image SBOM and base-image vulnerability analysis. **Q: How do you handle false positives?** A: Raw SCA output flags every known CVE in every component, regardless of whether the vulnerable code path is actually reached. Consultant triage filters these down to exploitable findings, the only ones that should consume engineering time. --- ## LLM Testing URL: https://www.vpsec.io/en/services/llm-testing/ Eyebrow: LLM Testing > Security testing for LLM-powered applications, AI agents, and copilot integrations, mapped to the OWASP LLM Top 10. AI is no longer experimental, it is shipping in production at scale across customer support, internal copilots, agentic workflows, code generation, and decision-support tools. Every one of those deployments now sits in the attack surface. LLM-powered applications carry entirely new categories of risk that mainstream application security testing has never had to address: prompt injection, agent abuse, retrieval-augmented attack paths, data exfiltration through model output, and supply-chain compromise via untrusted model weights or training data. The risk is structural, not incidental. An LLM accepts instructions from anyone whose text reaches the prompt, including attacker-controlled emails, documents, web pages, and tool outputs. Indirect prompt injection turns any of those inputs into a potential command channel. Where the LLM is wired into agents or tool-calling APIs, a successful injection is no longer just a data leak, it becomes operational compromise: sending email as the user, querying internal systems, modifying records, executing code. Vantage Point's LLM Testing service covers the model itself, the surrounding application, the retrieval pipeline (RAG), and any agent or tool-calling layer. Coverage maps to the OWASP LLM Top 10, plus our own evolving test cases developed through internal R&D and CTF practice against AI systems. ### Why it matters, AI changes what an attacker can do, not just how. - **Prompt injection is now production-real.** Indirect prompt injection via retrieved documents, emails, web pages, or pasted snippets is the default attack vector against LLM applications. Treating it as theoretical is no longer defensible. - **Agents turn injection into impact.** A chatbot that gets jailbroken leaks data. An agent that gets injected sends email, queries databases, deletes records, or executes code on the user's behalf. The same flaw class produces dramatically different outcomes. - **AI inherits the data it was built on.** Training data poisoning, leaked secrets baked into prompts, fine-tuning sets containing PII, and model weights pulled from untrusted registries all create persistent risk that traditional application testing never looked for. - **Hallucination is a security control failure.** When an LLM confidently produces wrong output that drives business decisions, executes tool calls, or generates code that ships to production, the gap between "AI demo" and "AI system" becomes a security problem. - **The supply chain just got longer.** Foundation models, plugins, vector stores, embedding services, third-party agents, each is a new dependency with its own update channel, its own trust boundary, and its own potential for compromise. - **Regulators are catching up, fast.** MAS Singapore AI risk guidance, CSA Singapore expectations, the EU AI Act, and emerging NIST AI guidance all set out testing and evidence requirements. Evidence-led security testing today gets ahead of where regulation is clearly moving. ### What we test Coverage maps to the full OWASP LLM Top 10 (2025). Test scope is tailored to whether the system is a chatbot, a RAG-powered assistant, an agent with tool access, a code assistant, or a multi-agent workflow. **OWASP LLM Top 10 coverage** The complete OWASP Top 10 for LLM Applications, the published baseline for LLM application security testing. - LLM01, Prompt Injection (direct and indirect) - LLM02, Sensitive Information Disclosure - LLM03, Supply Chain (models, plugins, datasets) - LLM04, Data and Model Poisoning - LLM05, Improper Output Handling - LLM06, Excessive Agency - LLM07, System Prompt Leakage - LLM08, Vector and Embedding Weaknesses - LLM09, Misinformation and Hallucination - LLM10, Unbounded Consumption **Application & agent layer** How the model is wrapped, called, and given access to the rest of the system. Almost always where the highest-impact findings live. - Application-layer wrappers and middleware - Tool / function-calling abuse - Agent autonomy and least-privilege boundaries - Plugin and connector security - Multi-agent / agent-to-agent attacks - Output handling and downstream injection **RAG, data & supply chain** The data the model reads, the embeddings it searches, and the dependencies it ships with. - Retrieval-augmented generation (RAG) attack paths - Indirect prompt injection via retrieved content - Embedding store poisoning - Training / fine-tuning data exposure - Foundation-model supply chain - Plugin and tool registry trust ### What we typically find - **Indirect prompt injection.** Hidden instructions in retrieved documents, support tickets, emails, or web pages causing the LLM to ignore its system prompt, exfiltrate data, or call tools the user never requested. - **Agent tool abuse.** Agents with broader tool access than required, granting "send email" or "query database" to flows that should only read, allowing an injection to take destructive actions. - **System prompt and secret leakage.** System prompts containing API keys, internal URLs, or business logic recoverable through targeted queries or output-format manipulation. - **Output handling failures.** LLM output rendered as HTML without sanitisation enabling XSS; output passed to eval/exec; SQL generated from natural language without parameterisation. - **Excessive data exposure.** Vector stores returning chunks across tenant boundaries; document retrievers exposing internal PII because chunking ignored access control. - **Unbounded consumption.** No rate limit on expensive completions; no token budget per session; cost-amplification via crafted prompts that produce runaway agent loops. ### Standards and frameworks LLM Testing engagements map to the recognised AI security frameworks plus the underlying application security baselines that still apply when an AI system ships in production. - OWASP Top 10 for LLM Applications (2025) - EU AI Act - ISO/IEC 23894, AI risk management - ISO/IEC 42001, AI management system - OWASP Application Security Verification Standard (ASVS) ### Deliverables - Executive summary - Technical findings report with OWASP LLM Top 10 mapping - Reproducible prompts, payloads, and responses - Agent action traces where in scope - CVSS scoring and impact analysis - Prioritised remediation recommendations - Retesting on remediated findings - Optional JSON / XML / CSV export for downstream tooling ### Frequently asked questions **Q: Do you only test the model, or the whole application?** A: The whole application. Testing the model in isolation misses where most production risk actually lives, the application wrapper, retrieval pipeline, tool-calling layer, and downstream consumers of model output. Where you only need a focused model-only assessment we can scope that, but most engagements cover the full stack. **Q: Can you test agentic systems and multi-agent workflows?** A: Yes. Agent testing is a core part of the service, covering tool-calling abuse, autonomy-boundary violations, multi-agent coercion, and chained-injection scenarios where the model takes action on behalf of an attacker-controlled input. **Q: What about RAG and vector store security?** A: RAG-specific testing is included where applicable: indirect prompt injection via retrieved content, cross-tenant chunk leakage, embedding poisoning, and chunking strategies that bypass access controls. **Q: Do you test code assistants and copilots?** A: Yes. Code assistants raise specific risks, generated code containing CVEs, prompt injection via untrusted code or comments, secret leakage from training data, supply-chain exposure through suggested dependencies. **Q: How do you test models we don't control (e.g. OpenAI, Anthropic, Google)?** A: The model provider is in scope as a dependency, not a target. We assess how your application uses that provider, prompt construction, output handling, tool integration, data flow, rather than attempting to test the foundation model itself, which would breach provider terms of service. ### Call to action **Test your AI the way attackers will.**, Whether you are launching a customer-facing LLM, an internal copilot, or a multi-agent workflow, Vantage Point can identify the OWASP LLM Top 10 categories that actually apply to your system and provide consultant-validated, audit-ready evidence. --- ## Other Security Reviews URL: https://www.vpsec.io/en/services/other-security-reviews/ Eyebrow: Other Security Reviews > Specialist testing outside traditional web, mobile, and network, for the technology that defines the next decade of attack surface. Web, mobile, and network testing covers most of today's attack surface. But organisations across the region are increasingly running technology that mainstream penetration testing barely touches: ATMs and payment terminals, IoT and connected devices, biometric authentication, blockchain protocols, LLM-powered applications, and configuration-heavy enterprise COTS platforms. Each of these technologies has its own attack model, its own evidence requirements, and its own way of failing. Generic methodologies do not catch what really matters. Vantage Point invests directly in the research, tooling, and hands-on capability required to test these systems credibly, and Velocity carries that work into engagements as mapped, repeatable test cases. ### Why it matters - **These systems carry asymmetric impact.** When an ATM, payment terminal, biometric system, or production LLM fails, the consequence is often customer-facing and immediate, not just a backend incident. - **Methodologies are still maturing.** Industry guidance for AI/LLM, IoT, and blockchain is genuinely new. Testing depth varies wildly between providers. Choosing a tester with hands-on research in the space matters more here than in commodity engagements. - **Regulators are catching up, fast.** The EU CRA, MAS/CSA Singapore AI guidance, and central bank requirements for ATM and payment-terminal security are all tightening. Evidence-led testing today avoids retrofit cost tomorrow. ### What we test **Physical & embedded** Hands-on testing of devices that touch customers and money directly. Combined hardware, firmware, and network coverage. - ATMs and Cash Deposit Machines - Payment terminals (POS, mPOS, unattended) - IoT and connected devices (EU CRA-aligned) - Kiosks and self-service terminals - Industrial / OT devices where in scope **Emerging & high-risk** Specialist coverage where mainstream pentesting has limited capability, anchored by internal R&D and CTF practice. - Biometrics, fingerprint, face, behavioural; liveness detection - Blockchain, smart contracts, wallets, protocol layer - LLM / AI, prompt injection, model evasion, agent abuse - COTS platforms, Salesforce, SAP, Microsoft Dynamics ### What we typically find - **Hardware tampering and skimming exposure.** ATM enclosures defeatable by commodity tools, exposed debug ports on payment terminals, skim-friendly card-reader designs. - **IoT firmware weaknesses.** Hardcoded credentials in firmware, unsigned firmware updates, debug services exposed on production builds, weak crypto on device-to-cloud channels. - **Biometric bypass surfaces.** Liveness detection defeatable by 2D / video replay, fallback flows reverting to weaker authentication, template-storage weaknesses. - **Smart contract logic flaws.** Re-entrancy, access-control errors in admin functions, oracle manipulation paths, upgradeable-proxy mistakes. - **LLM application risk.** Indirect prompt injection via retrieved documents, agent tool-calling abuse, model-output data exfiltration, jailbreaks reaching back-end functions. - **COTS misconfiguration.** Salesforce sharing rules exposing PII, SAP authorisation objects granting excessive paths, Dynamics security roles ignored in custom flows. ### Standards and frameworks - EU Cyber Resilience Act - PCI PIN / PTS / P2PE - OWASP LLM Top 10 - Vendor baselines (Salesforce, SAP, Dynamics) ### Call to action **Test the systems mainstream pentesting overlooks.**, Talk to a consultant about scoping specialist testing for ATMs, IoT, biometrics, blockchain, LLM applications, or enterprise COTS platforms. --- ## ATM Penetration Testing URL: https://www.vpsec.io/en/services/other-security-reviews/atm-penetration-testing/ Eyebrow: Other Compliance → ATM > Full-stack ATM penetration testing, hardware, software, firmware, network communication, and physical security. ATMs and Cash Deposit Machines are unusual in cybersecurity: a fielded device that handles cash, accepts cards, runs decade-old operating systems in many cases, and sits in physically exposed locations. The threat model spans physical tampering, software compromise, network intrusion, and the operational processes around cassette handling and key management. Engagements typically run on a representative test ATM at our lab or in a controlled bank environment. Coverage spans hardware-level testing (card reader, PIN pad, cash dispenser), software and firmware analysis, network and transaction-layer testing, and operational process review. Findings map to the relevant regional banking regulator requirements and to PCI PIN / PTS expectations. ### Why it matters - **ATMs run unusually long-lived software.** A typical ATM in production may be running an OS family no longer in mainstream support. Patch cycles are constrained by vendor release schedules and operational windows. - **Regional regulators look at this specifically.** Bank of Thailand, MAS, and OJK all publish expectations on ATM security testing for banks operating the channel. Vendor-supplied attestation is rarely sufficient. ### What we test **Hardware & physical** - Card readers - Cash dispensers - PIN pads - Physical security and enclosure - Environmental and operational security **Software & network** - ATM software and firmware - Transaction processing systems - Network communication - Skimming, tampering, and malware attacks - Network intrusion ### What we typically find - **Enclosure and tamper resistance.** Skim-friendly card-reader bezel designs, defeatable enclosure locks, exposed maintenance interfaces. - **Software stack weaknesses.** ATM application bypassable via kiosk-mode escape, unpatched OS components, insecure update channel. - **Network and transaction.** Weak protection on host-to-ATM communication, replay-tolerant transaction messages, lateral movement from network into ATM estate. ### Standards and frameworks - PCI PIN - PCI PTS - Vendor security guidance (NCR, Diebold, Wincor) - Regional regulator expectations --- ## Payment Terminal Security URL: https://www.vpsec.io/en/services/other-security-reviews/payment-terminal-security/ Eyebrow: Other Compliance → Payment Terminal > Payment terminal and POS security testing, covering firmware, communications, tamper resistance, and end-to-end transaction integrity. Payment terminals, countertop POS, mobile POS, and unattended terminals, sit on a critical security boundary: the device handles cardholder data, payment credentials, and PIN entry in environments where physical access is uncontrolled. Their security model is governed by PCI PTS for hardware and by tight operational and cryptographic requirements for everything above it. Engagements typically cover firmware analysis, hardware tamper resistance, secure-element and cryptographic-key handling, communications (Bluetooth, Wi-Fi, cellular), and the payment flow end-to-end through to the acquirer. Output supports vendor security review, acquirer onboarding, and PCI compliance evidence. ### Why it matters - **Payment terminals carry asymmetric impact.** A compromised terminal can skim cards, capture PINs, or alter transactions, with consequences for cardholders, merchants, and acquirers simultaneously. ### Standards and frameworks - PCI PTS - PCI PIN - PCI P2PE - EMV - Visa / Mastercard rules --- ## Biometrics Security URL: https://www.vpsec.io/en/services/other-security-reviews/biometrics-security/ Eyebrow: Other Compliance → Biometrics > Security testing for biometric authentication systems, fingerprint, face, and behavioural, including liveness detection evaluation. Biometric authentication is increasingly a primary control for financial, government, and identity workflows. Its security depends on three things being right at once: the sensor, the matching engine, and, most often the weak point, the liveness or presentation-attack detection layer. We test all three. Engagements cover passive and active liveness detection, presentation attack detection (PAD) including 2D, video, mask, and morph attacks, the surrounding application flows (enrolment, recovery, step-up), and the fallback paths that frequently revert to weaker authentication when biometrics fail. ### Why it matters - **Liveness is where most attacks succeed.** Modern face-matching is strong. Liveness detection, the layer that decides whether a real human is present, is where presentation attacks frequently succeed in real testing. - **Fallback flows undermine the strong path.** When biometrics fail, applications typically revert to weaker authentication. Attackers target the fallback rather than the strong path. ### Standards and frameworks - ISO/IEC 30107 Presentation Attack Detection - NIST FRVT - FIDO Biometric Component Certification - Sector regulator guidance --- ## Blockchain Security URL: https://www.vpsec.io/en/services/other-security-reviews/blockchain-security/ Eyebrow: Other Compliance → Blockchain > Blockchain security testing, smart contracts, wallets, and non-custodial protocol-layer review. Blockchain security splits into very different sub-disciplines depending on what you are building. A DeFi protocol, a custody platform, a wallet, and an NFT marketplace each have distinct threat models and review methodologies. Engagements are scoped accordingly, there is no single "blockchain audit". We cover smart contract review on EVM-compatible chains, custodial-system security (key management, withdrawal flows, MPC architectures), wallet security (mobile, browser, hardware integrations), and protocol-layer review for non-custodial systems including bridges and oracles. Findings are mapped to recognised checklists (SCSVS, SWC) and to the engagement-specific threat model. ### Why it matters - **Smart contract bugs are irreversible.** Once deployed, exploited smart contracts cannot be patched in place. Pre-deployment review is the only meaningful defence for material contract value. ### Standards and frameworks - SCSVS - SWC Registry - Custody and exchange-specific frameworks --- ## COTS Enterprise Platforms URL: https://www.vpsec.io/en/services/other-security-reviews/cots-enterprise-platforms/ Eyebrow: Other Compliance → COTS Platforms > Security review of commercial off-the-shelf enterprise platforms, Salesforce, SAP, Microsoft Dynamics, including configuration, customisation, and integration risk. Enterprise COTS platforms, Salesforce, SAP, Microsoft Dynamics, concentrate vast amounts of organisational data and process. Their security depends almost entirely on how they are configured, what custom code has been layered on top, and how they integrate with the rest of the environment. Penetration testing against the vendor product itself is rarely the right question; testing your specific configuration is. Our COTS engagements review platform-specific security primitives, Salesforce sharing rules and profiles, SAP authorisation objects and S_RFC, Dynamics security roles and field-level security, alongside the custom Apex / ABAP / plugin code that often quietly bypasses them. Findings map to vendor security baselines, ISO 27001:2022 access-control requirements, and any regulator requirements for the data the platform holds. ### Why it matters - **COTS platforms concentrate data.** A misconfigured Salesforce org, SAP system, or Dynamics tenant can expose more data than most application-layer breaches, and the controls that protect them are usually invisible to traditional penetration testing. - **Custom code routinely bypasses platform controls.** Apex without "with sharing", ABAP without authorisation checks, plugins running with elevated security, every COTS platform has its own version of "the customisation that defeated the security model". ### Standards and frameworks - Salesforce Security Baseline - SAP Cyber Security guidance - Microsoft Dynamics security best practices - ISO 27001:2022 - PCI DSS (where applicable) ---