Method
How we test
The whole method, in public, so you can judge it before you buy it and audit it afterwards.
This is a Ghost Protocol penetration test as the engagement actually runs: what we agree before anything is touched, what the machine does, what the person does, what a finding has to prove before it is allowed into the report, and where the boundary of the work sits. It describes the fixed-price web and API engagement and nothing else. The format of the document it produces is on the sample report page.
Version 1.0 · last reviewed 29 August 2026 · written by Ryan Sebastian, who runs the engagements and signs the attestation
One engineer, one engine, a fixed boundary
The engagement is one engineer and one engine against a fixed scope. The engine is PhantomDragon, the scanner fleet we build and run ourselves: 50 modules across a 17-phase pipeline, 75 or more scanners, roughly 62,000 lines of Python. The engineer is Ryan Sebastian, who scopes the work, drives the manual phase, writes the report and signs the attestation letter. About four engineer-days go into an engagement. The machine buys the breadth those days would otherwise be spent enumerating.
The boundary is the external application layer. One web app plus its API, up to three hostnames and two user roles, one price, held. Authenticated authorization testing (BOLA and BFLA) is performed by the engineer. Testing is grey box: you issue credentials for both roles, because access control is where the findings are and a black-box tester spends half the window getting to the authenticated surface. Inside that boundary the work is thorough. Outside it we do nothing at all: no internal network, no segmentation testing, no social engineering, no denial of service, no physical access, no mobile client. That list is not a disclaimer at the end of a proposal. It is the shape of the product, and it is the reason the price is a single number.
Two things we do not claim. The engine does not discover zero-days, and it is not autonomous: everything it produces is a lead, and a lead becomes a finding only when a person reproduces it. And a clean report is evidence of what was tested in a defined window, not a certificate that an application is secure. The attestation letter states the scope and the dates for exactly that reason.
What follows is the method in the order the engagement runs it. It is published so that a CTO can judge the work before buying it, an auditor can see what the report is and is not evidence of, and a competitor can hold us to it.
What we agree before anything is touched
Nothing is touched without written authorisation from the owner of the asset. The engagement letter fixes the scope, the window, the contacts and the escalation path, and the attestation later covers exactly what that document named. No more, and no less.
Explicitly out of scope
Several of these are available as separate work, quoted separately. None of them is quietly absorbed into a fixed price, because a scope that stretches is a scope that stops meaning anything on the attestation.
Reconnaissance and mapping
Before any payload, a map. The point of this phase is that nothing inside the scope is tested by accident, and nothing is missed because it was not on the sitemap.
Hostname and certificate inventory
The hostnames in scope, plus what DNS and certificate transparency say about them: names that still resolve, records pointing at hosts that no longer answer, staging names nobody took down. Anything outside the scope statement is reported as an observation and not tested.
Technology fingerprint
Server, framework, application platform, CDN and WAF, client-side libraries and their versions. This decides which scanners and which payload families are worth running at all. A Rails injection set fired at a Django application is noise, and noise costs a day of the report.
Route and parameter inventory
Every route the application serves to each role, crawled authenticated and unauthenticated, plus the routes it does not advertise: sitemaps, JavaScript bundles, source maps where they ship, historical paths, and directory discovery aimed by the fingerprint rather than by a generic wordlist.
The API shape
Endpoints, methods, parameters, and the object identifiers they take. Where an OpenAPI document or GraphQL introspection is available we use it and then check it against reality, because the endpoints missing from the documentation are usually the ones worth the most.
The role matrix
What each of the two roles is supposed to reach, written down as a matrix before anything is tested against it. This is the artefact the access-control phase works from. Without it, IDOR testing is guesswork with a good vocabulary.
The state map
The flows that change state: signup, login and reset, purchase and refund, invitation and role change, export and delete. Business-logic abuse happens inside these flows, so they are drawn before they are attacked.
The automated sweep
PhantomDragon runs its seventeen phases under manual oversight, in the order below. The sweep averages three to six hours. It is the cheapest part of the engagement and the least interesting part of the report.
Why a fleet rather than a scanner. In our own testing, any two scanners agree on a given issue only 30 to 40 percent of the time, so most of what each tool reports is unique to that tool. One scanner is a sample. The fleet is coverage, and coverage is the part of the work a machine is genuinely better at. We published the run we did against our own application, including what it found.
Earlier phases decide later ones. The fingerprint chooses which payload families are worth firing; content discovery is aimed by what the fingerprint found. The final phase correlates across all of them and applies seven validation strategies before a person sees anything: deterministic replay, differential analysis, timing correlation, pattern confidence, semantic context, technology-stack veto, and model reasoning. The engine is documented separately.
That is a triage layer, not a verdict. Nothing ships on scanner output alone. Everything the sweep produces is a lead, every lead is reproduced by hand or dropped, and the report prints which of the two happened for every finding in it.
The manual phase
This is what the days are for. Every class below asks a question about your application’s own rules rather than about HTTP, which is why pattern matching cannot begin it.
Authentication and session
Registration, login, password reset, MFA enrolment and recovery, and the session that follows. What the reset token is derived from and how long it lives; whether a reset invalidates the sessions that existed before it; whether logout revokes server-side or only clears a cookie; whether the session identifier survives a privilege change; and what a JSON Web Token is actually verified against, algorithm, signature, audience and expiry included. Rate limiting is measured on the endpoints that matter rather than assumed absent.
Access control and IDOR
The role matrix, pair by pair. Every state-changing request from one role is replayed against the other role's object identifiers, and what the server does is recorded: a 200 where a 403 belongs is the entire class. Vertical escalation, a user reaching an administrative route. Horizontal escalation, one tenant reaching another tenant's object. And the quiet version, where the interface hides a control but the endpoint behind it does not. Where identifiers are opaque we test whether they are unguessable or merely long, and whether some other endpoint leaks them.
Business-logic abuse
Requests that are individually legal and illegal in sequence or in quantity. Price and quantity tampering on the way to checkout, negative and fractional amounts, currency substitution, discount and referral codes replayed or stacked, refund paths that credit before they debit, a state machine driven out of order, and races on anything holding a balance or a single-use token. A scanner has no model of your business rules, so this is work it cannot begin, and it is where the findings that matter usually are.
Injection classes
Wherever input reaches an interpreter. SQL and NoSQL injection including blind and time-based variants; command and template injection; server-side request forgery in every place the server fetches a URL you supplied, which in practice means webhooks, avatar imports, document renderers and link previews, with cloud metadata endpoints and internal ranges as the targets that decide severity; XML external entities where XML is parsed; unsafe deserialisation where objects come off the wire; and cross-site scripting judged by whether it executes in a real browser session, not by whether a string came back reflected.
The API surface
REST and GraphQL, tested against the OWASP API Security Top 10 rather than the web Top 10, because the failure modes are different. Object-level and property-level authorisation on every endpoint that takes an identifier; mass assignment wherever a request body binds to a model; unrestricted resource consumption through pagination limits, expensive filters, and GraphQL depth and aliasing; undocumented endpoints; and version drift, where an older path outlived the access-control rewrite that fixed the newer one.
The infrastructure edges
The perimeter that belongs to the application. TLS configuration, certificate chain and expiry, HSTS. DNS records pointing at infrastructure you no longer control, which is how subdomain takeover happens. CORS policy, and specifically whether it reflects an arbitrary origin with credentials. Cookie flags and cookie scope across subdomains. Security headers judged by exploitability rather than by presence. Storage buckets and CDN paths reachable without authentication. And webhook endpoints that accept an unsigned body, payment webhooks included, tested for signature verification and replay.
Findings from this phase are usually the ones that matter, and they are the reason the engagement is a penetration test rather than a scan. They are also the ones a fixed price makes people suspicious of, so the report tags every finding with where it came from and totals the split. You can see exactly what the engineer’s days produced.
The bar a finding has to clear
A finding is a claim about your system, and a claim needs proof. A candidate that cannot meet all six of these is not reported as a finding. It is dropped, or written down as an observation, which is a different word on purpose.
A reproduction from a clean session
The steps replay in order from a fresh session, with no state left over from the run that found it. If it happens once and not again, it is not yet a finding.
The request and the response
The exact request that does it and the response that proves it, sanitised. Not a version banner, not a scanner's confidence score, not an inference from a header.
The identity it was run as
Which role, which account, authenticated or not. An access-control finding without the identity attached is an anecdote.
Impact in one sentence
What an attacker gets. If that sentence cannot be written without the words could potentially, the impact has not been demonstrated and the rating has nothing to stand on.
A rating with its reasoning
Likelihood and impact, aligned with the OWASP Risk Rating Methodology, with the reasoning printed beside the rating rather than implied by it.
Provenance
Scanner-detected and engineer-verified, or engineer-found. Every finding carries which, and the report's appendix totals the split.
What does not become a finding: a missing header with no exploit path, a version-banner guess, a self-inflicted script injection, a rate limit that exists but is generous. Those appear as observations and are not counted in the severity totals. Padding a count is the easiest way to make a report look thorough on page one and the fastest way to make it untrustworthy by page twelve.
How findings are rated
Likelihood and impact, aligned with the OWASP Risk Rating Methodology, with the rationale printed next to the rating rather than left implied. Severity inflation is the quiet fraud of this industry, and it is easy to spot once you know to look.
Chains are rated as chains. A low-severity leak plus a medium-severity request forgery that together reach an internal service is one critical finding with two components, not three separate rows scored in isolation. The chain is what an attacker uses, so the chain is what carries the rating. Scoring findings one at a time is the main reason automated output under-rates the worst thing in an application.
What lands in the report
Two documents and two machine-readable files, 5 to 7 days after kickoff. The report is ordered so that the first two pages work for a CFO and the rest works for the engineer who has to fix things.
Every finding page carries
Formats: PDF for the report and for the attestation letter, JSON and SARIF for the findings so that remediation becomes tickets rather than screenshots of a PDF. A thirty-minute walkthrough call covers every high-severity finding, and the Q&A inbox stays open for thirty days after delivery. The page-by-page anatomy, including how to judge anyone else’s report, is on the sample report page.
The re-test, and the letter
The engagement does not end at the report. It ends when the findings have a final status and the letter says so.
After you patch, we re-test the findings at no extra charge and append an addendum. Every finding takes one of three final statuses: fixed, still open, or risk accepted. Risk accepted is yours to declare, and the addendum records in writing that it was your call. The attestation letter is then reissued to match, so the document that ends up circulating is the post-fix one rather than the alarming one.
Re-running the pipeline costs us compute rather than a second engagement, which is why the re-test is included rather than sold. For PCI DSS the addendum is what closes the 11.4.4 loop with dated evidence. For ISO 27001 it is the retest evidence a certification auditor samples first, and the artefact most often missing from the folders we are shown.
The attestation letter states
Share the letter, not the report. The letter carries no technical detail and exists to be handed to auditors, enterprise reviewers and investors. The full report contains reproduction steps for live weaknesses and should stay with your team, your auditor, and reviewers under an NDA.
The standards this maps to
Naming a methodology is the minimum an auditor should accept from anyone. Here is what each name covers in this engagement, and the row at the bottom is where our coverage stops.
| Standard or control | What it asks for | What answers it here |
|---|---|---|
| OWASP Top 10 | The consensus list of web application risk categories. | The web application phases test against it, and every finding page names the category it maps to. |
| OWASP API Security Top 10 | The API-specific list, where broken object-level authorisation and broken authentication live. | The API surface is tested against this list rather than the web one, because the failure modes differ. |
| NIST SP 800-115 | The technical guide to information security testing and assessment: planning, discovery, attack, reporting. | The shape of the engagement and the shape of the report. It is the methodology the attestation letter names. |
| SOC 2, CC4.1 | Ongoing or separate evaluations confirming internal controls are present and functioning. | An independent, dated test with a named methodology is the separate evaluation. SOC 2 never says the words penetration test; auditors expect one and commonly map it here. |
| ISO 27001, A.8.8 | Management of technical vulnerabilities: timely identification, evaluated exposure, action taken. | The report evidences identification and evaluation; the re-test addendum evidences action. It does not replace your patching records, which sit inside the same control. |
| ISO 27001, A.8.29 | Security testing in development and acceptance. | The change-triggered engagement: a new application, a new API surface or an authentication rework, tested before it carries scoped data. |
| PCI DSS 11.4.3 | External penetration testing, at least annually and after significant change. | The external application layer, which is the whole of our scope. |
| PCI DSS 11.4.4 | Exploitable vulnerabilities corrected, and testing repeated to verify the correction. | The free re-test and the dated addendum that follows it. |
| PCI DSS, internal and segmentation | Internal penetration testing and segmentation testing. | Not covered. You will need a second provider for that work, and we say so at scoping rather than at delivery. |
One engagement can serve a SOC 2 audit and an ISO 27001 certification at the same time when the scope and the dates line up: the technical work is identical and only the paperwork around it differs. The two framework-specific guides go further, on SOC 2 timing and evidence and on what an A.8.8 auditor samples.
The limits
The honest boundary of this method, collected in one place, so that you can decide whether it is the right instrument before you buy it rather than after.
If your scope is larger than the caps, the fixed number stops holding and the engagement is quoted instead. The intake page works that out on its own, before anyone gets on a call. The engagement itself is $2,999, or LKR 600,000 for companies registered in Sri Lanka, with the full price book on the pricing page.