# Como uma restauração do Time Machine divide uma trilha de auditoria Uma restauração do Time Machine pode dividir um histórico de auditoria mesmo quando todos os registros sobreviventes passam pela verificação criptográfica. Isso surpreende as equipes porque elas esperam que uma cadeia de hashes produza uma única história definitiva. Uma cadeia comprova continuidade a partir de um registro anterior. Ela não prova que um Mac nunca voltou àquele registro anterior e continuou por um caminho diferente. O erro é chamar uma continuação de falsa assim que os investigadores encontram duas delas. Uma recuperação rotineira pode criar essa situação sem fraude. O trabalho com as evidências é preservar as duas linhas, descrever onde elas compartilham o histórico e informar o que cada uma pode e não pode estabelecer. Se você as reduzir a uma cronologia organizada, criará o primeiro registro não confiável do caso. ## Uma restauração pode criar duas continuações legítimas Um Mac restaurado cria uma bifurcação quando a restauração inclui uma cópia mais antiga do repositório de auditoria e o aplicativo depois grava novos eventos a partir desse estado restaurado. Considere um log cujos registros vinculam seus hashes em sequência. No registro 500, o repositório tem o hash de cabeça H500. O Time Machine captura esse estado. O Mac continua operando e grava os registros 501 a 580, cada um vinculado ao registro anterior. Mais tarde, alguém restaura o Mac para o backup que terminava no registro 500. O aplicativo restaurado vê H500 como seu hash de cabeça atual e grava um novo registro 501. Esse novo registro se vincula corretamente a H500. Ele apenas tem conteúdo, hash e talvez data e hora diferentes do registro 501 que o Mac original gravou antes da restauração. O resultado tem um prefixo compartilhado e dois descendentes: ```text records 1 through 500 | +-- lineage-original: 501 through 580 | +-- lineage-restored: 501 through 544 ``` Cada descendente pode passar por uma verificação normal da cadeia. O verificador pergunta se cada registro se vincula ao predecessor fornecido naquela sequência. Ele não guarda uma memória universal de toda continuação que poderia ter começado em H500. Isso não é uma falha de hashing. É o resultado esperado quando um sistema restaura um estado mutável. A bifurcação pode ocorrer após um desligamento normal, depois de uma falha ou durante uma recuperação urgente. Um técnico não precisa manipular o banco de dados de auditoria. Restaurar todo o sistema, restaurar uma pasta de dados do aplicativo ou substituir um volume por um backup pode devolver um cabeçalho de log mais antigo. Os detalhes dependem do que o backup capturou e do que a recuperação recolocou. Não confunda uma cópia com uma bifurcação. Se o Mac restaurado nunca registrar outro evento, você terá uma cópia mais antiga de um histórico. Há bifurcação apenas quando dois sucessores distintos afirmam ter o mesmo predecessor. Essa diferença afeta todas as conclusões posteriores. ## Validade dentro de uma ramificação não é uma linha do tempo global Uma verificação de cadeia de hashes responde a uma pergunta limitada: este registro veio depois deste registro anterior na sequência fornecida? Ela não responde se outro registro válido também seguiu o mesmo registro anterior em outro lugar. Investigadores costumam exagerar a primeira resposta como se ela resolvesse a segunda. Uma forma útil de separar as afirmações é manter quatro termos distintos: - Integridade significa que os registros de uma sequência coletada continuam vinculados como esperado. - Continuidade significa que a sequência não tem lacuna sem explicação dentro do material que você possui. - Completude significa que você tem todos os eventos que ocorreram no escopo relevante. - Exclusividade significa que não existe outra continuação a partir do mesmo ponto. Uma trilha de auditoria local pode oferecer forte integridade e ainda não oferecer completude nem exclusividade após uma restauração. Entender isso errado leva a uma frase prejudicial no relatório: o log prova que nenhuma aprovação ocorreu. Talvez o log prove apenas que nenhuma aprovação aparece na continuação restaurada. O próprio tempo piora a confusão. Os horários do relógio podem se sobrepor. O Mac original pode registrar uma ação às 14:03, e o Mac restaurado pode acertar o relógio pela rede e registrar outra ação às 14:02, enquanto continua a partir de um cabeçalho de sequência mais antigo. Ordenar por horário pode intercalar eventos das ramificações em uma ordem atraente, mas falsa. Os números de sequência também precisam de contexto. Os dois descendentes podem conter o registro 501. Não renomeie um deles como 501A na evidência bruta e não decida que o número de sequência maior vence. Mantenha os campos originais intactos e adicione informações de linhagem às suas anotações de trabalho. A Publicação Especial 800-92 do NIST, Guide to Computer Security Log Management, trata da sincronização de tempo e do tratamento protegido de logs como requisitos operacionais. Essa orientação continua válida, mas relógios sincronizados não resolvem estados restaurados. A disciplina de relógio ajuda a comparar fontes. Ela não diz ao verificador qual de dois registros posteriores foi o único sucessor de um registro anterior. ## Chame o ponto de bifurcação pelo que ele é Use um rótulo preciso antes de discutir motivação. Eu uso ponto de bifurcação para o último registro compartilhado pelas duas continuações. Uso linhagem para uma cadeia contínua que começa nesse ponto. Reservo ramificação para a relação entre linhagens, e não como sinônimo casual de um arquivo copiado. Dê a cada linhagem um identificador estável no caso. Os nomes precisam descrever a origem, não a credibilidade. Por exemplo, use lineage-original para a sequência recuperada de uma imagem do dispositivo ou de uma exportação anterior à restauração, e lineage-restored para a sequência que o Mac recuperado gravou depois. Se a origem ainda for incerta, use lineage-A e lineage-B até que as evidências sustentem um nome mais específico. Uma anotação de preservação pode ser curta e ainda evitar semanas de confusão: ```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 ``` Não coloque conclusões como legítima, comprometida ou confiável nesses rótulos. Essas palavras induzem a equipe a decidir antes de examinar as evidências ao redor. O rótulo deve permitir que outro investigador retome o material seis meses depois e saiba exatamente a que sequência uma afirmação se refere. Registre também o limite da restauração como um intervalo quando as evidências só sustentarem um intervalo. A data de um snapshot do Time Machine informa quando o backup capturou os dados. Ela não informa automaticamente quando a restauração de fato ocorreu, quando o Mac inicializou pela primeira vez depois dela ou quando o aplicativo voltou a gravar. Isso pode exigir metadados do backup, registros do sistema, anotações do administrador e logs de serviços que confirmem os fatos. ## Preserve a máquina antes que ela estenda a ramificação restaurada Uma máquina restaurada pode alterar as evidências assim que inicia o aplicativo que controla o repositório de auditoria. Ela pode gravar um evento de inicialização, rotacionar um arquivo, atualizar um índice ou entrar em contato com um serviço de horário. Por isso, a primeira decisão de manuseio importa mais do que um analisador sofisticado depois. Primeiro, interrompa o uso comum e registre a condição visível do Mac. Fotografe a tela se ele já estiver em execução, anote o horário exibido e o estado da rede, e registre quem tinha controle físico. Depois, isole-o das redes de uma forma compatível com seu procedimento de incidente. Não reinicie só porque você prefere uma coleta mais limpa. Uma reinicialização pode substituir o contexto volátil e provocar mais gravações. Em seguida, preserve fontes distintas separadamente. Isso inclui o volume restaurado, o conjunto de backup relevante do Time Machine, qualquer exportação anterior à restauração e cópias mantidas por serviços que receberam as ações auditadas. Calcule um hash criptográfico de cada arquivo ou imagem coletado e mantenha o original somente leitura sempre que suas ferramentas permitirem. Trabalhe com cópias. A expressão preservar as duas linhas do tempo tem um sentido prático. Ela não significa copiar uma tela de atividades renderizada para um relatório. Preserve os dados nativos de auditoria, o programa verificador e sua versão, os metadados de backup que situam um estado mais antigo no Mac e as anotações de coleta que mostram como cada item chegou até você. Se encontrar apenas a continuação restaurada, diga isso. Não invente a continuação original. Você ainda pode identificar uma possível bifurcação se um snapshot de backup contiver o cabeçalho compartilhado e outras fontes mostrarem atividade que o histórico restaurado não consegue explicar. Porém, não é possível reconstruir registros ausentes extrapolando hashes. Uma cadeia de hashes detecta uma relação fornecida, não recupera conteúdo ausente. Um incidente sensível ao tempo pode obrigar uma equipe a recuperar o serviço rapidamente. Separe a recuperação operacional da preservação das evidências. Faça primeiro uma cópia preservada quando puder, registre o ponto em que isso foi impossível quando não puder e documente toda ação que possa ter gravado no sistema ativo. Uma limitação assumida com honestidade causa muito menos dano que uma cronologia elegante construída depois dos fatos. ## Crie um mapa de evidências antes de ordenar os eventos Investigadores precisam de um mapa de evidências antes de criar uma linha do tempo. Comece pelas fontes, não pelos eventos. Cada fonte tem uma data de coleta, um responsável, um intervalo de datas relevante, um formato nativo, um resumo criptográfico e uma relação com uma linhagem ou com ambas. O mapa frequentemente revela que uma suposta bifurcação é apenas uma exportação incompleta. Por exemplo, um operador pode exportar os registros 1 a 580 de uma máquina, enquanto o Mac restaurado contém os registros 1 a 544. Se as duas sequências compartilham registros idênticos até o 500 e divergem no 501, isso sustenta uma bifurcação real. Se a exportação simplesmente omite os registros 545 a 580, mas fora isso corresponde à sequência restaurada, há uma linhagem com uma cópia abreviada. Procure testemunhas independentes perto do limite suspeito. Entre as testemunhas úteis estão metadados de snapshots de backup, registros de instalação e inicialização do sistema operacional, logs de API remota, logs de destino SSH, registros de notificações e anotações de tickets feitas na época. Cada fonte tem limites. Um serviço remoto pode confirmar que uma ação chegou, mas pode não identificar qual arquivo local de auditoria a registrou. Um registro de backup pode mostrar que um estado mais antigo existiu, mas talvez não mostre quem iniciou a restauração. Crie desde o começo uma tabela de trabalho com uma coluna de linhagem. Ela pode ser simples assim: | Referência do evento | Linhagem | Horário registrado | Fonte de apoio | Observação sobre confiança | | --- | --- | --- | --- | --- | | 000500 | compartilhada | 13:42 | ambos os repositórios nativos | ponto comum de bifurcação | | 000501-O | original | 13:45 | exportação anterior à restauração | primeiro sucessor original | | 000501-R | restaurada | 13:38 | volume restaurado | primeiro sucessor restaurado | Os sufixos na tabela são apenas referências do analista. Preserve o identificador nativo do registro em um campo separado. Isso impede que uma planilha reescreva silenciosamente as evidências apenas para deixar números duplicados mais organizados. Não classifique as fontes pela conveniência. Uma captura de tela parece fácil de ler, mas não traz campos nem contexto de coleta. Uma exportação bruta pode parecer incômoda, mas permite que outra pessoa refaça a verificação. O mapa de evidências deve dizer aos revisores por que uma fonte sustenta uma afirmação, e não apenas onde o analista a encontrou. ## Verifique cada linhagem sem fingir que elas se unem Execute a verificação da cadeia em cada linhagem coletada como uma sequência própria. Registre o conjunto exato de entradas, o resumo da cópia coletada, a versão da ferramenta, o comando, o host de execução e o resultado. Um resultado de verificador sem suas entradas é uma alegação, não uma conclusão que pode ser repetida. Para dados de auditoria compatíveis com o verificador do Sallyport, o comando relevante é: ```text sp audit verify ``` O Sallyport permite executar essa verificação offline no log de auditoria criptografado e encadeado por hashes, sem uma chave do cofre. Isso é útil durante a coleta porque um cofre bloqueado não exige que investigadores desbloqueiem credenciais apenas para testar se uma sequência coletada se vincula corretamente. Não execute o verificador em uma pasta que mistura casualmente registros dos dois descendentes. Uma entrada misturada pode falhar na divergência, ou uma ferramenta pode consumir arquivos em uma ordem que você não pretendia. Crie cópias de trabalho separadas e documentadas para lineage-original e lineage-restored. Mantenha o material nativo inalterado. Um resultado aprovado sustenta a integridade dentro da linhagem selecionada. Expresse isso dessa forma nas anotações e nos relatórios. Um resultado reprovado exige uma investigação controlada. Verifique se a coleta omitiu um segmento, se a ferramenta de exportação reordenou registros, se um analisador converteu quebras de linha ou campos e se a própria fonte contém alteração. Preserve cada entrada reprovada antes de testar uma correção. O registro compartilhado da bifurcação merece uma verificação própria. Confirme que seu conteúdo serializado e seu hash correspondem nas duas fontes. Se eles diferirem antes da divergência suspeita, você não tem o modelo simples de restauração descrito aqui. Pode haver exportações diferentes, corrupção, repositórios de auditoria independentes ou uma sequência mais complexa. Não force as evidências para formar um V limpo só porque o diagrama é familiar. ## Horários precisam de testemunhas quando as ramificações se sobrepõem Depois de separar as linhagens, os horários recuperam seu uso correto. Eles ajudam a situar os eventos em relação a fontes externas. Eles não decidem qual continuação local é a autorizada. Primeiro, crie duas cronologias. Em cada uma, mantenha o horário registrado, a ordem da sequência, a identidade do evento e a referência da fonte. Depois, acrescente eventos externos ao lado delas: uma solicitação de API remota recebida por um serviço, um registro de destino SSH, a conclusão de um snapshot de backup ou uma restauração documentada. Marque se cada evento externo sustenta uma linhagem específica, sustenta ambas ou apenas reduz a janela de tempo. Suponha que a continuação original registre uma chamada HTTP às 15:10. A continuação restaurada registra uma chamada diferente às 14:58, embora a restauração tenha ocorrido mais tarde no tempo físico. A discrepância pode refletir o relógio restaurado, um snapshot que continha um valor de relógio anterior ou uma correção de horário após a inicialização. O relatório correto não escolhe 14:58 ou 15:10 como ordem universal. Ele informa qual dispositivo registrou cada horário e qual registro independente situa a restauração entre eles. Contadores monotônicos podem ajudar dentro de uma única inicialização, mas uma restauração pode devolver um estado antigo do contador ou iniciar um novo contexto de inicialização. Trate-os como locais da ramificação, a menos que a documentação prove o contrário. O mesmo cuidado vale para identificadores de processo, nomes temporários de arquivos e identificadores de sessão locais. Um snapshot restaurado pode reproduzir valores que parecem únicos para quem lê apenas um dispositivo. Quando precisar de uma única narrativa do incidente, use uma ordem parcial. Declare os eventos que as evidências ordenam claramente, como uma exportação original criada antes de sua coleta. Declare os intervalos em que a ordem continua desconhecida. Investigadores às vezes não gostam dessa resposta porque a liderança quer uma única linha do tempo. Uma ordem total falsa é pior que uma incerteza explícita, principalmente quando decisões disciplinares ou legais dependem dela. ## Um histórico restaurado não prova ocultação As equipes frequentemente tratam uma lacuna após uma recuperação como prova de que alguém quis apagar atividades. Essa conclusão é popular porque se encaixa em uma história simples: backup significa reversão, reversão significa acobertamento. A evidência técnica raramente sustenta tanta intenção por si só. Uma restauração pode ocorrer após falha de disco, atualização malsucedida, remoção de malware, limpeza feita por engano ou uma tentativa rotineira de fazer uma máquina de desenvolvimento voltar a funcionar. A mesma ação pode criar uma bifurcação de auditoria independentemente da motivação. A intenção exige evidências fora da estrutura das ramificações, como mensagens, comandos, registros de acesso ou contradições no relato de uma pessoa. O erro oposto é justificar toda lacuna como uma restauração inofensiva. Procure contradições. A pessoa relatou a restauração? Os metadados do backup sustentam a fonte e o horário informados? A continuação original sobrevive em uma exportação ou em outro serviço? Um sistema remoto recebeu ações que a linhagem restaurada omite? Alguém alterou a retenção de backups, o armazenamento de auditoria ou o horário do sistema no mesmo período? Uma sequência prática de revisão mantém o raciocínio disciplinado: 1. Estabeleça o prefixo compartilhado e o primeiro registro divergente. 2. Preserve o material nativo e calcule os resumos das cópias coletadas. 3. Verifique cada linhagem separadamente. 4. Confirme o limite da restauração com registros de backup e externos. 5. Separe conclusões técnicas de conclusões sobre intenção. Essa abordagem também protege operadores inocentes. Uma pessoa que restaurou um Mac durante uma indisponibilidade não deve receber uma acusação porque um investigador tratou uma continuação restaurada válida como log falsificado. Por outro lado, uma pessoa não pode encerrar o assunto apontando para uma cadeia limpa se outra continuação preservada mostrar eventos posteriores a partir do mesmo ponto de bifurcação. ## Planeje a recuperação para que uma bifurcação deixe evidências visíveis Você não pode impedir que o Time Machine restaure o estado de um aplicativo. Pode decidir se uma restauração deixa evidências independentes suficientes para explicar o que veio depois. Os controles úteis são operacionais: exporte material de auditoria assinado ou retido de outra forma independente antes de grandes mudanças, preserve metadados de backup, registre decisões de restauração em um ticket e colete registros de ações remotas onde eles existirem naturalmente. Não use apenas uma cadeia local como única prova do histórico. Uma cadeia local fornece fortes evidências sobre os registros presentes naquele dispositivo. Um backup torna a reversão possível, que é sua função. Esses dois fatos coexistem. As equipes precisam de outra referência retida quando precisam distinguir continuidade de um estado mais antigo retomado depois. Teste o caso incômodo em um ambiente que não seja de produção. Crie alguns eventos de auditoria, faça um backup, crie mais eventos, restaure o estado mais antigo e crie então um evento adicional. Peça a uma segunda pessoa que colete as duas continuações e explique a bifurcação sem usar a memória do operador. Se a equipe não conseguir rotular as fontes, verificar cada sequência e preservar o limite nesse exercício, terá dificuldades durante um incidente. Inclua uma frase no procedimento de recuperação: uma restauração que inclui estado de auditoria inicia uma nova linhagem de evidências até que uma revisão estabeleça o contrário. Essa frase muda o comportamento do operador no momento em que isso importa. Ela pede preservação antes que o trabalho normal seja retomado e impede a ficção conveniente de que o log posterior à restauração substitui automaticamente o que veio antes. ## Relate dois históricos sem suavizar as partes difíceis Uma conclusão defensável identifica o registro compartilhado, aponta a fonte de cada continuação, informa os resultados de verificação separadamente e descreve o que as evidências externas ordenam ou não ordenam. Ela também deve distinguir uma restauração demonstrada de uma restauração suspeita. A linguagem pode continuar simples: o material coletado contém duas continuações criptograficamente consistentes após o registro 500; os metadados de backup situam um estado de auditoria mais antigo no Mac; as evidências não estabelecem uma única ordem entre os descendentes sem outras fontes. Não chame uma ramificação de realidade alternativa, log oculto ou linha do tempo duplicada. Essas expressões fazem uma condição técnica parecer dramática e deixam os revisores tentando adivinhar o que você encontrou. Um histórico de auditoria bifurcado já é suficientemente sério. Ele significa que o registro local deixou de fornecer um relato único e ininterrupto depois de um ponto conhecido. A primeira ação após a descoberta é simples: preserve a continuação original, se ela ainda existir, antes que o Mac restaurado grave outro registro. Toda discussão posterior sobre verificação, horários e motivação depende de essa segunda linha ter sobrevivido.