Data forensics

Reconstruct the record around what happened.

AuditTrace Labs reviews authorized digital artifacts with emphasis on evidence integrity, chronology, provenance, and the system state that gives those artifacts meaning.

An artifact on its own is a fragment. A file, a log line, a capture, or a configuration each describes one narrow slice of a system at one moment. The work is establishing what each can support, how they relate, and where they stop.

The output is a record another person can follow: what was examined, under what conditions, what it showed, and what it did not.

What review attends to

  • Evidence integrity and acquisition context
  • Chronology across independent sources
  • Provenance — where an artifact came from
  • The surrounding system state
  • Relationships between artifacts
  • Documented limitations and gaps

Work proceeds on authorized systems and evidence, within an agreed scope.

Evidence sources

Different sources answer different questions.

Each source carries a characteristic strength and a characteristic blind spot. Knowing both keeps a conclusion honest.

Storage and media

Disks, volumes, images, and removable media show persistence: what was written, what survived, and what the filesystem recorded — content, allocation, remnants of removed data, timestamps.

Does not show intent, who was present, or activity that existed only in memory.

Logs and event context

A log shows that a system recorded an event — an authentication, a service start, a policy change — in its own clock and format. Independent logs describing one moment are stronger than any single one.

Does not show what was never recorded. Rotation and retention decide what remains; a missing entry is not proof of a missing event.

Network and packet evidence

A capture shows observed behavior during the capture window: endpoints, protocols, sequence, timing, volume, and sometimes content.

Does not describe behavior outside the window. Encryption limits content, and traffic alone does not identify the process behind it.

System and application configuration

Configuration shows intended behavior: what a system was set up to permit, deny, route, log, or retain. Against a known earlier state, it also shows drift.

Does not establish that a setting was in force at the moment in question unless a change record ties it to that time.

Digital records and device artifacts

Documents, messages, exports, account records, and the traces a device leaves while in use can show that a record existed in a particular form at a particular time.

Does not by itself establish authorship, or that a copy is faithful to an original no longer available for comparison.

Relationships

One artifact answers one question.

A single artifact is the easiest thing to over-read.

Taken alone, one source will be asked to settle questions it was never able to settle. The weight a finding can carry comes from how independent sources constrain each other — agreeing, narrowing, or refusing to line up.

Relating them is the work. Do independent sources agree on sequence and time once clock offsets are accounted for? Does the configuration explain the observed traffic, or contradict it? A disagreement between sources is not automatically an error — it is a question that is either resolved or recorded as unresolved.

Where the surrounding state can be reconstructed, those relationships are easier to establish. System-state preservation exists to make that reconstruction more likely.

Context integrity

A conclusion is only as sound as the information beneath it.

The information a finding depends on is examined on its own terms: whether it can carry the weight placed on it.

Information can be genuine and still be the wrong basis for a conclusion — accurate but stale, complete but unattributable, or inconsistent in a way nobody has explained. Where a criterion is not met, that becomes part of the record rather than an assumption inside it.

Four questions asked of the information

  • Available — is it actually present, rather than assumed
  • Current — is it current for the question being asked, not merely recent
  • Traceable — can it be traced to an origin, not to a copy of unknown descent
  • Coherent — is it free of unexplained contradictions and unexplained gaps

A gap that has been explained is workable. A gap nobody has noticed is the dangerous one.

Evidence integrity

A checksum is one line in a longer record.

Evidence integrity is built from several independent inputs. Each contributes something the others cannot, and none of them substitutes for the rest.

Be precise about what a hash does. A checksum can help show that a file did not change between two points at which it was measured. It does not establish where the file came from, what it meant, or what the system was doing at the time. Provenance, meaning, and history come from the record around the artifact, not from the value itself.

Integrity is therefore an accumulated record rather than a single test.

What contributes to integrity

  • Hashes, with the point of measurement recorded
  • Timestamps, and the clock source behind them
  • Manifests of what a set of evidence contains
  • Acquisition context: method and conditions
  • Configuration and surrounding system state
  • Comparison records between two known states
  • Limitations, documented at the time
Inside a finding

Four things a reviewable record keeps apart.

A technical finding is most easily challenged at the seam between what was observed and what was inferred from it. A reviewable record keeps that seam visible rather than smoothing it over.

Observed fact

What the evidence directly shows, stated so a reviewer can return to the same artifact and see the same thing.

Derived conclusion

What a person concluded from those facts, with the reasoning attached so it can be tested or disagreed with.

Uncertainty

Where more than one explanation still fits, and what would be needed to separate them.

Missing evidence

What was expected and not found, what was never collected, and what is no longer available to examine.

  • Observed
  • Derived
  • Uncertain
  • Missing
Documented limitations

Stating the limits is part of doing the work.

A finding that describes its own boundaries is more useful than one that does not: a later reader can tell how far it reaches. Limitations are recorded while the work happens, not reconstructed from memory.

Long-horizon reviewability is a design goal of how we record work — that a finding still makes sense to a reviewer well after the event, where the available source evidence and chosen retention scope support it. Evidence that was never captured, or that no longer exists, is not recreated.

What gets written down

  • What was in scope, and what was deliberately outside it
  • Acquisition conditions, including anything that constrained them
  • Evidence sought and unavailable
  • Sources that disagree, and whether the disagreement was resolved
  • Questions the available evidence cannot settle

What this is not

This page describes method, not outcome. It is not a promise that evidence can be recovered, that an event can be reconstructed, that a matter can be accepted, or that any finding will be treated as admissible by a court, regulator, insurer, or other party. Those determinations are not ours to make.

Bring us the artifacts and the question behind them.

Scope and authorization are agreed before any examination begins. The first message is deliberately brief — please do not send credentials or evidence through it.