What evidence may show internal reconnaissance?¶
You will rarely get the whole reconnaissance story from one log.
More often, one source shows the command, another shows which host answered, another shows which account was queried, and a saved output file shows what the session actually learned.
The job is to join those views together.
Think in terms of observation points¶
Suppose a Windows workstation runs a command looking for other systems on the network.
At roughly the same time:
- the endpoint records the process and command;
- the firewall records connections to several internal addresses;
- directory records show account queries;
- and a text file contains the returned hostnames.
The useful picture comes from matching the device, account, session, process, time and returned results across those sources.
You do not need every source in every case. Use what the environment actually records.
What can each source give you?¶
| Source | Useful material |
|---|---|
| Endpoint / EDR | Process, parent process, command line, account and time |
| Shell or PowerShell history | Commands and their order |
| Directory / identity logs | Accounts, groups, roles or objects queried |
| Firewall / network logs | Internal systems and services contacted |
| Remote-access logs | The session or route controlling the machine |
| Saved output | The names, addresses, shares or accounts returned |
| Security alerts | A quick route into the underlying events |
The more specific discovery topics sit alongside this one: system discovery, network discovery, account discovery, service discovery, permission and group discovery, security-software discovery and file and directory discovery.
Do not overlook the output¶
The command tells you what somebody asked.
The output tells you what they got back.
That can be much more useful.
Imagine you find a saved file containing:
FIN-SRV-02
FIN-SRV-04
BACKUP-SRV
\FIN-SRV-04\Finance
svc-backup
Those values are now excellent pivots.
Search later authentication records for svc-backup. Look for connections to FIN-SRV-04. Check whether the Finance share was opened or copied.
This is often how reconnaissance becomes useful to the wider incident investigation: the results give you names and identifiers to follow forward.
A practical way to reconstruct it¶
Work through it in this order:
- Identify the source device, account and session.
- Collect the discovery commands or queries.
- Keep the returned output if it exists.
- Match endpoint, identity, network and remote-access records by time and identifiers.
- Put the activity in order.
- Reuse the discovered hostnames, accounts, IP addresses and paths when searching later records.
- Mark any genuine gaps rather than filling them with assumptions.
Failed commands and retries are worth keeping too. They may explain why the next query changed.
Once the sequence is visible, compare it with what administrators, monitoring tools or deployment systems normally do in that environment. Legitimate administration can look like reconnaissance, so context matters.
From there, two questions usually follow naturally:
- Did anything happen after the reconnaissance?
- What does the order of the discovery activity tell us?
The useful mindset is: do not hunt for one perfect log. Build the picture from the places that could see different parts of the same activity.
