Planning an Investigation

Learning Objectives

• Fill out a scope sheet and intelligence requirements before starting any investigation
• Build a collection plan and source checklist that map requirements to sources
• Keep a pivot log, parking lot, and time budget during an investigation
• Follow a complete, realistic recon investigation from question to findings
• Reuse these templates for the labs in this module

How to Use This File

The first half is a set of copy-and-paste templates. The second half is a complete walkthrough showing the templates filled in for a fictional company. Students should copy the templates into their own notes at the start of every lab.

All data in the walkthrough is fictional. IP addresses use the ranges reserved for documentation (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24), so they don’t point at anyone’s real systems.

Part 1: Templates

Template A: Scope Sheet

## Scope Sheet
- **Investigation name:**
- **Requester / client:**
- **Authorization:** (document name, date, who signed)
- **Decision this supports:**
- **Targets in scope:** (organizations, domains, IP ranges, named roles)
- **Explicitly out of scope:** (personal accounts, family members, home addresses, third-party providers, other orgs with similar names)
- **Allowed methods:** [ ] Passive  [ ] Semi-passive  [ ] Active (list techniques)  [ ] Social engineering
- **Prohibited actions:** (e.g., logging in, contacting staff, downloading breach data)
- **OPSEC level:** Low / Medium / High, and why
- **Data handling:** (where notes are stored, who can see them, when they're deleted)
- **Total time budget:**
- **Deadline:**
- **Point of contact for scope questions:**

Template B: Intelligence Requirements

## Intelligence Requirements
| ID | Question | Why it matters (decision) | Done when... | Time box |
|----|----------|---------------------------|--------------|----------|
| R1 |          |                           |              |          |
| R2 |          |                           |              |          |
| R3 |          |                           |              |          |

Tips:
- Write each requirement as a question with a clear answer.
- “Done when” is your stopping rule (e.g., “confirmed by 3 independent examples”).
- 3–6 requirements is plenty for a class lab.

Template C: Collection Plan

## Collection Plan
| Req | Source type | Specific source / query | Passive? | Status | Notes |
|-----|-------------|-------------------------|----------|--------|-------|
| R1  |             |                         |          | Not started / Done / No results | |

Template D: Source Checklist

Tick each source category as you consider it, even if you decide to skip it. (Details for each category are in Module 5 OSINT Sources.)

## Source Checklist
- [ ] Search engines (multiple engines, advanced operators)
- [ ] Organization's own website and documents
- [ ] Terms of service / privacy policy (what's allowed, what's hinted at)
- [ ] Job postings
- [ ] Professional networking and social media (organization-level)
- [ ] Code repositories
- [ ] Domain registration (WHOIS/RDAP)
- [ ] DNS records and passive DNS
- [ ] Certificate Transparency logs
- [ ] Internet scan search engines
- [ ] Web archives
- [ ] Public records and business filings
- [ ] News and press releases
- [ ] Breach notification services (authorized domains only)
- [ ] Images / geospatial (office locations)
- [ ] Other: ______

Template E: Pivot Log

## Pivot Log
| # | From | Method / source / query | To | Confidence | In scope? | Time (UTC) | Evidence file |
|---|------|-------------------------|----|------------|-----------|------------|---------------|
| 1 |      |                         |    |            |           |            |               |

Confidence values: Confirmed / Likely / Possible / Unverified.

Template F: Parking Lot

## Parking Lot (interesting, but not answering a requirement right now)
| # | Lead | Why it might matter | Scope concern? | Decision (pursue / drop / ask client) |
|---|------|---------------------|----------------|---------------------------------------|

Template G: Time Budget Tracker

## Time Budget
| Req | Budget | Used | Status | Reassess note |
|-----|--------|------|--------|---------------|
| R1  | 45 min |      |        |               |
| Total | 4 h  |      |        |               |

Template H: Findings Summary

## Findings
| Req | Finding | Confidence | Supporting pivots | Gaps / next steps |
|-----|---------|------------|-------------------|-------------------|

The full report format belongs to Module 7 Verification & Reporting. The findings table is the bridge between your working notes and that report.

Part 2: Walkthrough — External Exposure Review of Company X

Background (fictional)

Company X is a 200-person regional logistics company. Its domain is companyx.com. Its IT director has hired your team for an external exposure review: find out what an attacker could learn about the company from public sources before a planned authorized phishing simulation and external penetration test next month.

Step 1: Scope Sheet (filled in)

## Scope Sheet
- **Investigation name:** Company X External Exposure Review
- **Requester / client:** IT Director, Company X
- **Authorization:** Signed statement of work + rules of engagement, dated (fictional)
- **Decision this supports:** Design of next month's phishing simulation and external pentest; exposure-reduction recommendations
- **Targets in scope:** Company X (the legal entity), companyx.com and its subdomains, IP range 198.51.100.0/24 (confirmed by client), employees' professional presence
- **Explicitly out of scope:** employees' personal social media, family members, home addresses, third-party SaaS providers' systems, "Company X Holdings" (unrelated company with a similar name)
- **Allowed methods:** [x] Passive  [x] Semi-passive  [ ] Active  [ ] Social engineering (next month, separate RoE)
- **Prohibited actions:** logging into anything, contacting staff, downloading breach data, using any credentials found
- **OPSEC level:** Low-medium (client knows; IT staff don't, to keep the simulation realistic)
- **Data handling:** encrypted team folder; deleted 30 days after report delivery
- **Total time budget:** 6 hours
- **Point of contact for scope questions:** IT Director

Notice the “similar name” exclusion. Mixing up organizations is one of the most common OSINT errors.

Step 2: Intelligence Requirements

That’s 5.25 hours, leaving 45 minutes for processing and writing findings.

Step 3: Collection Plan (excerpt)

Step 4: Collection and Pivot Log (excerpt)

Step 5: Parking Lot

Step 6: Processing

• Merged subdomains from CT logs and passive DNS: 14 + 5 → 16 unique
• Normalized employee titles into departments
• Redacted the API key in the evidence screenshot and noted it was not tested or used
• Tagged every item with its requirement

Step 7: Analysis — Findings

Analytic judgments (what it means for the decision):
- Phishing pretexts using an e-signature request or project-tracking notification would look realistic, because both services are confirmed in use.
- The exposed API key is the highest-priority finding and should be reported to the client immediately, not held until the final report.
- The remote desktop exposure and dev-portal ownership need confirmation before next month’s active testing.

Step 8: Dissemination

• Immediate notice to the IT Director about the exposed API key (same day)
• Report following the structure in Module 7: executive summary, scope and method, findings with confidence, risk, recommendations
• Handling: employee names summarized as counts by department in the main report; full list in a restricted appendix only because the phishing simulation needs it

Step 9: Feedback

The IT Director confirms dev-portal is a legitimate cloud host they own and adds it to next month’s scope. They ask a new question: “Are any of our IT staff credentials in breach data?” This becomes a new requirement (R6) with its own authorization check and data handling rules (see Module 2 and Module 6).

Time Budget (final)

Lessons from the Walkthrough

• Scope decisions happen all the time, not just at the start (pivots 7 and 13, parking lot P1–P3).
• Similar names are a trap; write exclusions into the scope sheet.
• Some findings can’t wait for the final report.
• Found credentials are reported, never used.
• Stale data is labeled as such and handed to active testing for confirmation.
• Minimize personal data in deliverables: counts instead of names where possible.

Key Terms

• Scope sheet: a one-page summary of what’s authorized, what’s excluded, and how data is handled
• Statement of work (SOW): the contract document describing the engagement
• Rules of engagement (RoE): the specific rules for what testers may do and when
• External exposure review: an assessment of what an organization reveals to the internet
• Documentation IP ranges: address blocks reserved for examples (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24)
• Analytic judgment: a conclusion about what findings mean for the decision

Key Takeaways

• Fill out a scope sheet before you open a browser
• Every requirement needs a “done when” stopping rule and a time box
• Map each requirement to sources in a collection plan
• Log every pivot with confidence and a scope decision
• Park interesting-but-off-target leads instead of chasing them
• Critical findings (like exposed keys) get reported right away
• Findings tables bridge working notes and the final report

References

• Reconnaissance, Tactic TA0043 — MITRE ATT&CK (for mapping walkthrough activities)
• RFC 5737: IPv4 Address Blocks Reserved for Documentation — RFC Editor