Logs Exist But Are Not Centralized

Logging is enabled — sometimes correctly configured — but every machine keeps its logs locally: no copy ever leaves the device that produced it.

This is structural: local logging is the default behavior of any system; centralization is a project — collector, storage, source triage — that has no owner and no urgency until an incident demands it. The pattern is distinct from retention that is too short (see MFL-002): here the duration may be correct, it is the location that is at fault. The log lives on the machine whose story it tells, and shares its fate: encrypted, wiped, or rebuilt, the machine takes its testimony with it.

Three distinct, cumulative mechanisms:

• destruction by the incident itself: encrypting a machine takes its logs down with it; wiping local logs is a standard attacker action before leaving a machine. In both cases, the machines most valuable to the investigation are exactly the ones with nothing left;
• collection cost during the investigation: reconstructing a timeline requires connecting machine by machine, across a suspect fleet, sometimes through access that is itself compromised — days of work for what a centralized search resolves in minutes, and those days come at the expense of containment;
• no correlation possible, before or during: lateral movement is by nature a cross-machine pattern. In logs that never meet, it is structurally invisible — each machine sees only an isolated, innocuous event.

Thirty-minute test: pick a routine, recent event — a remote connection from yesterday, a privilege elevation — and try to find it without connecting to the machine in question. If the answer involves “you’d have to check on the machine,” the pattern is present.

Then take inventory, by category:

• workstations, servers, directory and authentication servers, network equipment, exposed applications, backup platform: which ones send to a collection point, which ones keep everything local?
• uncollected central authentication servers and remote access points are the most costly gaps during an incident — start verification with them;
• for sources already “collected”: verify they are still sending. Sources that silently stop sending after an update or an address change are the classic failure mode of aging collection pipelines.

Centralize by decreasing investigative value, not by exhaustiveness:

• first authentication (directory servers, identity provider), remote access, exposed servers; then workstation execution events if volume allows;
• a simple, complete collection beats a sophisticated analysis platform that only receives a tenth of the sources — analysis tooling can come later, lost logs never come back;
• place the centralized copy out of reach of production identities — same logic as for backups (see MFL-003): a log the attacker can purge centrally is no better than a local log, it’s just more convenient to destroy;
• monitor completeness: an alert when a source stops sending, a periodic review of coverage rate by category.

Preservation comes before analysis:

• copy the local logs of still-intact machines now, starting with authentication servers, access gateways, and machines in the suspect perimeter — before any remediation that reboots, reinstalls, or “cleans” a machine;
• copy the log files themselves, in their original format — not excerpts or screenshots: the investigation will need to query, correlate, and prove;
• for machines already lost, look for indirect witnesses: logs from equipment that saw the machine (network equipment, central authentication, applications it connected to), recent backups that contain its logs as of the backup time;
• set up a minimal central collection during the incident for the suspect perimeter: a few hours of effort, and the rest of the investigation stops losing what is still happening.