Penetration Testing Services
Virtual Nomad runs penetration tests on web and mobile applications, APIs, cloud environments and internal networks. Each test is performed manually by a security engineer, with automated tooling used where it genuinely helps. We look for the vulnerabilities an attacker could actually exploit, confirm what access they would provide, and document what your team needs to fix them.
Virtual Nomad runs penetration tests on web and mobile applications, APIs, cloud environments and internal networks. Each test is performed manually by a security engineer, with automated tooling used where it genuinely helps. We look for the vulnerabilities an attacker could actually exploit, confirm what access they would provide, and document what your team needs to fix them.
Much of what is sold as penetration testing is an automated scan with a report attached to it. Our engagements work differently. A person reviews every finding, removes the false positives, and confirms that each issue can be exploited before it goes in the report. Severity is explained in terms of your systems and data, not left as a generic label.
Manual testing
Automated scanners are good at matching known signatures. Many of the problems that lead to a real breach are not visible to them: broken access control, business-logic errors, chains of smaller issues, and permissions that were set up incorrectly. We test for these by hand and include a working proof of concept with every high-severity finding.
What we cover
An engagement can include your web and mobile applications, REST and GraphQL APIs, cloud accounts on AWS, Azure or GCP, external and internal networks, and the CI/CD pipeline behind them. We begin by mapping what is actually reachable from the outside, which regularly turns up forgotten subdomains, old staging servers and services that were never meant to be public.
How we work
Testing follows the OWASP Testing Guide, PTES and NIST SP 800-115. The scope and depth are agreed before we start, the coverage is recorded, and the results can be compared from one assessment to the next. You always know what was tested and how.
The report
Each finding is scored with CVSS and placed in the context of your environment. You get the steps to reproduce it, evidence of the impact, and a specific fix. The report is written for the developers who will act on it, with a short summary for management.
Retesting
Once your team has worked through the findings, we test the affected areas again and confirm the fixes hold. This retest is part of the engagement and is not charged separately.
Who runs the test
The work is done by senior engineers who find and responsibly report real vulnerabilities, not by a rotating junior team. Every engagement is covered by an NDA and runs against a scope you approve in writing before any testing starts.
run a test
A test is most useful at a few specific moments: before you put something new in front of users, after a release that changed how login, payments or permissions work, when a customer or auditor asks you to prove the application was checked, or after an incident that left you unsure what else might be exposed. Because a test reflects the system as it was on the day we looked at it, most teams run one on a regular schedule rather than treating it as a one-off.
need from you
To start we need three things: a clear scope of what is in and out of bounds, test accounts at each privilege level that matters, and someone on your side who can answer questions while the work is underway. We agree the dates up front, keep the more disruptive checks off production unless you specifically want them there, and tell you straight away if we find something serious rather than making you wait for the final report.

