How we run a vulnerability test in practice.

We never test without written consent.

A vulnerability test is technically a controlled simulation of an attack. That means we send packets, attempt logins, and look for misconfigurations that could be abused. Without consent from the owner, it's the same act as a real intrusion, and falls under computer-misuse laws almost everywhere.

What we need before we start

• Written consent from the domain owner. We need confirmation from someone who actually owns or administers the target.
• Scope agreement. Which domains, IPs, and ports are in scope, and what is explicitly out.
• Time window. We agree on when the scan runs, so your ops team doesn't have a heart attack at two in the morning.

Once this is in place, you get an engagement ID you can reference when we discuss findings later.

Eight phases, from mapping to report.

A full test follows a fixed sequence. Each phase builds on the last, and you get a status update when each phase finishes. The AD and cloud phases are skipped if your target doesn't have the relevant infrastructure.

We tune the pace to your production.

You decide how hard we step on it. An aggressive test goes faster, but trips firewalls and can look like a real attack in the SOC. Stealth mode takes longer but flies under the radar, useful if you want to test whether your detection actually works.

The tools we use, and why.

Every tool has a reason to be here. Here's each one, with the example command we actually run and the kind of findings it typically surfaces.

Dedicated test agents per domain.

Beyond the classic command-line tools, we have ten specialist agents that each cover their own domain. Each agent knows what's relevant for its area, what's normal, and what typically goes wrong. They run asynchronously and report findings back to the same engagement.

60+ named probes, runnable individually.

Every bug class we test for has one or more dedicated probes. The list grows every month. You can run them all as a bundle through the web agent, or pick out specific probes for targeted testing. Here's what's in today, grouped by attack category.

Red chips = can hit critical or high CVSS when triggered. Yellow = medium. Each probe has its own "requires_auth" flag that controls whether it fires against unauthenticated or only logged-in targets. Full list via list_probes.

What the other tools don't have.

The platform we use runs several layers above the raw scanners. These features are why we can deliver a report that isn't just an export of Nuclei output.

The report you get, and what's in it.

A pen-test and recon you can't act on is just a long PDF. We write reports that give the ops team a concrete order: this first, here's how you fix it, here's how you verify it's gone.

Structure

• Executive summary. One page leadership can read. What we found, what it means, what it costs to fix.
• Technical overview. Every finding with CVSS score, CWE ID, and OWASP category.
• Attack chains. How three medium findings can be combined into one critical problem.
• Proof of Concept. The exact command or request that demonstrates the vulnerability, and what the response looks like.
• Remediation. For every finding: temporary mitigation, permanent fix, how to verify.
• Detection rules. Sigma rules you can drop straight into the SIEM.
• Appendices. Raw output from every tool, if you want to double-check.

CVSS prioritization

Every finding gets a CVSS 3.1 score. We group them like this:

• Critical (9.0–10.0). Fix within 24 hours. Actively exploitable from the internet, gives control of the system or data.
• High (7.0–8.9). Fix within 7 days. Exploitable with logged-in users, or leaks sensitive information.
• Medium (4.0–6.9). Fix within 30 days. Requires specific conditions, or contributes to a larger attack.
• Low / Info (<4.0). Best practice. Fix when you can.