From security-engineer
Passive reconnaissance on a target domain or organisation using open-source intelligence. Maps the attack surface from publicly available sources only. Use at the start of a penetration test or security assessment to understand what's exposed before active testing begins.
npx claudepluginhub hpsgd/turtlestack --plugin security-engineerThis skill is limited to using the following tools:
Conduct passive reconnaissance on $ARGUMENTS.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Designs, implements, and audits WCAG 2.2 AA accessible UIs for Web (ARIA/HTML5), iOS (SwiftUI traits), and Android (Compose semantics). Audits code for compliance gaps.
Conduct passive reconnaissance on $ARGUMENTS.
[!IMPORTANT] Passive reconnaissance only. This skill collects publicly available information without touching the target's systems. Active scanning (nmap, Burp, nikto, etc.) is outside this skill's scope. Authorisation for subsequent active testing does NOT come from this skill — confirm scope and rules of engagement before proceeding to any active phase.
Before starting, confirm and log:
Reconnaissance that drifts outside the agreed scope can have legal and contractual consequences. When uncertain, check with the client before proceeding.
Using only passive sources (no active DNS queries to the target):
Certificate transparency — crt.sh: search for all certificates issued to %.target.com. This is the single most reliable passive subdomain discovery method.
DNS records — SecurityTrails public search or dnsdumpster.com for historical DNS data including subdomains, MX records, and past IP associations.
WHOIS — registrant, nameservers, registration date. See /investigator:domain-intel for the full WHOIS methodology including AU/NZ registries.
Google dorking — passive web search queries to discover indexed content and exposed resources:
site:target.com -www # Subdomains indexed by Google
site:target.com filetype:pdf # Exposed documents
site:target.com inurl:admin # Admin interfaces
site:target.com "index of" # Directory listings
Find all IP ranges associated with the organisation:
This establishes the full IP surface area, including ranges that may not be surfaced by DNS alone.
Identify technologies in use from passive indicators:
Job postings — the most underrated reconnaissance source. Job postings name specific technologies, versions, and products. A job ad for a "Senior AWS security engineer with experience in Terraform and Kubernetes" tells you the cloud platform, IaC tool, and container orchestration.
Search: LinkedIn Jobs, Seek (AU/NZ), the company careers page.
Web technologies — Wappalyzer public lookup, BuiltWith (for public data tier). Reveals CMS, CDN, analytics, and framework choices.
Email headers — publicly available email headers (in press releases, newsletters) reveal mail server software, delivery infrastructure, and SPF/DKIM configuration.
TXT record analysis — from DNS step: third-party services declared in TXT records (HubSpot, Salesforce, SendGrid, Google Workspace, Microsoft 365) map the SaaS surface area.
Shodan and Censys index internet-connected services from their own scanning activity — looking at their data is passive from your perspective.
Search by: organisation name, ASN, IP range, domain name.
Note: Shodan/Censys data has a timestamp. Flag the scan date of any findings — a service that was exposed 6 months ago may have been remediated.
Key findings to surface: exposed management interfaces, non-standard ports with service banners, TLS certificate details, HTTP response headers.
HaveIBeenPwned — api.haveibeenpwned.com/api/v2/breachedaccount/[email] or domain search to identify breaches affecting corporate email addresses.
Public paste sites and GitHub — search for: target.com password, target.com api_key, target.com secret. GitHub dork: "target.com" filename:.env or "target.com" api_key.
Finding leaked credentials doesn't mean they're still valid — but it confirms the credential class was exposed and should be flagged for the client to investigate.
What information could an attacker use for social engineering or phishing?
This section informs the social engineering risk assessment, not active attacks.
## Reconnaissance: [Target]
**Engagement:** [authorisation reference]
**Date:** [today]
**Scope:** [domains / IP ranges in scope]
**Out of scope:** [exclusions]
**Method:** Passive OSINT only
### Domain and subdomain inventory
[Subdomains found via cert transparency, DNS, Google dorking]
### IP ranges and ASN
[Registered ASNs and IP blocks]
### Technology fingerprint
| Category | Technology | Source | Confidence |
|---|---|---|---|
| Web framework | — | Wappalyzer | High / Medium |
| Email | — | MX record | High |
| Cloud | — | Job postings | Medium |
### Exposed services (Shodan/Censys)
| Service | IP:Port | Shodan scan date | Notes |
|---|---|---|---|
### Credential exposure
[Breach data findings — with breach names and dates, not plaintext credentials]
[GitHub/paste findings — with URLs to the specific commits/pastes]
### Social engineering surface
[LinkedIn structure, email format pattern, notable disclosures]
### Attack surface summary
[High-level assessment: what stands out, what warrants active testing focus]
### Out-of-scope findings
[Anything surfaced that falls outside agreed scope — noted but not investigated]