Throughout this module, we have gathered DNS records, exposed subdomains, search engine dorks, leaked credentials, and employee profiles. However, disjointed data has no tactical value. This final synthesis lesson teaches you to correlate disparate OSINT pieces into a cohesive Attack Surface Map and produce a professional External Assessment Report. This bridges passive recon to the active exploitation phase.
Intelligence is validated information. Data is just raw text. The equation is: Data + Context (Who, What, When) + Correlation (How items connect) = Actionable Intelligence. A .env file found on GitHub is data. Linking it to the current production IP from SecurityTrails makes it actionable.
Maltego is the industry standard for link analysis. It ingests data from transforms and displays the relationships visually. You begin with a Domain entity. Running 'To DNS Name [SecurityTrails]' expands to subdomains. Running 'To IP Address' resolves them. Then you run 'To Social Media Profile' to connect infrastructure to humans. The power lies in seeing the one developer who links the staging server, the GitHub leak, and the corporate Twitter.
Let's correlate a multi-source scenario. DNSDumpster reveals 'dev.example.com' pointing to 5.6.7.8. Shodan shows port 22, 8080 open on that IP with a Jenkins header. Google Dork finds an index of '/jenkins/workspace' with directory listing enabled. SOCMINT identifies a software engineer who posts about 'Jenkins pipelines' for 'dev.example.com'. The correlation is complete: an exposed Jenkins instance with likely build artifacts.
💡 The 'So What?' Test: Every entry in your report must pass the 'So What?' test. 'Found subdomain dev.example.com.' So what? Versus: 'Found subdomain dev.example.com hosting an unauthenticated Jenkins instance, likely granting access to source code and deployment keys, rated Critical.'
A passive recon report is divided into two audiences. The Executive Summary highlights business risk: 'We successfully mapped 45 external assets and identified 3 critical data leaks that could simulate a data breach...' The Technical Findings section details each vulnerability with Evidence (screenshot of the Google dork), Impact (Exposure of API keys), and Remediation ('Remove .env from public GitHub repos and rotate keys').
| Asset Type | Description | Discovery Method | Risk Rating |
|---|---|---|---|
| Subdomain | dev.example.com | crt.sh / DNSDumpster | Critical |
| Leaked File | .env (DB Credentials) | Google Dork | Critical |
| Employee | J. Doe - Admin/DevOps | LinkedIn / X | Medium |
⚠️ Do not include raw unredacted passwords in the final report appendix unless the secure delivery method (PGP encrypted PDF) is confirmed. Reports are often forwarded across insecure email chains. Mask secrets as 'DB_PASS=redacted' and deliver raw keys only to the designated security contact.
The final step of the passive phase is packaging the data for the active team. Export the Maltego graph as a CSV seed file for vulnerability scanners. Map the discovered IPs and URLs into a prioritized list: 'Targets with open sensitive ports' at the top. This ensures that when the ethical hacker flips the switch to active scanning, they aren't wasting time on out-of-scope or hardened assets, but hitting the weakest links you just uncovered.
Verify exercises to earn ★ 250 XP and unlock next lab level.