Offensive security · Manual testing
Penetration testing and adversary simulation.
Three engagements I can genuinely deliver: what your perimeter exposes, what your own applications get wrong once someone is logged in, and what an attacker does with a foothold you hand them. The testing is manual. A scanner covers the first day. If your standard names a certification I don't hold, there is a section further down that says so before you spend an hour on a proposal.
NDA as standard. Scope, test windows and source IPs are agreed in writing before the first packet goes out.
Last updated: 4 September 2026
What I can take on
Three engagements, together or one at a time.
If you are breaking a larger scope into pieces, these are the pieces. Each one stands on its own, each is quoted separately, and each has a different prerequisite on your side.
01
Perimeter, edge services, VPN gateways, client portals
External attack surface assessment
This starts with what you look like from the outside: published services, a test subdomain nobody decommissioned, a management interface listening on the wrong side of the firewall, a VPN gateway two builds behind, a client portal that a different team built and that now lives its own life. I enumerate all of it, then work out what an attacker reaches first and how far that carries them. You end up with a host and service inventory, annotated with what should never have been reachable in the first place.
What I need from you: A domain and IP list, plus written confirmation that the assets on it are yours. Anything hosted needs the provider's authorisation as well, and providers tend to take days over that.
02
Custom-developed applications
Web and API penetration test
Authentication, authorisation, injection, business logic. A scanner runs first, because walking versions and known CVEs by hand wastes your money, but the scanner output is where the work starts. What comes back clean is almost always the authorisation layer: an object id in the URL that another tenant's session happily accepts, a role the front end hides while the API still honours it, a discount that applies twice if the two requests arrive close enough together. None of that has a signature.
What I need from you: Test accounts covering at least two roles, a staging environment with no live personal data, and a developer I can ask when something behaves oddly.
03
From an agreed foothold to a named objective
Assumed-breach exercise
We start from the assumption that one workstation or one account already belongs to the attacker, because phishing eventually lands and the interesting question is what happens after it does. From there I work the kill chain toward an objective we named in advance: a specific file on a specific share, domain administrator, a query against a database you care about. Every step is logged with a timestamp and mapped to an ATT&CK technique. The defensive side is watched throughout: which step raised an alert, which one did not, how long it took, and what the analyst on shift did with it. That gets its own chapter, and it is usually the chapter that stings.
What I need from you: A named objective, a starting access (an account or a machine), and a decision about whether the SOC knows the exercise is running. Either answer works. They measure different things.
Rules of engagement
Agreed in writing before anything starts.
- Scope is listed host by host, domain by domain, application by application. Anything not on the list stays untouched, including things I notice are wide open while I work. You get told about it. I don't go near it.
- Test windows are agreed down to the time of day. If you want nothing running during month-end close, nothing runs during month-end close.
- No denial of service. No load testing either, and no exploit whose documented side effect is the service falling over.
- Nothing that writes to or deletes production data without written approval first. On an OT network, no active tooling without prior agreement, ever.
- Two named contacts with phone numbers, one on your side and one on mine. If a system starts behaving strangely mid-test, I stop and I call. Nobody reads email during that hour.
- Source IPs are agreed up front so your SOC can separate test traffic from the real thing afterwards. Where the whole point is whether they notice, the SOC gets no advance warning and only the two contacts know.
The deliverable
A report your engineers can work from.
- 01Executive summaryOne page for the person who will not read a terminal transcript: the three worst things, what they cost you if somebody uses them, and roughly how long remediation runs.
- 02Findings with reproduction stepsRequest, response, screenshot, the CWE it maps to, and the exact sequence a developer can follow to trigger it themselves. A finding you cannot reproduce is a finding you cannot fix.
- 03Risk rankingA CVSS score, and a sentence on what it means in your environment. A 9.8 on an isolated test host matters less than a 6.5 on the payment path, and the ranking reflects that.
- 04Remediation steps for every findingWhich config line, which code path, which firewall rule. Not “strengthen authentication”, but where and what.
- 05Detection and response write-upWhat the defenders saw, what alerted, what did not, and the gap between my first move and the first response. On an assumed-breach exercise this is half the report.
- 06RetestWhether I retest after remediation, over what scope and within what deadline, is written into the proposal. It doesn't surface afterwards. It isn't a separate negotiation either.
On certification
Where the standard says CREST or CHECK, I bring in a team.
If your procurement standard requires a CREST or CHECK certified provider, I can still take this on. I run the engagement as prime contractor and bring in subcontractors who hold those certifications. You get one contract, one invoice, and one person accountable; the certification requirement is met through the people I bring in.
What I am not claiming for myself: OSCP, AZ-500 and CISSP are still in progress, I sit in the HackTheBox global top 1000, and I have spent years doing this work on production systems, but as one person I do not cover a CREST-level requirement, and I am not going to call myself something I am not. Project management, scope, and the report stay my responsibility; the certified technical work is delivered by the subcontractor.
If your standard allows the scope to be split, say because testing your own applications falls outside the certification requirement, we can run that part separately too. Tell me exactly which certification needs to be on file, and I will come back with names, CVs, and certificates.
The other half
The same person fixes what the test finds.
Most test reports end their life in a folder, and the same finding comes back on the next engagement. Here remediation can be the next phase of the same job: segmentation, access control, logging and hardening, built by the person who spent the previous week getting through them. No handoff between the report and whoever configures the firewall.
Evidence collection and alert triage are covered on the security automation page, the technical side of NIS2 has its own page, and if the network runs alongside a production line, start with OT/IT security.
Frequently asked questions
What does a test cost?
It is scoped per target list and per engagement, because an eight-host perimeter and a twenty-role application are not the same job. To quote the first I need the domain and IP list; to quote the second, the number of roles and whether a staging environment exists. You get a written proposal against a fixed scope after the intro call.
Is this a scanner report?
No, although a scanner is part of it. Versions, open ports and known CVEs come out of a tool on day one, and that is the cheap part of the week. What you pay for is the authorisation and business-logic testing no tool performs, plus stripping the false positives before you ever see them.
Can you take our systems down?
Not by design, because I don't do the things that take systems down: no denial of service, nothing that writes to production data without written approval, and no active tooling on a live OT network without prior agreement. If something starts behaving strangely anyway, I stop and phone your contact.
Who sees the report?
You, and nobody else. An NDA is standard on every engagement, the report is delivered encrypted, and the retention period for raw test data goes into the contract. Unless you ask for something else, I delete it when the engagement closes.
Do you work as a subcontractor for a consultancy?
Yes, and it is the most common arrangement I work in. You keep the client relationship, the report goes out in your template, and I don't approach your client behind your back. If the end client's standard names CREST or CHECK, we can cover that too: I run it as prime contractor and bring in a subcontractor who holds the certification, while I keep the project management and the report.
When can you start, and how long does it run?
An external surface assessment is usually a few days, an application test one to two weeks, an assumed-breach exercise depends entirely on scope. I run one test at a time, so the start date depends on what is ahead of it in the queue. You get that answer on the first call, before there is a contract to sign.
Let's start
Bring the target list.
30 minutes, free. A domain list or an application name is enough. By the end of the call you will know which of the three engagements fits, roughly how long it runs, and what you need ready before it does.