Lateral Movement Inferred from Authentication Records

A domain authentication log is the closest thing to a network map that an investigation usually gets, because every successful authentication records not only who authenticated but, in most configurations, where the authentication came from and what service was requested. Reading that map correctly is a matter of knowing which fields the protocol derives and which the client supplies.

Lateral movement is the phase in which the intruder converts one compromised identity into many. It is also the phase with the highest density of recordable events, because it requires authentication to a service on another machine, and services record their own access. The difficulty is not a shortage of data; it is that the same records describe help-desk work, backup jobs, monitoring, and an intruder, and the differences are in the sequence rather than in any single event.

What each logon record actually contains

Windows records logons with a type that describes the mechanism, and the type determines which fields are meaningful.

A network logon (type 3) is recorded when a client authenticates to a service over the network: an SMB share, a remote registry, a service control operation. The record carries the source address and port of the client and the name of the service. This is the record that maps movement, because it is written on the target machine and therefore survives the compromise of the source.

An interactive logon (type 2) is recorded at the console or through a local session. Remote interactive (type 10) is recorded for a remote-desktop session. Batch (type 4) and service (type 5) logons are recorded when scheduled tasks and services start under stored credentials, the mechanism behind persistence that uses a service account, and the mechanism that makes a compromised service account persist silently for a long time.

The field that makes the network logon a map is the workstation name and address. Both are supplied by the client during the authentication exchange, and neither is validated against the network layer: a client can present an arbitrary workstation name, and the address recorded is the one the client connected from, which may be a hop, a proxy, or a NAT translation rather than the machine’s own address.

Kerberos adds a distinction that matters for detection. The ticket-granting service issues a ticket-granting ticket, and the client then requests service tickets for specific services on specific hosts. Each service ticket request names the target service principal, which encodes the host. The domain controller logs the request, so the record of “this identity asked for a ticket to that machine’s file service” exists centrally, independent of whether the target machine recorded the subsequent access. This is the property that makes service ticket requests the more reliable movement map in a Kerberos environment, and the reason a target host’s silence is not evidence that no access was attempted.

The three patterns that distinguish traversal

Single records are almost never conclusive. Sequences are.

Fan-out from one identity over a short interval. An account that authenticates to ten machines within a few minutes, each with a different service, is doing something that a human doing administration rarely does, since administrative work tends to repeat on the same small set of hosts, and monitoring tends to repeat on a schedule. The distinguishing feature is the set of distinct targets, not the count of logons: a scheduled job authenticating to the same ten hosts every hour has a high count and a stable set, while traversal has an expanding set.

Fan-in to one target from many identities. Many accounts authenticating to one host in a short window, each once, describes credential spraying or the use of a harvested credential list. The rate matters: authentication attempts against a domain controller are throttled by policy in most environments, so the pattern appears as a slow trickle over hours rather than a burst, and a rate-based rule with a short window misses it entirely.

Chains. A logon on host A whose recorded source is host B, where B’s own records show a logon from C at a slightly earlier time, forms a path. Reconstructing the path requires joining records across machines by identity and time, and the joins are exactly where clock skew corrupts the result: the ordering between “authenticated to B” and “authenticated from B to A” is often separated by seconds, which is within the combined uncertainty of two unsynchronized hosts.

-- Identities that authenticated to many distinct hosts from one source host
-- within a bounded interval; the HAVING clause is the fan-out test.
SELECT src_host, account, COUNT(DISTINCT dst_host) AS targets,
       MIN(ts) AS first_seen, MAX(ts) AS last_seen
FROM logon_events
WHERE logon_type = 3 AND success = 1
GROUP BY src_host, account, strftime('%Y-%m-%dT%H', ts)
HAVING COUNT(DISTINCT dst_host) >= 5
ORDER BY targets DESC;

The grouping by hour is a deliberate choice with a cost. It bounds the query’s state and makes the window cheap to compute, and it also splits a traversal that crosses an hour boundary into two rows that each fail the threshold. Sliding windows avoid that at the cost of state proportional to the event rate; the trade is the same one described in behavioral detection, where the window parameter determines both recall and cost.

Where the map lies

Four properties of the data systematically mislead.

Source address is not identity. Records written by a target name the address the connection came from. Behind NAT, several machines share one address, so fan-in from a single address may be many machines. Behind a jump host, every administrative action in the environment appears to originate from one address, which is why the jump host’s own logs must be joined to the analysis rather than treated as noise.

Workstation name is client-supplied. It is useful as a corroborating detail and useless as an identifier. A mismatch between the claimed workstation name and the address that resolves to that name is a signal, but only where reverse resolution is trustworthy, and in many environments it is not.

Service accounts hide in the type field. A logon of type 5 is expected for a service account and therefore rarely examined. An intruder who installs a service under a compromised account produces exactly that record, at a time when no service installation was authorised. The discriminating detail is the creation or modification of the service on the target, not the logon itself, which means the authentication log alone cannot answer the question and the host’s own process and file records must be joined to it.

Successful-only collection. Many environments log failures and successes to different destinations, with different retention. Fan-in detection depends on failures; movement reconstruction depends on successes. An environment that retains one and not the other supports one analysis and not the other, and the gap is not visible from either dataset alone, a point that generalizes to the retention reasoning in log destruction and forwarding gaps.

Reconstructing the path

The output worth producing is a directed graph: nodes are hosts and identities, edges are authentications with a time window and a service. Edges are added from the target’s records, which are the authoritative side. Identities that appear as both a source and a destination within the window are candidate pivots.

Pruning matters more than construction. A domain controller’s records contain every authentication in the environment, and a graph built from all of them is a complete graph with a temporal dimension and no signal. The useful reductions are: exclude machine accounts authenticating on their own schedule, exclude the monitoring and backup identities by name, exclude authentications to the domain controller itself, and exclude edges whose time window is wider than the interval between the two events being compared.

What remains after pruning is a small graph, and the remaining question is whether it is traversal or administration. The honest discriminator is not a threshold but a comparison against what the environment’s own records say should have happened: an authorised change ticket, a scheduled job’s documented target list, an administrator’s normal working set. Where those do not exist as data, the graph is a hypothesis about movement rather than a finding, and the containment decision described in network isolation has to be made on that weaker basis.