Methodology
Automated discovery for scale. Human offensive-security judgement for what matters. Here is how that actually works in practice.
Discovery: mapping the real footprint, not the assumed one
We start from seed information you provide (organization name, known domains, brands) and expand outward using the same reconnaissance techniques an attacker would use: DNS enumeration, certificate transparency logs, passive and active subdomain discovery, ASN and IP-range analysis, cloud-provider fingerprinting, and technology fingerprinting of what we find. The goal is a footprint built from evidence, not from your CMDB.
Analysis: separating signal from noise
Every discovered asset is triaged. Some are clearly owned and expected. Some are unexpected: forgotten staging environments, subsidiary infrastructure, third-party-hosted assets nobody remembers commissioning. Each is analyzed for exposure: what's actually reachable, what technology is running, what version, what configuration is visible from the outside.
Validation: where automation stops and offensive security starts
Automated tools are good at finding candidates. They are not good at judgement. A flagged observation might be a real weakness, a false positive, or something that looks interesting but leads nowhere. An experienced offensive-security professional manually reviews the observations that matter: checking configuration by hand, testing authentication behaviour, confirming whether a fingerprinted version is actually exploitable in context, before anything is reported as a finding.
Connecting exposures: attack-path investigation
A single exposed component is rarely the whole story. Where scope and authorization allow, we investigate whether individual weaknesses can be chained: an unknown asset leads to an exposed application, which has a validated weakness, which permits access, which has a business consequence. This is the same chain-of-reasoning an attacker uses, documented as evidence, not speculation.
Reporting on what we didn't find, too
Every attack hypothesis we test is reported, whether it was validated or not. A tested-and-resisted scenario is evidence of a working control, and we treat it with the same rigor as a validated finding. We do not claim absolute security, and we're explicit about the limitations and boundaries of each assessment.
What we actually use, phase by phase
Naming the toolchain is less important than being clear about where automation ends and a person takes over. In broad terms:
- Discovery relies on passive sources first: certificate transparency logs, DNS records, WHOIS and ASN registries, search-engine and code-repository exposure, cloud-provider metadata. Active scanning is layered on top only where scope allows, and is throttled to avoid any operational impact.
- Analysis fingerprints each discovered asset (technology, version, configuration signals) and cross-references it against known exposure patterns, without yet treating anything as a confirmed finding.
- Validation is where a person takes over from the tooling: manually confirming whether a fingerprinted version is actually exploitable in its specific context, whether an exposed panel actually accepts the credentials it appears to, whether a misconfiguration is reachable the way it looks on paper. This step is why an EASM platform's raw output and our report rarely say the same thing, see how this compares to a traditional penetration test.
We don't publish a fixed tool list. Tooling changes; the discipline of not reporting anything that hasn't been manually checked doesn't.
Methodology questions
Do you use AI or LLMs to generate findings?
AI-assisted tools may help with discovery-phase triage, narrowing a large candidate list faster. They never generate a reported finding on their own. Every finding in the report has been manually verified by a person before it is written up.
How do you avoid false positives?
By not reporting anything until it has been manually validated. Automated discovery produces candidates, not findings. A candidate becomes a finding only once someone has confirmed, by hand, that the exposure is real and reachable in its current configuration.
What is the difference between your discovery phase and a vulnerability scanner?
A vulnerability scanner checks known assets against a signature database. Our discovery phase first has to establish what your known assets even are, working outward from public reconnaissance sources the way an attacker would, before anything gets checked against anything.
Do you follow a specific industry framework?
The approach draws on established offensive-security practice (OSINT reconnaissance, OWASP testing guidance where applications are in scope) rather than a single named framework, because attack surfaces rarely fit one framework cleanly. What matters more than the label is that every step is documented with evidence.