# How a Time Machine restore splits an audit trail A Time Machine restore can split an audit history even when every surviving record passes cryptographic verification. That result surprises teams because they expect a hash chain to produce one authoritative story. A chain proves continuity from a prior record. It cannot prove that a Mac never returned to that prior record and continued along a different path. The mistake is calling one continuation fake as soon as investigators find two of them. A routine recovery can create this shape without deceit. The evidence job is to preserve both lines, describe where they share history, and state what each line can and cannot establish. If you flatten them into one neat chronology, you create the first untrustworthy record in the case. ## A restore can create two honest continuations A restored Mac creates a fork when the restore includes an older copy of the audit store and the application later writes new events from that restored state. Consider a log whose records link their hashes in sequence. At record 500, the store has head hash H500. Time Machine captures that state. The Mac continues operating and writes records 501 through 580, each linked to the record before it. Later, someone restores the Mac to the backup that ended at record 500. The restored application sees H500 as its current head and writes a new record 501. That new record links correctly to H500. It simply has different contents, a different hash, and perhaps a different timestamp than the record 501 that the original Mac wrote before the restore. The result has one shared prefix and two descendants: ```text records 1 through 500 | +-- lineage-original: 501 through 580 | +-- lineage-restored: 501 through 544 ``` Each descendant can pass a normal chain check. The verifier asks whether each record links to the predecessor supplied in that sequence. It does not possess a universal memory of every continuation that could have started from H500. That is not a flaw in hashing. It is the expected result when a system restores mutable state. The fork can occur at a clean shutdown, after a crash, or during an urgent recovery. A technician does not need to manipulate the audit database. Restoring the whole system, restoring an application-data folder, or replacing a volume with a backup can all return an older log head. The details depend on what the backup captured and what the recovery put back. Do not confuse a copy with a fork. If the restored Mac never records another event, you have an older copy of one history. You have a fork only when two distinct successors claim the same predecessor. That distinction affects every later conclusion. ## Validity inside a branch is not a global timeline A hash-chain check answers a narrow question: did this record follow this preceding record in this supplied sequence? It does not answer whether another valid record also followed the same preceding record somewhere else. Investigators often overstate the first answer as if it settled the second. A useful way to separate the claims is to keep four terms apart: - Integrity means the records in one collected sequence still link as expected. - Continuity means the sequence has no unexplained gap within the material you hold. - Completeness means you have every event that occurred in the relevant scope. - Exclusivity means no other continuation exists from the same point. A local audit trail can offer strong integrity and still offer neither completeness nor exclusivity after a restore. Getting this wrong leads to a damaging report sentence: the log proves no approval occurred. The log may only prove that no approval appears in the restored continuation. Time itself makes the confusion worse. Wall-clock timestamps can overlap. The original Mac may record an action at 14:03, then the restored Mac may set its clock from the network and record a different action at 14:02 while it continues from an older sequence head. A timestamp sort can interleave events from branches into an appealing but false order. Sequence numbers also need context. Both descendants may contain record 501. Do not rename one record 501A in the raw evidence, and do not decide that the higher sequence number wins. Keep original fields untouched and add lineage information in your working notes. NIST Special Publication 800-92, Guide to Computer Security Log Management, treats synchronized time and protected log handling as operational requirements. That guidance remains sound, but synchronized clocks do not solve restored state. Clock discipline helps compare sources. It cannot tell a verifier which of two later records was the sole successor to an earlier record. ## Call the fork point what it is Use a precise label before discussing motive. I use fork point for the last record shared by both continuations. I use lineage for one continuous chain beginning at that point. I reserve branch for the relationship between lineages, not as a casual synonym for a copied file. Give each lineage a stable case identifier. The names must describe origin, not credibility. For example, use lineage-original for the sequence recovered from a device image or an export that predates the restore, and lineage-restored for the sequence the recovered Mac wrote afterward. If the origin remains uncertain, use lineage-A and lineage-B until evidence supports a more specific name. A preservation note can be small and still prevent weeks of confusion: ```yaml case: IR-2026-041 fork_record: 000500 shared_head_hash: H500-value-recorded-verbatim lineage-original: source: external-export-collected-from-operator first-divergent-record: 000501 collection-copy-sha256: recorded-separately lineage-restored: source: restored-mac-audit-store first-divergent-record: 000501 collection-copy-sha256: recorded-separately ``` Do not put conclusions such as legitimate, compromised, or trusted into these labels. Those words invite the team to decide before it has examined the surrounding evidence. The label should let another investigator pick up the material six months later and know exactly which sequence a statement refers to. Also record the restore boundary as a range when the evidence only supports a range. A Time Machine snapshot date tells you when the backup captured data. It does not automatically tell you when the actual restore ran, when the Mac first booted afterward, or when the application resumed writing. Those may require backup metadata, system records, administrator notes, and corroborating service logs. ## Preserve the machine before it extends the restored branch A restored machine can change the evidence as soon as it starts the application that owns the audit store. It may write a launch event, rotate a file, update an index, or contact a time service. The first handling decision therefore matters more than a clever parser later. First, stop ordinary use and record the Mac's visible condition. Photograph the screen if it is already running, note the displayed time and network state, and record who had physical control. Then isolate it from networks in a way that fits your incident procedure. Do not reboot merely because you prefer a clean collection. A reboot can replace volatile context and trigger more writes. Next, preserve distinct sources separately. That means the restored volume, the relevant Time Machine backup set, any export from before the restore, and copies held by services that received the audited actions. Calculate a cryptographic hash of every collected file or image and keep the original read-only whenever your tooling allows it. Work from copies. The phrase preserve both timelines has a practical meaning. It does not mean copying a rendered activity screen into a report. Preserve the native audit data, the verifier program and version, the backup metadata that places an older state on the Mac, and the collection notes that establish how each item reached you. If you find only the restored continuation, say so. Do not draw the original continuation from imagination. You can still identify a possible fork if a backup snapshot contains the shared head and other sources show activity that the restored history cannot account for. You cannot, however, reconstruct the missing records by extrapolating hashes. A hash chain detects a supplied relationship; it does not recover absent content. A time-sensitive incident may force a team to recover service quickly. Split operational recovery from evidence preservation. Make a preserved copy first when you can, record the point at which that was impossible when you cannot, and document every action that may have written to the live system. An honest limitation is far less damaging than a polished chronology built after the fact. ## Build an evidence map before sorting events Investigators need an evidence map before they make a timeline. Start with sources, not events. Each source has a collection date, an owner, a relevant date range, a native format, a cryptographic digest, and a relationship to one lineage or to both. The map often reveals that a supposed fork is only an incomplete export. For example, an operator may export records 1 through 580 from one machine, while the restored Mac holds records 1 through 544. If both sequences share identical records through 500 and diverge at 501, that supports a true fork. If the export simply omits records 545 through 580 but otherwise matches the restored sequence, you have one lineage with a shortened copy. Look for independent witnesses around the suspected boundary. Useful witnesses include backup snapshot metadata, operating system install and boot records, remote API logs, SSH destination logs, notification records, and ticket notes written at the time. Each source has limits. A remote service can corroborate that an action arrived, while it may not identify which local audit file recorded it. A backup record can show that older state existed, while it may not show who initiated the restore. Make a working table with a lineage column from the beginning. It can be as plain as this: | Event reference | Lineage | Recorded time | Supporting source | Confidence note | | --- | --- | --- | --- | --- | | 000500 | shared | 13:42 | both native stores | common fork point | | 000501-O | original | 13:45 | pre-restore export | first original successor | | 000501-R | restored | 13:38 | restored volume | first restored successor | The suffixes in the table are analyst references only. Preserve the native record identifier in a separate field. This prevents a spreadsheet from silently rewriting the evidence merely to make duplicate numbers look tidy. Do not rank sources by convenience. A screen capture feels easy to read, but it lacks fields and collection context. A raw export may feel awkward, but it lets another person rerun the verification. The evidence map should tell reviewers why a source supports a statement, not merely where the analyst found it. ## Verify each lineage without pretending they join Run chain verification against each collected lineage as its own sequence. Record the exact input set, the collection-copy digest, the tool version, the command, the execution host, and the result. A verifier result without its inputs is a claim, not a repeatable finding. For audit data that supports Sallyport's verifier, the relevant command is: ```text sp audit verify ``` Sallyport lets that verification run offline over the encrypted, hash-chained audit log without a vault key. That is useful during collection because a locked vault does not require investigators to unlock credentials merely to test whether a collected sequence links correctly. Do not run the verifier on a folder that casually mixes records from both descendants. A mixed input can fail at the divergence, or a tool may consume files in an order you did not intend. Create separate, documented working copies for lineage-original and lineage-restored. Keep the native material unchanged. A passing result supports integrity within the selected lineage. Phrase it that way in notes and reports. A failed result needs a controlled investigation. Check whether collection omitted a segment, whether the export tool reordered records, whether a parser converted line endings or fields, and whether the source itself contains alteration. Preserve each failed input before testing a correction. The shared fork record deserves its own check. Confirm that its serialized contents and hash match in both sources. If they differ before the suspected divergence, you do not have the simple restore model described here. You may have different exports, corruption, independent audit stores, or a more complex sequence. Do not force the evidence into a clean V shape because the diagram is familiar. ## Timestamps need witnesses when branches overlap After you separate lineages, timestamps regain their proper use. They help place events in relation to outside sources. They do not decide which local continuation is authoritative. Build two chronologies first. In each chronology, retain recorded time, sequence order, event identity, and source reference. Then add outside events beside them: a remote API request received by a service, an SSH destination record, a backup snapshot completion, or a documented restore. Mark whether each outside event supports a specific lineage, supports both, or merely narrows the time window. Suppose the original continuation records an HTTP call at 15:10. The restored continuation records a different call at 14:58, even though the restore happened later in physical time. The discrepancy may reflect the restored clock, a snapshot that contained an earlier clock value, or a corrected time after startup. The right report does not choose 14:58 or 15:10 as the universal order. It says which device recorded each time and what independent record places the restore between them. Monotonic counters can help within a single boot, but a restore may return an old counter state or start a new boot context. Treat them as branch-local unless documentation proves otherwise. The same caution applies to process identifiers, temporary file names, and local session identifiers. A restored snapshot can reproduce values that look unique to someone reading only one device. When you need a single incident narrative, use a partial order. State events that evidence clearly orders, such as an original export created before its collection. State intervals where the order remains unknown. Investigators sometimes dislike that answer because leadership wants one timeline. A false total order is worse than an explicit uncertainty, especially when disciplinary or legal decisions depend on it. ## A restored history does not prove concealment Teams often treat a gap after a recovery as proof that someone intended to erase activity. That conclusion is popular because it fits a simple story: backup equals rollback, rollback equals cover-up. The technical evidence rarely carries that much intent on its own. A restore may follow disk failure, an unsuccessful upgrade, malware remediation, a mistaken cleanup, or a routine attempt to get a developer machine running again. The same act can create an audit fork regardless of motive. Intent requires evidence outside the branch structure, such as messages, commands, access records, or contradictions in a person's account. The opposite mistake is excusing every gap as a harmless restore. Look for contradictions. Did the person report the restore? Does backup metadata support the claimed source and time? Does the original continuation survive in an export or another service? Did a remote system receive actions that the restored lineage omits? Did someone change backup retention, audit storage, or system time around the same period? A practical review sequence keeps the reasoning disciplined: 1. Establish the shared prefix and the first divergent record. 2. Preserve native material and calculate collection digests. 3. Verify each lineage separately. 4. Corroborate the restore boundary with backup and external records. 5. Separate technical findings from conclusions about intent. This approach also protects innocent operators. A person who restored a Mac during an outage should not inherit an accusation because an investigator treated a valid restored continuation as a forged log. Conversely, a person cannot settle the matter by pointing to a clean chain if another preserved continuation shows later events from the same fork point. ## Design recovery so a fork leaves visible evidence You cannot make Time Machine incapable of restoring application state. You can decide whether a restoration leaves enough independent evidence to explain what followed. The useful controls are operational: export signed or otherwise independently retained audit material before major changes, preserve backup metadata, record restore decisions in a ticket, and collect remote action records where they naturally exist. Do not rely on a local chain alone as your only proof of history. A local chain gives strong evidence about the records present on that device. A backup makes rollback possible, which is its job. Those two facts coexist. Teams need another retained reference when they need to distinguish continuity from an older state resumed later. Test the awkward case in a non-production environment. Create a few audit events, take a backup, create more events, restore the older state, then create one additional event. Have a second person collect both continuations and explain the fork without using the operator's memory. If the team cannot label the sources, verify each sequence, and preserve the boundary in that exercise, it will struggle during an incident. Write one sentence into the recovery procedure: a restore that includes audit state starts a new evidence lineage until review establishes otherwise. That sentence changes the operator's behavior at the moment it counts. It asks for preservation before ordinary work resumes, and it stops the convenient fiction that the post-restore log automatically replaces what came before. ## Report two histories without smoothing the hard parts A defensible finding names the shared record, identifies the source of each continuation, states verification results separately, and describes what external evidence does or does not order. It should also distinguish a demonstrated restore from a suspected restore. The language can remain plain: the collected material contains two cryptographically consistent continuations after record 500; backup metadata places an older audit state on the Mac; the evidence does not establish a single order between the descendants without further sources. Do not call a branch an alternate reality, a shadow log, or a duplicate timeline. Those phrases make a technical condition sound dramatic and leave reviewers guessing what you actually found. A forked audit history is already serious enough. It means the local record no longer supplies one uninterrupted account after a known point. The first action after discovery is simple: preserve the original continuation if it still exists, before the restored Mac writes another record. Every later discussion about verification, timestamps, and motive depends on whether that second line survived.