// RESTRICTED ACCESS
This document contains non-public methodology and toolchain detail. Enter your access code to continue.
ACCESS CODE
// INVALID CODE — ACCESS DENIED
Access restricted to authorized prospects and clients.
Contact info@lucretia-security.com to request access.
LUCRETIA SECURITY // ENGAGEMENT METHODOLOGY

This is what we actually do.
Every. Single. Engagement.

What follows is a complete, phase-by-phase breakdown of how Lucretia conducts an External Attack Surface Management engagement — from the first passive recon query to the final validated deliverable. No marketing language. No ambiguity. This is the process.

APPROACH
Human-Driven. AI-Powered.
STANDARD
Proof-Backed Validation
FALSE POSITIVE RATE
Zero. Guaranteed.
VALIDATION PASSES
Minimum Two, Independent
// 9-step walkthrough of the platform — screenshots + live proof demo
01
PHASE 01 //
RECON

Before we touch a single host, we know more about your external footprint than most of your own team does. Phase 01 is entirely passive — nothing we do here is detectable. We are building a complete picture of your organization's internet-facing presence using publicly available data, commercial intelligence feeds, and open-source tooling — all before issuing a single packet toward your infrastructure.

// SHODAN / CENSYS

Commercial internet scan indexes queried by org name, domain, and IP range — before we send a single packet toward your infrastructure.

Open ports and service banners already indexed against your IPs
Known CVEs flagged by Shodan against your hosts
Cloud and shadow IT assets you may not know are exposed
ASN and IP range attribution
// SUBFINDER

Passive subdomain enumeration across 75+ public sources simultaneously — no DNS brute force, no noise, just what's already publicly known.

Subdomains not visible in public DNS records
Staging, dev, and internal hostnames exposed passively
Cross-referenced against Shodan for hosts already indexed
// WHOIS / ASN INTELLIGENCE

Organization registration records, IP range ownership, and ASN attribution mapped before any scanning begins. We establish the full legitimate IP space — and look for what's missing from it.

All IP ranges registered to your organization or subsidiaries
ASN relationships revealing acquisitions or legacy infrastructure
WHOIS registrant data cross-referenced against domain portfolio
IP blocks present in Shodan but not in official registration records
// theHARVESTER

Multi-source OSINT aggregator pulling email addresses, hostnames, and IPs from search engines, LinkedIn, Hunter.io, and passive DNS services.

Email addresses associated with your domain
Personnel names and roles (social engineering surface)
Hostnames and IPs surfaced in search engine indexes
// DeHASHED / DARK WEB

Breach database and dark web index queries run against your domain before any active phase begins. We find out what attackers already have.

Email:password pairs from breach databases matching your domain
API keys, tokens, and secrets in public repositories
Dark web paste hits indexed within the past 90 days
// WAYBACK / GAU

Historical web crawl archives surface endpoints, parameters, and subdomains that no longer appear in DNS or sitemaps — but are still live.

Forgotten endpoints and API paths still responding
Subdomains that were once public but dropped from DNS
URL parameters revealing internal application structure
// SUBDOMAIN ENUMERATION

Subdomain enumeration runs against 75+ passive sources simultaneously. We are not brute-forcing DNS — we are aggregating what is already publicly known.

Certificate transparency logs (every cert ever issued for your domains)
DNS dataset aggregators and passive resolver records
Public GitHub repos, CI configs, Docker registries
Wayback Machine URL patterns revealing hidden subdomains
Cross-reference: subdomains that appear in Shodan but not in DNS
// CERTIFICATE TRANSPARENCY

Every SSL/TLS certificate issued by a public CA is logged in the CT ledger. We mine this to find every domain and subdomain your organization has ever had a cert issued for.

Subdomains revealed in cert SAN fields that aren't in public DNS
Old or expired certs pointing to legacy infrastructure still live
Internal hostnames accidentally included in public certs
Third-party services (CDNs, SaaS) linked to your domains
// CREDENTIAL EXPOSURE

Before any scanning, we check whether credentials belonging to your domain are already circulating in breach data or accessible in public repositories.

Email:password pairs from breach databases matching your domain
API keys, tokens, and secrets in public GitHub / GitLab repositories
Dark web paste sites indexed within the past 90 days
Internal IP addresses and hostnames exposed in leaked config files
// RECON OUTPUT: A fully de-duplicated, scope-confirmed host list — IP addresses, live hostnames, identified services, and known-vulnerable banners — built entirely without touching your infrastructure. This list drives everything that follows.
// HUMAN
WHERE A HUMAN IS IN THIS PHASE
Scope confirmation: Before any active phase begins, a human analyst reviews the aggregated RECON output and signs off on the final in-scope host list. Edge cases are reviewed — cloud assets, third-party subdomains, ambiguous IP ranges.
Dark web triage: Automated tools surface breach data and paste hits, but a human determines whether a credential match is relevant, stale, or a false association with your organization.
Anomaly flagging: Unexpected assets — subdomains pointing to abandoned infrastructure, legacy systems — are flagged for human review before they advance to SCAN.
OSINT interpretation: Raw intelligence data is reviewed by an analyst for context that automated tools cannot infer — organizational relationships, acquisition history, named subsidiaries.
// DNS RECORD ANALYSIS
📧
MX / SPF / DKIM
Mail configuration reveals third-party providers, email security gaps (missing SPF, weak DKIM), and potential for spoofing attacks against your domain.
🔗
CNAME Chains
CNAME records pointing to unclaimed or expired third-party services — a common source of subdomain takeover vulnerabilities.
🌐
Zone Transfer Attempt
Misconfigured DNS servers can return your entire zone file — exposing internal hostnames, IP ranges, and network topology.
02
PHASE 02 //
SCAN

Every host confirmed in RECON is scanned across the full 65,535-port range. Not the top 1,000. Not the top 10,000. All of them. Attackers don't limit themselves to well-known ports — neither do we. Every open port is interrogated: service version, protocol, banner, SSL presence, and OS fingerprint.

// NMAP

Full 65,535-port SYN scan on every in-scope host. Host-alive checks are bypassed — if it's in scope, it gets scanned regardless of ping response.

Every open TCP port with service version and banner
OS fingerprint and TTL-based stack identification
NSE script output: default credential checks, protocol enumeration, known vulnerability signatures
Filtered vs. closed port distinction for firewall mapping
// SSLSCAN

Dedicated TLS/SSL enumeration run independently against every port presenting a certificate — not just 443. Covers the full cipher and protocol surface.

Every cipher suite supported, including RC4, DES, NULL, and export-grade
Protocol versions: SSLv2, SSLv3, TLS 1.0, TLS 1.1 — all deprecated, all flagged
Certificate chain: expiry, CN/SAN fields, self-signed status
HSTS header presence and max-age value
// TESTSSL.SH

Second-pass TLS analysis run independently from SSLScan. Cross-checks cipher results and adds protocol-level attack surface testing.

Protocol attack checks: BEAST, POODLE, ROBOT, Heartbleed, CRIME, DROWN, LOGJAM
Forward secrecy support (ECDHE / DHE key exchange present)
Session resumption and renegotiation behavior
JSON output captured for automated proof extraction
// HTTPX

HTTP/HTTPS probe across every open port — not just standard web ports. Maps every web application in scope, including those running on unexpected ports.

HTTP status codes and redirect chains per port
Server header and X-Powered-By technology disclosure
Web apps on non-standard ports (admin panels, dev servers, APIs)
Response fingerprinting for framework and CMS identification
// WAFW00F

WAF and reverse proxy detection across all web-responding hosts. Knowing what's in front of a target informs how the rest of the assessment is structured.

WAF vendor and product identification (Cloudflare, Akamai, Imperva, F5, etc.)
Unprotected hosts — no WAF detected, direct exposure confirmed
Inconsistent protection — WAF on some ports but not others
WAF bypass surface flagged for deeper assessment
// SSH-AUDIT

Dedicated SSH service analysis run against every SSH port in scope. Version detection alone isn't enough — algorithm support is what determines actual exposure.

OpenSSH version mapped against CVE database
Weak key exchange algorithms (diffie-hellman-group1-sha1, group14-sha1)
Deprecated MACs (MD5 and SHA-1 based)
Password authentication enabled and root login permitted flags
// ZAP

OWASP ZAP with AJAX spider runs against every web-responding host — passive mode first, then active probing. Covers dynamic content that static crawlers miss.

Injection points: SQL, command, header, and parameter injection candidates
Information disclosure: server internals, debug output, stack traces in responses
Authentication and session management weaknesses
Security header gaps surfaced across every scanned URL
// NIKTO

Web server misconfiguration scanner targeting server-level exposure — not application logic. Runs against every HTTP/HTTPS port identified by httpx.

Dangerous HTTP methods enabled: PUT, DELETE, TRACE
Directory listings and exposed backup files
Default credentials on known software interfaces
Outdated server software with known CVE signatures
// KATANA / GAU

Endpoint discovery across every web application in scope — Katana crawls what's live, GAU surfaces what was once public. Together they map the full reachable surface.

All reachable paths, forms, and JavaScript-referenced endpoints
API routes and parameter patterns exposed in client-side code
Historical endpoints from Wayback Machine and Common Crawl — still live but unlinked
Hidden admin paths and legacy routes not visible from the homepage
// SECURITY HEADER & CONFIGURATION CHECKS
🛡️
Content Security Policy
Missing, weak, or unsafe-inline CSP headers — enabling cross-site scripting, data injection, and clickjacking attacks.
🍪
Cookie Flags
Session cookies missing HttpOnly, Secure, or SameSite attributes. Each missing flag is a concrete, provable finding.
🔓
HTTP Methods
Dangerous methods enabled: PUT, DELETE, TRACE, OPTIONS. PUT/DELETE on a web server can mean direct file write access.
🔐
HSTS & HTTPS
Missing Strict-Transport-Security headers, HTTP-to-HTTPS redirects not enforced, preload list absence.
📦
Subresource Integrity
Third-party scripts loaded without SRI hashes — supply-chain injection risk if the CDN or third-party source is compromised.
⚠️
Error Disclosure
Stack traces, database errors, internal paths, and framework version strings returned in error responses.
// SCAN OUTPUT: A complete port-service matrix for every in-scope host — every open port, every identified service and version, every TLS configuration, every web application endpoint, and every security header finding. Nothing is assumed closed. Nothing is assumed irrelevant.
// HUMAN
WHERE A HUMAN IS IN THIS PHASE
Anomaly review: When a host returns unexpected services — a database on a web port, an admin interface on a high port — an analyst reviews before those findings advance.
Scan result QA: Automated scans can misidentify services. A human reviews ambiguous banner matches and confirms service identification for high-value targets.
Scope edge cases: If a new IP or hostname surfaces during scanning that wasn't in the original RECON list, a human determines whether it falls within scope before it is touched further.
03
PHASE 03 //
ASSESS

Raw scan output is triaged by analysts. Every identified service version is cross-referenced against CVE databases. Every web application is probed for security header misconfigurations, injection points, and client-side exposures. Scanner noise is discarded. Only findings with genuine risk potential advance.

// VULNERABILITY CROSS-REFERENCE
NVD / CVE Database
Every service version matched against the National Vulnerability Database
CVSS v3 base score pulled per CVE match
Temporal scoring applied where exploit availability is known
Exploit-DB / SearchSploit
CVEs cross-referenced against public exploit availability
Findings with a public exploit are elevated in priority
Exploit type noted: remote, local, DoS, or proof-of-concept
Nuclei + Vulscan
Community and custom Nuclei templates run against all web-responding hosts
Vulscan NSE adds a local CVE lookup pass driven from nmap service output
Covers CVEs, exposed panels, misconfigurations, and tech-specific checks
// ASSESS OUTPUT: A prioritized finding list with CVSS scores, exploit availability flags, and real-world risk context. Each finding is assessed for whether it can be proven with a reproducible command. Those that can proceed to VALIDATE. Those that cannot are flagged for manual research.
// HUMAN
WHERE A HUMAN IS IN THIS PHASE
Exploitability judgment: CVSS scores are a starting point, not a verdict. A human analyst reviews each finding's real-world context — is the service internet-facing? Is there a public exploit? Is the affected code path actually reachable?
Cannot-confirm escalation: Findings that automated tools flag but cannot produce proof for are escalated to an analyst for manual research. The analyst determines whether a custom approach can confirm the finding or whether it should be classified as NOT_VALIDATED and held.
Web application review: Automated web app scanning surfaces candidates. A human analyst reviews results for logic flaws, auth bypass attempts, and business-context vulnerabilities that scanners cannot reason about.
Noise filtering: Automated tools generate false positives. A human removes scanner noise before anything enters the VALIDATE queue — ensuring analysts aren't chasing phantom findings.
04
PHASE 04 //
VALIDATE

This is where most EASM vendors stop — and where we start. A finding in our system does not exist until it can be proven. Not inferred. Not flagged. Proven, with a specific command, against a specific host and port, producing real output that directly demonstrates the vulnerability.

// CORE PRINCIPLE: NOT_VALIDATED = NOT_VERIFIED. A finding with no proof command is not a finding. It is a hypothesis. We do not ship hypotheses.
// THE VALIDATION GATE

Every assessed finding must pass through the validation gate before it can advance. The gate requires:

VALIDATION REQUIREMENTS GATE STATUS
REQUIREMENT
Specific host IP retained
REQUIREMENT
Specific port retained
STATUS
REQUIRED ✓
REQUIREMENT
Reproducible command produced
REQUIREMENT
Real output captured
STATUS
REQUIRED ✓
REQUIREMENT
Command is copy-paste-ready
REQUIREMENT
Client can run it themselves
STATUS
REQUIRED ✓
FAIL CONDITION
Cannot produce proof command
OUTCOME
NOT_VALIDATED
RESULT
DOES NOT SHIP ✗
// VALIDATION TOOLS BY FINDING TYPE
nmap (targeted)
Service-specific NSE scripts run against the exact host:port. Output captures the vulnerable version or configuration state directly.
openssl s_client
TLS vulnerability confirmation — deprecated protocol support, weak ciphers, certificate issues. Exact host:port, exact cipher negotiated.
curl
HTTP header validation — CSP presence, HSTS headers, cookie flags, server version disclosure. Explicit IP:port prevents DNS ambiguity.
ssh-audit
SSH algorithm and version validation. Produces a structured output listing every weak algorithm with a fail/warn/info classification.
testssl.sh
Protocol vulnerability confirmation — BEAST, POODLE, Heartbleed, ROBOT. JSON output captured as evidence with specific CVE references.
nuclei
CVE-specific template execution against the exact target. Match output captured as proof of the specific vulnerability condition.
ZAP
Web application finding validation — injection points, auth weaknesses, and header findings confirmed with a targeted active scan against the specific host:port. Alert output captured as proof.
Burp Suite
Manual validation of web findings that require request-level inspection — parameter tampering, session token analysis, and logic flaw confirmation. Used where automated proof capture is insufficient.
// VALIDATION OUTPUT: Each finding exits this phase as a VALIDATED file — containing the finding type, host IP, port, proof command, and captured output. The proof command is written to be run verbatim by the client's own team to reproduce the result. IP and port are retained in every data record, without exception.
// HUMAN
WHERE A HUMAN IS IN THIS PHASE
Proof command review: Every auto-generated proof command is reviewed by an analyst before it is executed. The command must target the correct host and port, use the appropriate tool for the finding type, and be written clearly enough for a client to run independently.
Cannot-confirm escalation: When automated validation produces no usable output — service unreachable, tool incompatibility, ambiguous result — the finding is escalated to a human analyst. The analyst attempts a manual approach. If proof still cannot be produced, the finding is marked NOT_VALIDATED and does not advance.
Output interpretation: Captured proof output is reviewed by a human to confirm it directly demonstrates the vulnerability — not a related condition, not a partial match. The analyst writes the finding description based on what the output actually shows.
05
PHASE 05 //
VERIFY

Every VALIDATED finding is subjected to a second, independent confirmation pass using a different tool and a different method. If the second method contradicts the first, the finding is pulled — not reported. This is the gate that eliminates false positives entirely, and no other EASM vendor runs this process at scale.

// THE SECOND-PASS PRINCIPLE

No tool is infallible. A single tool's output can reflect a momentary condition, a parsing error, or a false match. We treat each VALIDATED finding as a hypothesis that must be independently confirmed before it earns the right to appear in a client deliverable.

Different tool — not a second run of the same tool against the same target
Different method — where possible, different protocol-level approach
Same result required — if the result differs, the finding is escalated for manual analyst review, not automatically accepted
Both commands retained — the final deliverable includes evidence from both passes
// WHAT GETS PULLED AT VERIFY

The VERIFY phase is designed to be adversarial — it actively fights to disprove findings. The following conditions cause a finding to be pulled:

Second method cannot reproduce the condition at the same host:port
Service has changed between VALIDATE and VERIFY runs (transient condition)
Finding relies solely on banner version without service confirmation
CVE matched but target not confirmed to be running the affected code path
HTTP-only finding detected on a port that also serves HTTPS (would be a different finding)
// EXAMPLE: DUAL-METHOD VERIFICATION

For a TLS 1.0 finding, the two methods look like this:

// METHOD 01 — VALIDATE PASS
SSLScan
SSLScan runs against the specific host:port and enumerates all accepted protocol versions. Output shows TLS 1.0 as "enabled" in the negotiated cipher list. Captured output becomes Proof A.
VS
// METHOD 02 — VERIFY PASS
openssl s_client
openssl s_client explicitly requests a TLS 1.0 connection to the same host:port. If the handshake completes successfully, Proof B is captured. Both proofs ship in the deliverable.
// VERDICT MATRIX — POSSIBLE OUTCOMES
VALIDATE RESULT VERIFY RESULT VERDICT ACTION
CONFIRMED ✓ CONFIRMED ✓ VERIFIED Ships in report
CONFIRMED ✓ NOT REPRODUCED ✗ CONFLICT Manual analyst review → likely pulled
NOT CONFIRMED ✗ N/A NOT_VALIDATED Does not advance to Verify
CONFIRMED ✓ NO METHOD AVAILABLE HUMAN REVIEW Analyst documents reason, senior review required
// VERIFY OUTPUT: A final, dual-confirmed finding set where every entry has been independently reproduced by two separate methods. This is the list that gets reported. Nothing else.
// HUMAN
WHERE A HUMAN IS IN THIS PHASE
Independent method selection: A human analyst selects the second verification method. The choice is deliberate — a different tool, a different protocol approach — not a repeat of what was already run. This judgment cannot be automated.
CONFLICT resolution: When Method 1 and Method 2 produce contradictory results, a human analyst reviews both outputs, investigates the discrepancy, and makes the final inclusion or exclusion decision. The reasoning is documented. No finding advances on a split result without senior analyst sign-off.
HUMAN REVIEW exceptions: In rare cases where no second automated method exists for a finding type, a human analyst documents the limitation, performs the closest available human review, and records the reasoning. These findings are flagged as requiring additional review before publication.
Final pre-report gate: Before any finding is cleared for the REPORT phase, a human analyst reviews the complete VALIDATE + VERIFY record — both commands, both outputs, the finding description, and the CVSS score — and confirms it is accurate, complete, and client-ready.
06
PHASE 06 //
REPORT

The deliverable is not a list of scanner output with your logo on it. It is a structured, prioritized, evidence-packed document where every claim is backed by a reproducible proof command. Your team — or your clients — can verify every single finding themselves, using the commands we provide.

📄
TECHNICAL REPORT
Full-detail findings document structured for your security team. Each finding includes CVSS score, description, proof commands, evidence output, and remediation guidance.
Finding ID, type, severity
Affected host IP + port
Proof command (Method 1)
Proof command (Method 2)
Captured output / evidence
CVSS v3 base score + vector
Remediation recommendation
📊
EXECUTIVE SUMMARY
A non-technical summary of the engagement designed for leadership and board-level audiences. Communicates risk in business terms, not scanner output.
Engagement scope overview
Severity distribution (Critical / High / Med / Low)
Security posture assessment
Top 3 risk priorities
Business impact analysis
Remediation priority matrix
🗂️
EVIDENCE PACK
All raw evidence files organized by finding. Every VALIDATED file, every captured output, every tool result — packaged for your team's records and any compliance audit trail.
VALIDATED finding files (per-finding)
Tool output captures
Scan result files
Reproducible command manifest
Engagement scope documentation
// THE PROOF STANDARD: Every finding in the deliverable ships with a command your team can copy, paste, and run from a standard Linux terminal to reproduce the result themselves. We do not ask you to take our word for it. We show you the proof and give you the tools to verify it independently.
// FORMATS DELIVERED
Word Document (.docx)
Editable technical report with full formatting, tables, and evidence sections. Suitable for client re-branding and internal distribution.
PDF
Print-ready, signed PDF version of the full technical report and executive summary. Suitable for auditors, board presentations, and compliance records.
Evidence Archive
Structured folder of all captured evidence, organized by finding ID. Includes raw tool output, command transcripts, and the validation index.
// WHAT IS NEVER IN THE REPORT
Unvalidated scanner output presented as findings
Findings without a specific host IP and port
Severity ratings without CVSS justification
Remediation recommendations copied from scanner boilerplate
Findings that could not be reproduced during VERIFY phase
Vague language: "may be vulnerable," "could potentially," "appears to"
// HUMAN
WHERE A HUMAN IS IN THIS PHASE
Executive summary authorship: The executive summary is written by a human analyst, not generated from a template. Business impact, risk narrative, and remediation priorities reflect judgment — not boilerplate. No two summaries are the same.
Finding QA review: Every finding in the final report is reviewed by a human analyst before the report is assembled. This includes verifying the proof commands are copy-pasteable, the evidence files match the finding, and the CVSS scoring is defensible.
Report accuracy review: A human reviews the assembled report end-to-end for accuracy, completeness, and client-appropriate language. Scope references, company names, host lists, and severity labels are all verified against the engagement record.
Final sign-off: No deliverable leaves the system without human sign-off. This is a mandatory gate — not a formality. The analyst who signs off is accountable for every finding, every proof command, and every recommendation in the document.
07
THE PLATFORM //
IN PRACTICE

Every phase documented above runs inside a purpose-built engagement platform. Each step is tracked, time-stamped, and linked to the findings it produces. Nothing falls through the cracks.

// THE PLATFORM

The Lucretia platform is a purpose-built engagement management system that runs every phase of an EASM assessment from first passive recon hit to final signed report. It is not a scanner dashboard or a third-party integration — it is the operational core of how we work.

Every finding, every proof command, every validation result, and every verification pass is recorded, time-stamped, and linked to the specific host and port it came from. The platform enforces the methodology — findings cannot advance to the next phase without meeting the requirements of the current one.

The result is a complete, auditable engagement record that backs every deliverable we produce.

// PLATFORM SECURITY
Hardened, dedicated cloud server — not shared infrastructure
All data in transit is encrypted
Access restricted to authorized analysts only
Every session is authenticated and logged
Client data is isolated per engagement — never commingled
No third-party services have access to engagement data
Platform access is not publicly exposed
Lucretia Security Dashboard
// MISSION CONTROL — total findings, validated count, severity distribution, active engagements at a glance
Engagements List
// ENGAGEMENTS — every active and completed assessment with phase-by-phase progress tracking
Findings Database
// FINDINGS DATABASE — portfolio-wide finding index, filterable by severity, status, and company