The launch post gave you the overview. This one goes module by module, showing you the actual Lateralus APIs and the design decisions behind each. If you’re evaluating whether Lateralus Pentester fits your workflow, this is the post to read.
PENTESTER.RECON — DISCOVERY
RECONReconnaissance is where every engagement starts. The recon module handles both passive intelligence gathering (things you can do without touching the target) and active discovery (things that generate network traffic). The key design decision here was to make passive and active stages separate functions so you can choose your footprint.
import pentester.recon as recon
// Passive only -- no target-side traffic
let intel = "example.com"
|> recon.cert_transparency() // CT logs -- subdomains for free
|> recon.osint_aggregate() // public records, registrar data
|> recon.asn_map() // which IP ranges does this org own?
// Active discovery -- generates DNS traffic
let hosts = "10.0.0.0/24"
|> recon.discover_hosts() // ICMP + ARP sweep
|> recon.dns_enum(
wordlist: "/usr/share/wordlists/subdomains-top1m.txt"
)
The passive stages are safe to run from your personal connection without a VPN. The active stages should run from an engagement box. I wanted to make this distinction explicit in the API rather than leaving it as tribal knowledge in a README.
PENTESTER.SCAN — PORTS AND SERVICES
SCANScanning is where |=> earns its keep. The fan-out operator distributes the host list across all available CPU cores. Each core runs an independent scan task. Results are collected back into a typed list when all tasks complete.
import pentester.scan as scan
// Scan 1,000 hosts in parallel -- all cores utilized
let scan_results = discovered_hosts
|=> scan.port_scan(top_ports: 1000, proto: "tcp")
// Service fingerprinting on scan results
let services = scan_results
|> scan.service_fingerprint() // banner grab, version detection
|> scan.tls_inspect() // cert chain, cipher suites
|> scan.http_headers() // security header scoring
On a 6-core machine scanning a /24 (254 hosts), top 1000 ports: 38 seconds. The same scan sequential takes about 214 seconds. The |=> operator handles the work distribution, collection, and ordering. You get back the same type you would have gotten sequentially — list[ScanResult] — with no additional API to learn.
A detail I’m proud of: the scan results maintain the original host ordering from the input. Some tools lose ordering when parallelizing. Lateralus Pentester preserves it because the fan-out semantics guarantee result ordering matching input ordering.
PENTESTER.VULN — VULNERABILITY ASSESSMENT
VULNThe vuln module crosses service version data with the CVE database. The CVE database is a local cache that updates weekly as part of the rolling subscription. High-severity CVEs with public PoC get pushed within 72 hours of disclosure so you’re not waiting a week to test for a fresh critical.
import pentester.vuln as vuln
let findings = services
|?> vuln.assess(cve_db: "latest") // version-to-CVE matching
|> vuln.check_misconfigs() // default creds, open admin
|> vuln.web_scan( // web app testing
tests: ["sqli", "xss", "ssrf", "traversal"]
)
|> vuln.api_audit() // REST/GraphQL issues
Note the |?> on vuln.assess. If the local CVE database is stale or the network is unreachable for an update, the error propagates as a typed Err(VulnDbError) value rather than crashing. You still get the rest of the pipeline output. The error appears in the report as a note on why CVE data is missing for certain services.
PENTESTER.EXPLOIT — EXPLOITATION
EXPLOITThe exploit module is the most sensitive one and the one I thought hardest about the API for. The decision I landed on: each exploit is a typed function with a clear input (Target) and a clear output (Session | Err). No magic. No “this module does stuff” black boxes.
import pentester.exploit as exploit
// Attempt exploitation, get back a Session or a typed error
let result = vuln_findings
|> exploit.select_best_match() // pick highest-confidence exploit
|?> exploit.run(target: host) // attempt -- returns Session|Err
// Or target a specific CVE
let session = {
host: "10.0.0.5",
port: 8080,
cve: "CVE-2024-21887"
} |?> exploit.run()
exploit.run always uses |?>. A failed exploit attempt is not exceptional — it’s the common case. |?> makes the error a value you work with rather than an exception you handle. The Err result carries the exploit name, the target, and the failure reason, which all go into the report.
New exploit templates ship monthly. The template format is public so subscribers can write their own and register them in the local registry.
PENTESTER.POST — POST-EXPLOITATION
POSTimport pentester.post as post
session
|?> post.enumerate_privesc() // local priv esc paths
|?> post.dump_credentials() // hashes, tokens, keys
|> post.map_lateral_movement() // reachable hosts from here
|> post.enumerate_persistence() // what's already persisted?
All post-exploitation findings come back as typed Finding structs with the same schema as vuln findings. The report module doesn’t distinguish between “vuln found during assessment” and “credential dumped during post-ex” — it’s all list[Finding], all goes in the report, all gets severity-ranked.
PENTESTER.REPORT — REPORTING
REPORTReport generation was almost an afterthought in the original design. Then I realized: if findings are typed, report generation can be completely automatic. No template filling. No manual copy-paste from tool output to report body. The module maps the type schema directly to the report structure.
import pentester.report as report
all_findings
|> report.group_by_severity()
|> report.enrich_with_remediation() // auto-fetch remediation from NVD
|> report.generate(
format: "pdf",
title: "Q2 Internal Network Assessment",
author: "bad-antics",
client: "ACME Corp",
date: "2026-04-15",
)
|> report.write_to("./q2-2026.pdf")
The JSON output format is designed for import into Dradis, PlexTrac, and DefectDojo. If you use one of those platforms for engagement management, report.write_json() gets you a file that imports without any field mapping.
PENTESTER.EVASION — STEALTH
EVASIONEvasion stages are composable wrappers. You put them before any scan or exploit stage to modify how that stage generates network traffic:
import pentester.evasion as evasion
// Apply evasion then scan
let stealthy_results = host_list
|> evasion.with_jitter(ms: 200) // randomize packet timing
|> evasion.fragment_packets(size: 8) // fragment to evade IDS sigs
|=> scan.port_scan(top_ports: 100) // scan with evasion applied
// Evasion before exploitation
vuln_service
|> evasion.decoy_traffic(intensity: 3) // inject cover traffic
|?> exploit.run(target: host)
The evasion module is updated continuously — not monthly like the module drops, but on an ongoing basis as EDR and IDS vendors publish new detection signatures. If a bypass technique goes stale, the update lands in the registry within days. This is the part of the toolset that benefits most from the rolling subscription model.
PENTESTER.CLOUD — CLOUD ATTACK SURFACE
CLOUDCloud environments have their own attack surface that doesn’t map to traditional network scanning. The cloud module handles AWS, GCP, and Azure:
import pentester.cloud as cloud
// AWS assessment
let aws_findings = aws_creds
|> cloud.aws.enumerate_iam() // list roles, policies, users
|> cloud.aws.check_privesc_paths() // can any role reach admin?
|> cloud.aws.scan_s3_public() // public buckets
|> cloud.aws.metadata_api_test() // IMDSv1 vulnerability check
|> cloud.aws.lambda_misconfigs() // serverless security issues
The GCP and Azure modules have equivalent API shapes. Cloud module coverage expands monthly as new attack patterns and provider features are added.
PENTESTER.CRYPTO — CRYPTOGRAPHIC ANALYSIS
CRYPTOimport pentester.crypto as crypto
// TLS/SSL analysis
let tls_findings = host_list
|> crypto.tls_audit() // weak ciphers, old protocols
|> crypto.cert_chain_check() // validity, expiry, chain issues
|> crypto.hsts_audit() // HSTS configuration
// Hash cracking pipeline
let cracked = dumped_hashes
|> crypto.identify_hash_type()
|> crypto.crack(wordlist: "/usr/share/wordlists/rockyou.txt")
The crypto module uses Lateralus’s built-in crypto engine, which means zero external dependencies. No OpenSSL version mismatches. The same engine is used in the rest of the toolset for audit log signing.
PUTTING IT ALL TOGETHER
The real power is composing these nine modules into engagement-specific workflows that live in version-controlled .ltl files. Here’s a complete external network assessment pipeline:
import pentester.recon as recon
import pentester.scan as scan
import pentester.vuln as vuln
import pentester.cloud as cloud
import pentester.evasion as evasion
import pentester.report as report
let scope = {
domains: ["example.com"],
ip_ranges: ["203.0.113.0/24"],
}
// Full external assessment
let findings = scope.ip_ranges
|> recon.discover_hosts()
|> evasion.with_jitter(ms: 150)
|=> scan.port_scan(top_ports: 1000)
|> scan.service_fingerprint()
|?> vuln.assess(cve_db: "latest")
|> vuln.web_scan()
// Add cloud findings
let cloud_findings = scope |> cloud.aws.full_audit()
// Merge and report
(findings + cloud_findings)
|> report.group_by_severity()
|> report.generate(format: "pdf", title: "External Assessment")
|> report.write_to("./external-2026.pdf")
Version control that file. Re-run it in 6 months. Diff the findings. The reproducibility of pipeline-expressed engagements is something I haven’t seen addressed elsewhere in the tooling ecosystem.
Subscribe at lateralus.dev/pentester. $25/month. wizard@lateralus.dev for questions.