# Cómo una restauración de Time Machine bifurca un rastro de auditoría Una restauración de Time Machine puede bifurcar un historial de auditoría incluso cuando todos los registros conservados superan la verificación criptográfica. El resultado sorprende a los equipos porque esperan que una cadena de hashes produzca una sola historia autorizada. Una cadena demuestra continuidad desde un registro anterior. No puede demostrar que un Mac nunca volvió a ese registro anterior y siguió por otro camino. El error consiste en llamar falsa a una continuación en cuanto los investigadores encuentran dos. Una recuperación rutinaria puede crear esta situación sin engaño. La tarea con la evidencia es conservar ambas líneas, describir dónde comparten historial e indicar qué puede y qué no puede demostrar cada línea. Si las aplanas en una cronología ordenada, creas el primer registro poco fiable del caso. ## Una restauración puede crear dos continuaciones legítimas Un Mac restaurado crea una bifurcación cuando la restauración incluye una copia antigua del almacén de auditoría y la aplicación escribe después eventos nuevos desde ese estado restaurado. Considera un registro cuyos elementos enlazan sus hashes en secuencia. En el registro 500, el almacén tiene la cabecera de hash H500. Time Machine captura ese estado. El Mac sigue funcionando y escribe los registros 501 a 580, cada uno enlazado con el anterior. Más tarde, alguien restaura el Mac a la copia que terminaba en el registro 500. La aplicación restaurada ve H500 como su cabecera actual y escribe un nuevo registro 501. Ese nuevo registro enlaza correctamente con H500. Simplemente tiene contenido, hash y quizá marca de tiempo distintos del registro 501 que el Mac original escribió antes de la restauración. El resultado tiene un prefijo compartido y dos descendientes: ```text records 1 through 500 | +-- lineage-original: 501 through 580 | +-- lineage-restored: 501 through 544 ``` Cada descendiente puede superar una comprobación normal de cadena. El verificador pregunta si cada registro enlaza con el predecesor proporcionado en esa secuencia. No posee una memoria universal de todas las continuaciones que podrían haber comenzado desde H500. No es un fallo de los hashes. Es el resultado esperado cuando un sistema restaura estado modificable. La bifurcación puede ocurrir tras un apagado limpio, después de un fallo o durante una recuperación urgente. Un técnico no necesita manipular la base de datos de auditoría. Restaurar todo el sistema, restaurar una carpeta de datos de la aplicación o sustituir un volumen por una copia de seguridad puede devolver una cabecera de registro más antigua. Los detalles dependen de lo que capturó la copia y de lo que devolvió la recuperación. No confundas una copia con una bifurcación. Si el Mac restaurado nunca registra otro evento, tienes una copia antigua de un historial. Solo hay una bifurcación cuando dos sucesores distintos reclaman el mismo predecesor. Esa diferencia afecta a todas las conclusiones posteriores. ## La validez dentro de una rama no equivale a una línea de tiempo global Una comprobación de cadena de hashes responde a una pregunta limitada: ¿este registro siguió a este registro anterior en la secuencia proporcionada? No responde si algún otro registro válido también siguió al mismo registro anterior en otro lugar. Los investigadores suelen exagerar la primera respuesta como si resolviera la segunda. Una forma útil de separar las afirmaciones es distinguir cuatro términos: - Integridad significa que los registros de una secuencia recopilada siguen enlazando como se espera. - Continuidad significa que la secuencia no tiene un hueco sin explicación dentro del material que tienes. - Exhaustividad significa que cuentas con todos los eventos que ocurrieron en el ámbito relevante. - Exclusividad significa que no existe otra continuación desde el mismo punto. Un rastro de auditoría local puede ofrecer una integridad sólida y aun así no ofrecer ni exhaustividad ni exclusividad después de una restauración. Equivocarse aquí lleva a una frase dañina en un informe: el registro demuestra que no hubo aprobación. El registro quizá solo demuestre que no aparece ninguna aprobación en la continuación restaurada. El tiempo empeora la confusión. Las marcas de tiempo del reloj pueden solaparse. El Mac original podría registrar una acción a las 14:03 y, después, el Mac restaurado podría ajustar su reloj desde la red y registrar una acción distinta a las 14:02 mientras continúa desde una cabecera de secuencia más antigua. Ordenar por marcas de tiempo puede entremezclar eventos de las ramas en un orden atractivo pero falso. Los números de secuencia también necesitan contexto. Ambos descendientes pueden contener el registro 501. No renombres uno como registro 501A en la evidencia original ni decidas que gana el número de secuencia más alto. Mantén intactos los campos originales y añade información de linaje en tus notas de trabajo. La Publicación Especial 800-92 de NIST, Guide to Computer Security Log Management, considera que el tiempo sincronizado y el manejo protegido de registros son requisitos operativos. Esa orientación sigue siendo acertada, pero los relojes sincronizados no resuelven el estado restaurado. La disciplina del reloj ayuda a comparar fuentes. No puede decir a un verificador cuál de dos registros posteriores fue el único sucesor de un registro anterior. ## Llama al punto de bifurcación por lo que es Usa una etiqueta precisa antes de hablar del motivo. Uso punto de bifurcación para el último registro compartido por ambas continuaciones. Uso linaje para una cadena continua que comienza en ese punto. Reservo rama para la relación entre linajes, no como sinónimo informal de un archivo copiado. Asigna a cada linaje un identificador de caso estable. Los nombres deben describir el origen, no la credibilidad. Por ejemplo, usa lineage-original para la secuencia recuperada de una imagen de dispositivo o de una exportación anterior a la restauración, y lineage-restored para la secuencia que escribió después el Mac recuperado. Si el origen sigue siendo incierto, usa lineage-A y lineage-B hasta que la evidencia justifique un nombre más específico. Una nota de conservación puede ser breve y aun así evitar semanas de confusión: ```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 ``` No incluyas en estas etiquetas conclusiones como legítimo, comprometido o fiable. Esas palabras invitan al equipo a decidir antes de examinar la evidencia circundante. La etiqueta debe permitir que otro investigador retome el material seis meses después y sepa exactamente a qué secuencia se refiere una afirmación. También registra el límite de la restauración como un intervalo cuando la evidencia solo sustente un intervalo. La fecha de una instantánea de Time Machine indica cuándo la copia capturó datos. No indica automáticamente cuándo se ejecutó la restauración, cuándo arrancó por primera vez el Mac después ni cuándo la aplicación volvió a escribir. Para saberlo quizá necesites metadatos de la copia, registros del sistema, notas del administrador y registros de servicios que lo corroboren. ## Conserva la máquina antes de que amplíe la rama restaurada Una máquina restaurada puede cambiar la evidencia en cuanto inicia la aplicación propietaria del almacén de auditoría. Puede escribir un evento de inicio, rotar un archivo, actualizar un índice o contactar un servicio horario. Por eso, la primera decisión de manejo importa más que un analizador ingenioso posterior. Primero, detén el uso habitual y registra el estado visible del Mac. Fotografía la pantalla si ya está en funcionamiento, anota la hora mostrada y el estado de red, y registra quién tenía el control físico. Después, aíslalo de las redes de una manera acorde con tu procedimiento de incidentes. No lo reinicies solo porque prefieras una recopilación limpia. Un reinicio puede sustituir contexto volátil y provocar más escrituras. Después, conserva las fuentes distintas por separado. Eso incluye el volumen restaurado, el conjunto relevante de copias de Time Machine, cualquier exportación anterior a la restauración y las copias que mantengan los servicios que recibieron las acciones auditadas. Calcula un hash criptográfico de cada archivo o imagen recopilados y mantén el original en solo lectura siempre que tus herramientas lo permitan. Trabaja con copias. La frase conservar ambas líneas de tiempo tiene un sentido práctico. No significa copiar una pantalla de actividad mostrada a un informe. Conserva los datos de auditoría nativos, el programa verificador y su versión, los metadatos de la copia que sitúan un estado anterior en el Mac y las notas de recopilación que establecen cómo llegó hasta ti cada elemento. Si solo encuentras la continuación restaurada, indícalo. No inventes la continuación original. Aun así puedes identificar una posible bifurcación si una instantánea de copia contiene la cabecera compartida y otras fuentes muestran actividad que el historial restaurado no puede explicar. Sin embargo, no puedes reconstruir los registros ausentes extrapolando hashes. Una cadena de hashes detecta una relación proporcionada, no recupera contenido ausente. Un incidente urgente puede obligar al equipo a recuperar el servicio rápidamente. Separa la recuperación operativa de la conservación de evidencia. Haz primero una copia conservada cuando puedas, registra el momento en que no fue posible cuando no puedas y documenta cada acción que pudiera haber escrito en el sistema activo. Una limitación honesta es mucho menos dañina que una cronología pulida construida después de los hechos. ## Crea un mapa de evidencia antes de ordenar eventos Los investigadores necesitan un mapa de evidencia antes de crear una línea de tiempo. Empieza por las fuentes, no por los eventos. Cada fuente tiene una fecha de recopilación, un responsable, un intervalo de fechas relevante, un formato nativo, un resumen criptográfico y una relación con uno o ambos linajes. El mapa suele revelar que una supuesta bifurcación es solo una exportación incompleta. Por ejemplo, un operador puede exportar los registros 1 a 580 de una máquina, mientras que el Mac restaurado contiene los registros 1 a 544. Si ambas secuencias comparten registros idénticos hasta el 500 y divergen en el 501, eso respalda una bifurcación real. Si la exportación simplemente omite los registros 545 a 580 pero por lo demás coincide con la secuencia restaurada, tienes un solo linaje con una copia abreviada. Busca testigos independientes alrededor del límite sospechoso. Entre los testigos útiles están los metadatos de instantáneas de copias, los registros de instalación y arranque del sistema operativo, los registros de API remotas, los registros de destinos SSH, los registros de notificaciones y las notas de tickets escritas en ese momento. Cada fuente tiene límites. Un servicio remoto puede corroborar que llegó una acción, pero quizá no identifique qué archivo de auditoría local la registró. Un registro de copia puede mostrar que existió un estado anterior, pero quizá no quién inició la restauración. Desde el inicio, crea una tabla de trabajo con una columna de linaje. Puede ser tan sencilla como esta: | Referencia de evento | Linaje | Hora registrada | Fuente de apoyo | Nota de confianza | | --- | --- | --- | --- | --- | | 000500 | compartido | 13:42 | ambos almacenes nativos | punto de bifurcación común | | 000501-O | original | 13:45 | exportación previa a la restauración | primer sucesor original | | 000501-R | restaurado | 13:38 | volumen restaurado | primer sucesor restaurado | Los sufijos de la tabla son solo referencias del analista. Conserva el identificador de registro nativo en un campo separado. Así evitas que una hoja de cálculo reescriba silenciosamente la evidencia solo para que los números duplicados parezcan ordenados. No clasifiques las fuentes por comodidad. Una captura de pantalla parece fácil de leer, pero le faltan campos y contexto de recopilación. Una exportación sin procesar puede parecer incómoda, pero permite que otra persona repita la verificación. El mapa de evidencia debe explicar a los revisores por qué una fuente respalda una afirmación, no solo dónde la encontró el analista. ## Verifica cada linaje sin fingir que se unen Ejecuta la verificación de cadena sobre cada linaje recopilado como su propia secuencia. Registra el conjunto exacto de entradas, el resumen de la copia recopilada, la versión de la herramienta, el comando, el equipo de ejecución y el resultado. Un resultado de verificador sin sus entradas es una afirmación, no un hallazgo repetible. Para datos de auditoría compatibles con el verificador de Sallyport, el comando relevante es: ```text sp audit verify ``` Sallyport permite ejecutar esa verificación sin conexión sobre el registro de auditoría cifrado y encadenado mediante hashes, sin una clave de bóveda. Es útil durante la recopilación porque una bóveda bloqueada no obliga a los investigadores a desbloquear credenciales solo para comprobar si una secuencia recopilada enlaza correctamente. No ejecutes el verificador sobre una carpeta que mezcle casualmente registros de ambos descendientes. Una entrada mezclada puede fallar en la divergencia, o una herramienta puede consumir archivos en un orden que no pretendías. Crea copias de trabajo separadas y documentadas para lineage-original y lineage-restored. Mantén sin cambios el material nativo. Un resultado satisfactorio respalda la integridad dentro del linaje seleccionado. Exprésalo así en notas e informes. Un resultado fallido exige una investigación controlada. Comprueba si la recopilación omitió un segmento, si la herramienta de exportación reordenó registros, si un analizador convirtió finales de línea o campos y si la propia fuente contiene alteraciones. Conserva cada entrada fallida antes de probar una corrección. El registro compartido de bifurcación merece su propia comprobación. Confirma que su contenido serializado y su hash coincidan en ambas fuentes. Si difieren antes de la divergencia sospechada, no tienes el modelo simple de restauración descrito aquí. Podrías tener exportaciones distintas, corrupción, almacenes de auditoría independientes o una secuencia más compleja. No fuerces la evidencia a una forma de V limpia porque el diagrama resulte familiar. ## Las marcas de tiempo necesitan testigos cuando las ramas se solapan Después de separar los linajes, las marcas de tiempo recuperan su uso correcto. Ayudan a situar eventos en relación con fuentes externas. No deciden qué continuación local tiene autoridad. Primero crea dos cronologías. En cada una, conserva la hora registrada, el orden de secuencia, la identidad del evento y la referencia de fuente. Después añade junto a ellas eventos externos: una solicitud de API remota recibida por un servicio, un registro de destino SSH, la finalización de una instantánea de copia o una restauración documentada. Indica si cada evento externo respalda un linaje específico, ambos o simplemente acota el intervalo temporal. Supón que la continuación original registra una llamada HTTP a las 15:10. La continuación restaurada registra una llamada distinta a las 14:58, aunque la restauración ocurrió más tarde en el tiempo físico. La discrepancia puede reflejar el reloj restaurado, una instantánea que contenía un valor de reloj anterior o la corrección de hora tras el inicio. El informe correcto no elige las 14:58 ni las 15:10 como orden universal. Indica qué dispositivo registró cada hora y qué registro independiente sitúa la restauración entre ambas. Los contadores monotónicos pueden ayudar dentro de un único arranque, pero una restauración puede devolver un estado anterior del contador o iniciar un nuevo contexto de arranque. Trátalos como locales de la rama salvo que la documentación demuestre lo contrario. La misma cautela se aplica a identificadores de proceso, nombres de archivos temporales e identificadores de sesión locales. Una instantánea restaurada puede reproducir valores que parecen únicos para quien lee un solo dispositivo. Cuando necesites una única narrativa del incidente, usa un orden parcial. Indica los eventos que la evidencia ordena claramente, como una exportación original creada antes de su recopilación. Indica los intervalos cuyo orden sigue siendo desconocido. A los investigadores a veces no les gusta esa respuesta porque la dirección quiere una sola línea de tiempo. Un orden total falso es peor que una incertidumbre explícita, especialmente cuando dependen de ello decisiones disciplinarias o legales. ## Un historial restaurado no demuestra ocultación Los equipos suelen tratar un hueco después de una recuperación como prueba de que alguien pretendía borrar actividad. Esa conclusión resulta atractiva porque encaja con una historia simple: copia de seguridad equivale a reversión, reversión equivale a encubrimiento. La evidencia técnica rara vez basta por sí sola para atribuir tanta intención. Una restauración puede seguir a un fallo de disco, una actualización fallida, la eliminación de malware, una limpieza equivocada o un intento rutinario de volver a poner en marcha la máquina de un desarrollador. El mismo acto puede crear una bifurcación de auditoría con independencia del motivo. La intención requiere evidencia ajena a la estructura de ramas, como mensajes, comandos, registros de acceso o contradicciones en el relato de una persona. El error opuesto es excusar cada hueco como una restauración inocua. Busca contradicciones. ¿La persona informó de la restauración? ¿Los metadatos de la copia respaldan el origen y la hora declarados? ¿Sobrevive la continuación original en una exportación o en otro servicio? ¿Un sistema remoto recibió acciones que omite el linaje restaurado? ¿Alguien cambió la retención de copias, el almacenamiento de auditoría o la hora del sistema en el mismo periodo? Una secuencia práctica de revisión mantiene el razonamiento disciplinado: 1. Establece el prefijo compartido y el primer registro divergente. 2. Conserva el material nativo y calcula los resúmenes de recopilación. 3. Verifica cada linaje por separado. 4. Corrobora el límite de restauración con registros de copias y externos. 5. Separa los hallazgos técnicos de las conclusiones sobre la intención. Este enfoque también protege a operadores inocentes. Quien restauró un Mac durante una interrupción no debería cargar con una acusación porque un investigador trató una continuación restaurada válida como un registro falsificado. A la inversa, una persona no puede resolver el asunto señalando una cadena limpia si otra continuación conservada muestra eventos posteriores desde el mismo punto de bifurcación. ## Diseña la recuperación para que una bifurcación deje evidencia visible No puedes impedir que Time Machine restaure el estado de una aplicación. Puedes decidir si una restauración deja suficiente evidencia independiente para explicar lo que ocurrió después. Los controles útiles son operativos: exportar material de auditoría firmado o conservado de otro modo de forma independiente antes de cambios importantes, preservar metadatos de copias, registrar las decisiones de restauración en un ticket y recopilar registros remotos de acciones allí donde existan de forma natural. No dependas de una cadena local como única prueba del historial. Una cadena local aporta evidencia sólida sobre los registros presentes en ese dispositivo. Una copia de seguridad permite revertir, que es su función. Ambos hechos coexisten. Los equipos necesitan otra referencia conservada cuando deban distinguir entre continuidad y un estado anterior reanudado más tarde. Prueba el caso incómodo en un entorno que no sea de producción. Crea algunos eventos de auditoría, realiza una copia de seguridad, crea más eventos, restaura el estado anterior y crea después un evento adicional. Pide a una segunda persona que recopile ambas continuaciones y explique la bifurcación sin usar la memoria del operador. Si el equipo no puede etiquetar las fuentes, verificar cada secuencia y conservar el límite en ese ejercicio, tendrá dificultades durante un incidente. Escribe una frase en el procedimiento de recuperación: una restauración que incluya estado de auditoría inicia un nuevo linaje de evidencia hasta que una revisión establezca lo contrario. Esa frase cambia la conducta del operador en el momento importante. Pide conservar la evidencia antes de reanudar el trabajo habitual y evita la ficción conveniente de que el registro posterior a la restauración reemplaza automáticamente lo anterior. ## Informa de dos historiales sin suavizar las partes difíciles Un hallazgo defendible nombra el registro compartido, identifica la fuente de cada continuación, expone por separado los resultados de verificación y describe qué evidencia externa ordena o no ordena los hechos. También debe distinguir una restauración demostrada de una restauración sospechada. El lenguaje puede seguir siendo sencillo: el material recopilado contiene dos continuaciones criptográficamente coherentes después del registro 500; los metadatos de copia sitúan un estado de auditoría anterior en el Mac; la evidencia no establece un único orden entre los descendientes sin más fuentes. No llames a una rama realidad alternativa, registro fantasma ni línea de tiempo duplicada. Esas expresiones hacen que una condición técnica suene dramática y dejan a los revisores preguntándose qué encontraste en realidad. Un historial de auditoría bifurcado ya es suficientemente serio. Significa que el registro local ya no ofrece una única relación ininterrumpida después de un punto conocido. La primera acción tras descubrirlo es sencilla: conserva la continuación original si todavía existe, antes de que el Mac restaurado escriba otro registro. Toda discusión posterior sobre verificación, marcas de tiempo y motivo depende de que esa segunda línea haya sobrevivido.