What can the sequence of discovery activity tell an investigator?¶

The order of discovery activity can tell you how somebody learned their way around the environment and what caught their attention next.

One command finds the computer name. Another finds an account. A network query turns up another server. A minute later that server is being examined in more detail. Read together, those events can show the activity narrowing from “what is around me?” to “this is the thing I want to look at next”.

Read the timeline as a developing picture¶

Consider this sequence from one workstation:

The underlying concepts are covered separately in system discovery, account discovery, network discovery and service discovery. This page is about the extra meaning created by their order.

Results can connect the events¶

A sequence becomes especially useful when a result reappears later.

If 10.24.8.17 is first seen in network-discovery output and then appears as the target of a service query one minute later, there is a direct relationship to examine. If svc-backup is discovered and later appears in an authentication attempt, that creates another bridge into the incident timeline.

Useful linking details include:

• hostnames and IP addresses;
• account and group names;
• file paths and share names;
• process and parent-process identifiers;
• session identifiers;
• exact timestamps; and
• command output reused in later activity.

These repeated values are often more informative than simply saying several “discovery commands” occurred.

Timing can show how the activity was performed¶

Interactive activity often develops at an uneven pace because a person waits for output, reads it and decides what to do next. A failed command may be corrected. A newly discovered hostname may be typed into the next command.

Automation often produces more regular timing and repeated syntax because the target list and commands were already defined.

These patterns help describe how the discovery developed. Could legitimate administration look like reconnaissance? provides the separate comparison with authorised administrative activity.

Before joining the dots, make sure they really belong together¶

Before treating several records as one sequence, join them using the strongest available relationships:

1. Time: normalise time zones and account for known clock differences.
2. Device: establish which system generated each event.
3. Account and session: identify whether the same authenticated context continues.
4. Process chain: connect parent and child processes where endpoint records allow it.
5. Results: look for hostnames, accounts, addresses or paths carried from one event into the next.
6. Remote control route: where relevant, connect the local activity to the same remote-access session.

If those links break, the timeline should show the break. Several administrators or automated systems can operate at the same time, so proximity alone is not enough to make one sequence.

Use the sequence to choose the next evidence¶

A good discovery timeline should give you somewhere useful to go next.

If the sequence ends with a particular server, search the network, authentication and server records for later activity involving that server. If it ends with a privileged account, follow that account through the authentication records. If it ends with a share or file path, look for later file access or collection.

Does reconnaissance prove the next stage of an attack occurred? explains how to follow those discovered targets into later evidence. If the sequence progresses into another system, lateral movement explains the source-to-target transition that must then be reconstructed.

The point to remember¶

The useful bit is not simply that several discovery commands ran. Look for values that carry forward from one event to the next. A hostname, account, address or path that appears in one result and then becomes the next target can show you how the activity developed and where to look for the next evidence.