CEH · M02

Reconnaissance notes: separate observation from inference

Information gathering is useful when it improves the next question. Record source, time and confidence to turn scattered clues into testable hypotheses.

After this lesson, you can
  • Distinguish direct target interaction from reading existing material.
  • Write a bounded finding from a DNS clue.

Prerequisites: Ethical hacking starts with authorization, scope and stop conditions

Decide what you need to know

Reconnaissance builds an initial picture of assets, services and relationships. A question can be narrow: which service did this name point to, and when was that recorded? The answer should reduce uncertainty, not justify collecting every available personal detail.

Reading a supplied dataset does not directly contact the target; sending requests to its service does. A method called passive may still create query records at a third party. Record the actual source and action rather than relying only on an active or passive label.

Further reading: NIST SP 800-115: Security Testing and Assessment

Name resolution is not ownership evidence

DNS distributes resource records through a naming system. A and AAAA records provide addresses; CNAME provides an alias relationship. These answers support name resolution, but do not independently establish administration, software version or testing permission. Shared hosting makes it especially easy to confuse the same address with the same asset.

A useful note separates observation, inference and next check. Time matters because an earlier resolution may not represent the current configuration. The next check still needs to fit the authorization established in M01.

Further reading: RFC 1034: Domain names, concepts and facilities

Example: two names share an address

A supplied synthetic list says docs.example.test and shop.example.test both pointed to 192.0.2.10 at 09:00.

You can observe a shared address at that time and hypothesize shared hosting or a front end. You cannot infer the same backend, administrator or permission to test the shop from authorization for the documentation site.

Conclusion: Check the hypothesis against the asset inventory and authorizer before testing the additional name.

Tabletop exercise: a three-column evidence card

Use only the synthetic DNS records in this lesson; do not query real domains.

  1. Record both names, 192.0.2.10 and 09:00 under Observation.
  2. Under Inference, write a possible explanation and one counterexample.
  3. Under Next check, name the role that must confirm ownership and scope.

Expected result

A counterexample is different customers sharing a CDN or reverse-proxy address. The next action is scope verification, not an immediate scan.

Check your work

What evidence is missing if “may share a front end” becomes “proven to share a backend”?

Finish and clean up

Save the synthetic evidence card. No network or system cleanup is needed.

Q&A · Check your reasoning

Choose an answer and confidence, then read every explanation. Answers stay in this browser.

ceh-m02-evidence-q1 · Original practice

Two names resolve to the same IP. What follows directly?

Two names resolve to the same IP. What follows directly?
ceh-m02-evidence-q2 · Original practice

Which note is easiest to verify later?

Which note is easiest to verify later?
ceh-m02-evidence-q3 · Original practice

Does a CNAME alias automatically extend test scope?

Does a CNAME alias automatically extend test scope?

Connect the next idea

Terms: Evidence boundary·DNS·Scope

Sources & scope

These sources support the technical principles. Examples, questions and exercises are original to this series.