Reconnaissance and Information Gathering Questions
Covers the preparatory information collection stage used in security assessments and offensive engagements, including both passive and active reconnaissance. Passive techniques include open source intelligence gathering from public records, domain registration and domain name system enumeration, certificate transparency monitoring, public repository and source code review, social media and corporate disclosure analysis, and review of job postings and public disclosures. Active techniques include network scanning and mapping, port and service enumeration, banner analysis, content discovery on web endpoints, application programming interface identification, technology fingerprinting, targeted probing, and vulnerability fingerprinting. Candidates should be able to describe tools and end to end workflows, how to select and tune scanning profiles, and the tradeoffs between coverage, speed, stealth and safety. The topic also covers building an attack surface map, identifying high value assets and likely entry points, prioritizing and validating findings to reduce false positives, operational security and evidence handling practices, ethical and legal considerations, reporting and documentation practices, and how reconnaissance findings inform further security testing and risk assessment.
HardTechnical
87 practiced
Create a reporting schema that maps reconnaissance findings to risk levels and remediation guidance suitable for both technical teams and executives. Define required fields for each finding (summary, technical details, evidence, reproduction steps, confidence, impact, remediation), provide example templates for severity labels and remediation steps, and describe how you would present aggregated risk trends over time to different stakeholders.
Sample Answer
**Situation / Goal**Design a reporting schema mapping reconnaissance findings to risk levels and remediation guidance usable by engineers and execs.**Schema — required fields per finding**- ID (unique)- Title / Summary (1–2 lines for execs)- Technical details (full description, affected assets, CVE / CWE)- Evidence (logs, screenshots, request/response snippets, hashes)- Reproduction steps (numbered, commands, PoC code)- Confidence (High / Medium / Low with justification)- Impact (technical impact + business impact statement)- Severity (see template below)- Remediation (short action + detailed steps)- Compensating controls / workarounds- Detection / monitoring guidance- Discovery date / reporter / status**Severity labels (example)**- Critical — Active RCE, data exfiltration possible; immediate patch/isolation- High — Auth bypass / privilege escalation; fix within 7 days- Medium — Info leak, weak crypto; prioritize in next sprint- Low — Minor misconfig, low exploitability; track**Remediation template**- Short instruction: "Patch package X to >= vY"- Steps: 1) Identify instances, 2) Apply patch, 3) Validate with test case (include PoC), 4) Rollback plan- Verification: Expected result, sample test commands- Monitoring: IOCs, SIEM rules, alert thresholds**Presenting aggregated risk trends**- For technical teams: Weekly dashboard with filterable timelines, stack-ranked assets, exploitability matrix, remediation backlog, and repeat-finding heatmap. Include raw counts, mean time to remediate (MTTR), and PRs/patch links.- For executives: Monthly one-page summary with trend lines (vulnerabilities by severity over time), risk score (weighted by severity × asset criticality), top 3 business risks, remediation progress (% closed), and recommended actions (budget/resourcing).- Use interactive drill-down: exec view links to technical tickets and PoCs; technical view links to exec context (business impact).
MediumTechnical
80 practiced
Describe how you would combine passive DNS data, Shodan/Censys lookups, and certificate transparency results to enrich a list of discovered hosts. Explain deduplication strategies, metadata to populate (open ports, geolocation, ASN), how to surface anomalous/high-risk hosts, and how to avoid relying on stale or spoofed data.
Sample Answer
**Approach summary**Start by ingesting passive DNS (pDNS) records, Shodan/Censys query results, and Certificate Transparency (CT) entries into a single enrichment pipeline, then normalize, deduplicate, score, and validate.**Deduplication strategy**- Normalize host identifiers: lower-case FQDNs, IPs, and CIDR prefixes.- Canonicalize IPv4/IPv6 and remove CNAME chains by following final A/AAAA targets.- Use composite keys: (IP, port, protocol, cert_serial, SANs) to dedupe service-level entries.- Merge records within time windows (e.g., 30 days) but keep freshest timestamp and source list.**Metadata to populate**- Host: FQDN, IP, canonical CNAME, first-seen / last-seen timestamps- Services: open ports, transport/protocol, service banners (from Shodan)- TLS: cert serial, issuer, subject, SANs, validity notBefore/notAfter (from CT & active TLS)- Network: ASN, prefix, RIR, BGP origin- Location: geolocation (from MaxMind + Shodan geo) + confidence score- Risk tags: exposed services (RDP/SMB), default creds, public cloud metadata**Surfacing anomalous/high-risk hosts**- Heuristics + scoring: recent cert issuance for old domain, mismatched ASN vs WHOIS, unexpected open risky ports, expired/zero‑day certs, service banners with known vulnerable versions.- Flag inconsistencies: multiple unrelated SANs, rapid IP churn, private-to-public migrations.- Present top-N by score and provide evidence (banner, cert, pDNS timestamps).**Avoiding stale/spoofed data**- Prefer freshest source and require multiple corroborating sources before high confidence.- Validate: perform controlled active checks (TCP SYN, TLS handshake) during engagement window.- Cross-check CT entries against live cert chain; verify cert fingerprints.- Discount single-source pDNS with very old TTLs or NXDOMAIN flapping; use DNSSEC and authoritative SOA where available.- Rate-limit and honor scope/permission; log provenance for every datapoint.Example: an IP with RDP open (Shodan banner), a new CT cert with that IP in SANs, and pDNS first-seen 2 days ago -> high priority for active validation.
HardTechnical
62 practiced
Design a scoring model to prioritize assets discovered during reconnaissance for further testing. Define attributes to use (exposure, sensitivity, criticality, exploitability, business impact), propose weightings and normalization, describe how to compute a final score, and explain how manual triage feedback is incorporated to refine the model over time.
Sample Answer
**Approach (brief)** I’d build a weighted, normalized composite score combining measurable attributes (exposure, sensitivity, criticality, exploitability, business impact). Scores drive which assets I test first and are refined with triage feedback.**Attributes & measurement**- Exposure (0–10): public IPs, open ports, internet-facing apps, DNS records.- Sensitivity (0–10): data classification (PII, payment), regulatory scope.- Criticality (0–10): uptime requirements, service dependencies, SLA.- Exploitability (0–10): presence of known CVEs, aging software, auth flaws.- Business impact (0–10): financial loss, reputational, customer impact.**Weighting & normalization**- Initial weights (tunable): Exposure 0.20, Sensitivity 0.20, Criticality 0.20, Exploitability 0.25, Business impact 0.15 (sum = 1).- Normalize each attribute to 0–1 by dividing by 10.**Final score computation**
Result scaled 0–1; map to priority tiers (>=0.8: High, 0.5–0.8: Medium, <0.5: Low).**Example**- Internet-facing DB (Exposure 9), stores PII (Sensitivity 9), critical (8), known CVE (Exploitability 8), high revenue impact (9):Compute gives high score → immediate testing.**Incorporating manual triage feedback**- Record triage outcome and reason codes (false-positive, out-of-scope, surprisingly critical).- Use simple supervised update: aggregate triage labels quarterly and adjust weights via gradient-free search (e.g., grid or Bayesian optimization) to maximize alignment between model priority and human-assigned priority.- Implement per-attribute calibration (e.g., if many high-exposure assets were deprioritized, reduce Exposure weight).- Log decisions and maintain audit trail; keep a human override flag and retrain only after thresholds of sample size and agreement.**Operational notes**- Integrate into reconnaissance pipeline (CSV/ELK), surface top N assets to testers, periodically review weights with stakeholders, and add signals like attack surface fuzzing or authentication complexity over time.
MediumTechnical
84 practiced
Explain how you would perform service and vulnerability fingerprinting by combining banner analysis, nmap NSE scripts, Shodan/Censys data, and active probes. Describe methods to validate tentative version detections and reduce false positives, and give an example where an apparent banner version was misleading.
Sample Answer
**Approach overview**I’d combine passive data (Shodan/Censys), banner analysis, targeted nmap NSE scripts, and bespoke active probes to build a confidence-weighted fingerprint for services and versions.**Step-by-step method**- Passive: query Shodan/Censys for host metadata (banners, certs, historical changes) to get candidate versions without touching the target.- Banner analysis: collect service banners (SMTP/FTP/HTTP/SSH) and associated headers/certs. Note inconsistencies (e.g., HTTP Server header vs X-Powered-By).- Nmap NSE: run service-specific NSEs (e.g., http-title, http-methods, ssl-enum-ciphers, ssh2-enum-algos) and version scan (-sV --script=vuln or specific scripts) to probe protocol features and known behavior.- Active probes: send protocol-correct but atypical requests (e.g., malformed HTTP verbs, TLS ClientHello variants, SSH kex negotiation) to observe responses, reset behavior, error messages, timing, cipher lists — many versions have distinct quirks.- Correlation & scoring: weight indicators (banner, cert SAN, cipher list, specific NSE fingerprint matches, Shodan historical data) to compute confidence and map to CVEs.**Validating tentative detections / reducing false positives**- Require >=2 independent indicators before flagging a version (e.g., banner + cipher set + NSE signature).- Use non-destructive, low-noise exploits (proof-of-concept safe checks) where applicable to confirm presence of a vulnerability.- Cross-check TLS cert validity, build dates, and server headers against Shodan history.- For web apps, compare fingerprinted framework behaviors (error pages, default endpoints, cookie names) rather than trusting X-Powered-By.- Document uncertainty and potential impact; classify as confirmed vs probable.**Misleading-banner example**I once saw an Apache 2.2 banner on an HTTP server, but ssl-enum-ciphers and response to HTTP/1.1 pipelining indicated Apache 2.4 behavior and the site supported TLS 1.3—features absent in 2.2. Shodan history showed a recent upgrade. Relying only on the banner would have led to false CVE matches for Apache 2.2-only issues; correlating multiple probes revealed the true version.
MediumTechnical
80 practiced
You discover an API that requires a bearer token provided after SPA login and you have a set of test credentials. Describe safe methods to map the API surface and parameter behaviors: using Burp Repeater, intercepting devtools traffic, creating authenticated crawlers, rate-limiting considerations, and ways to avoid exposing sensitive test data while performing thorough discovery.
Sample Answer
**Approach (brief)** I treat this as an authenticated API mapping task: capture a single valid session, enumerate endpoints and parameters safely, and record behaviors while protecting test creds and respecting rate limits.**Steps & Tools**- Burp Repeater / Proxy: intercept SPA login flow, capture bearer token header and refresh flow. Use Repeater to fuzz parameters and replay requests with the exact Authorization header to observe responses. Use Intruder sparingly and only against non-destructive endpoints.- DevTools interception: use Chrome devtools / network tab or puppeteer to see XHR/WebSocket sequences, storage keys (localStorage/sessionStorage), and token refresh timing. This helps build an authenticated session programmatically.- Authenticated crawler: build a headless crawler (puppeteer/playwright) that performs the SPA login using test creds, extracts tokens, and crawls linked API endpoints. Configure it to follow robots-of-engagement and only allowed paths.- Rate-limiting & safety: set conservative concurrency and request rates (e.g., 1–5 r/s), exponential backoff on 429, and limit attack surface to read-only enumeration first. Use non-destructive HTTP verbs and avoid state-changing operations unless explicitly in scope.- Protecting test data: store tokens/creds in encrypted vault (or ephemeral env vars); redact tokens and PII in logs and screenshots; rotate creds frequently and use short-lived tokens if possible; audit logs to ensure no sensitive artifacts left on test machines.- Automation tips: create session-handling rules in Burp to automatically inject fresh tokens; implement retry/backoff and jitter in crawlers; capture responses to a secured artefact store that masks Authorization headers.**Why this works** Combines manual inspection (Repeater, devtools) for nuance with automated crawling for breadth, while minimizing impact and protecting sensitive test data through encryption, redaction, rotation, and conservative rate limits.
Unlock Full Question Bank
Get access to hundreds of Reconnaissance and Information Gathering interview questions and detailed answers.
