Digital Forensics — Filesystem Timelines and Memory Artifacts — DedSec Project

Purpose: Deepen forensic reasoning: preserve evidence, understand filesystem metadata, construct timelines, correlate volatile and persistent artifacts, and communicate uncertainty.

Learning objectives

• Distinguish acquisition, preservation, examination, analysis, and reporting.
• Understand common filesystem timestamp and metadata limitations.
• Build multi-source timelines with normalized time.
• Understand what memory can reveal that disk cannot and vice versa.
• Correlate identity, process, network, and persistence artifacts without overclaiming.

Forensics is reconstruction under uncertainty

A forensic conclusion is an inference from artifacts left by systems. Artifacts may be incomplete, overwritten, tampered with, time-skewed, or generated by normal software. Strong analysis records both supporting and contradicting evidence and distinguishes observed fact from hypothesis.

Evidence preservation

Before analysis, document source, collector, date/time/timezone, acquisition method, hashes, storage location, and access history appropriate to your organization. Work from copies when possible.

Do not collect more personal or confidential data than the investigation requires. Legal/HR/privacy requirements may constrain acquisition and retention.

Filesystem metadata

Filesystems store metadata such as names, paths, size, ownership, permissions, allocation information, and timestamps. Semantics vary by filesystem and OS. A single “modified time” cannot answer every question.

For NTFS, analysts may encounter multiple timestamp sources and metadata structures; for ext-family filesystems and mobile storage, semantics differ. Learn the specific filesystem rather than applying one universal timestamp model.

Timestamp caveats

Timestamps can change because of copying, extraction, backup/restore, software behavior, clock corrections, virtualization, or deliberate manipulation. Some timestamps have different precision or update rules.

Use timestamps as one evidence source and correlate with logs, process execution, network activity, package/application metadata, and user actions.

Timeline normalization

Pick a canonical analysis timezone, often UTC, while preserving original timezone/offset. Record clock skew where known. Distinguish event time, write time, collection time, and ingest time.

A useful timeline row includes: normalized time, source, host, user/principal, artifact type, action, object, confidence, and raw reference.

Super-timelines

A super-timeline merges many artifact sources: filesystem events, authentication logs, process telemetry, browser history, cloud audit, EDR, DNS, firewall, application logs, and memory artifacts.

The value is correlation. A process execution followed by a file write followed by a network connection is more informative than any one event alone.

Process execution artifacts

Different operating systems record execution in different ways. Potential sources include event logs, EDR, shell/application history, prefetch-like mechanisms, service/task metadata, package records, and memory remnants.

Do not assume absence from one source proves the process never ran.

Persistence review

For incident response, examine legitimate startup mechanisms: services, scheduled tasks, startup folders/registry, shell profiles, browser extensions, systemd units/timers, cron, launch mechanisms, cloud startup scripts, mobile app receivers, and management policies.

The objective is identify unexpected configuration and restore a known-good state, not to teach persistence creation.

Memory forensics concepts

Volatile memory can contain process lists, mapped modules, open handles, network endpoints, command-line fragments, decrypted application data, cryptographic material, kernel structures, and artifacts of recently exited activity depending on platform and timing.

Memory collection is highly sensitive. It can contain passwords, tokens, messages, keys, and personal data. Restrict access and retention.

Process-versus-module anomalies

Analysts compare expected process image, path, signer, loaded modules, memory mappings, thread start addresses, parent context, and executable permissions. An anomaly is a lead, not proof. Legitimate debuggers, JIT runtimes, security software, and updaters can create unusual patterns.

Network artifacts

Correlate active/recent connections with process identity, DNS resolution, firewall/proxy logs, TLS metadata, and cloud/VPN logs. NAT and proxies can complicate attribution.

A remote IP alone rarely proves which user/process initiated activity.

Browser and user artifacts

Browser history, downloads, cache, extensions, cookies, and local storage can provide context, but browser profiles contain personal/sensitive information. Scope searches narrowly and follow policy.

Downloads should be hashed and correlated with process execution rather than assumed malicious from filename alone.

Cloud and SaaS forensics

Cloud audit logs may show role assumption, object access, policy changes, login events, OAuth grants, mailbox rules, file shares, and device/session information. Retention and licensing can limit history.

Preserve critical cloud logs early because some sources have short retention windows.

Hypothesis-driven investigation

Instead of “look at everything,” write hypotheses:

• Did account A authenticate from a new context?
• Did process P create persistence?
• Did data object D leave the environment?
• Did role R gain unexpected authority?
• Did security control C stop reporting before or after event E?

For each, list evidence that would support, weaken, or falsify it.

Root cause versus patient zero

The first observed alert is not necessarily the initial compromise or root cause. Work backward and forward from strong anchor events. Track gaps explicitly.

Avoid forcing a complete narrative when data cannot support one.

Safe timeline lab

Generate synthetic activity on a disposable VM: log in, create a file, run a benign script, start/stop a test service, make a localhost request, and delete a temporary file. Collect available logs and filesystem metadata. Build a 10–20 event timeline and identify which actions are visible in which sources.

Forensic report structure

• scope and authority;
• systems/accounts examined;
• acquisition details and hashes;
• time normalization and known skew;
• executive findings;
• detailed timeline;
• evidence per finding;
• confidence level;
• alternate explanations considered;
• containment/remediation;
• evidence retention/cleanup.

Guided study workflow

Before you begin

Complete Modules 23, 37, 47, 72–80.

Practice task

Build a multi-source timeline from your synthetic lab activity. Deliberately omit one source, explain the resulting blind spot, then add it and update the conclusion.

Evidence to keep

Timeline CSV/Markdown, source inventory, hashes where appropriate, timezone notes, and uncertainty annotations.

Common mistakes to avoid

• treating one timestamp as definitive;
• collecting unrelated personal data;
• assuming missing telemetry means no activity;
• using mismatched timezones;
• presenting hypotheses as facts.

Mastery check

Given three conflicting artifacts, explain how you would rank them, normalize time, and state a defensible conclusion with uncertainty.

Continue with

Modules 82, 83, 84, and 85.