Penetration Testing

Penetration testing at INLD is a manual discipline supported by tooling, not the other way round. We begin from an agreed scope and rules of engagement, map the attack surface, and then work through authentication, authorisation, session management, input handling, business logic and data exposure in the order that risk dictates. Automated scanners are used with tuned rulesets to clear ground quickly; every candidate finding is then verified by hand so the report contains no unconfirmed scanner output. Where exploitation is authorised, we produce controlled proof-of-concept evidence to establish real impact rather than theoretical severity. Findings are documented with reproduction steps precise enough for a developer to follow without contacting us.

What the engagement covers

A penetration test is only as useful as its boundary. We begin by agreeing exactly which systems, domains, accounts and third-party components are in scope, which are explicitly out of scope, and what the testing constraints are — rate limits, prohibited techniques, maintenance windows, and the escalation path if something breaks. That agreement is written down and signed before any traffic is generated, because a supervisor reviewing the engagement later will want to see that the boundary was defined in advance rather than rationalised afterwards.

Within the boundary, testing follows the OWASP Testing Guide v4.2 for web applications, the OWASP Mobile Application Security Testing Guide where mobile clients are in scope, and PTES for the overall engagement structure. NIST SP 800-115 provides the assessment framing: plan, discover, attack, report. Automated scanning is used deliberately and with tuned rulesets, primarily to enumerate surface area quickly. It never produces a finding on its own. Every candidate issue is reproduced by hand before it is written up, which is why our reports do not contain the false-positive noise that raw scanner exports are known for.

Where we find most issues

Across financial services and digital asset clients, the categories that produce the highest severity findings are consistently access control and business logic rather than injection. Authentication tends to be implemented carefully because it is visible; authorisation is implemented per endpoint and drifts as the application grows. We test whether identifiers are enforced against the authenticated principal on every route, whether privilege boundaries hold under role changes and impersonation features, and whether a workflow can be entered at step three when steps one and two carried the actual checks.

Business logic testing is where scope and time budget matter most. Withdrawal limits that reset on a race, refund flows that can be replayed, negative quantities that survive client-side validation, and approval chains that a single compromised account can complete alone are all defects that no signature-based tool will report. We work through the application's own money and data movements with the client's product documentation in hand, because these findings depend on understanding what the system is supposed to prevent.

Exploitation and evidence

Where exploitation is authorised in the rules of engagement, we demonstrate impact rather than assert it. A proof of concept is controlled, minimal and reversible: enough to establish that an attacker reaches data or capability they should not, and no further. We do not pivot beyond the agreed boundary, we do not exfiltrate production personal data, and we record the exact time of any action that could appear in the client's own monitoring so their detection team can correlate it afterwards. Several clients treat that correlation as a secondary output of the test: if our activity never appeared in their alerting, that is itself a finding.

Findings are scored using CVSS 4.0. We publish the full vector, not just the numeric score, so that a reader can see which environmental assumptions drove the severity and adjust them against their own deployment. Where the CVSS result understates business impact — which happens regularly with logic flaws — the report states the business consequence explicitly alongside the score rather than inflating the vector to compensate.

Retest and closure

Remediation is verified, not assumed. After the client reports fixes, we retest each finding against the original reproduction steps and record the outcome as resolved, partially resolved or unresolved, with evidence for each. The retest report is a separate document, so it can be handed to an auditor without the original technical detail attached. On completion we issue a concise attestation stating the scope tested, the methodology followed, the dates of testing and retest, and the residual findings the client has accepted. That document is written for regulators, partners and auditors who need assurance without an appendix of exploitation detail.