Análisis forense de mensajería: fundamentos

El análisis forense de mensajería consiste en recopilar, procesar, normalizar e interpretar comunicaciones, desde el correo electrónico y los SMS hasta las aplicaciones de chat y las herramientas de colaboración empresarial, para responder a preguntas de hecho: quién dijo qué a quién, cuándo, por qué canal, y qué se compartió, editó o eliminó por el camino.

Se sitúa en la intersección del análisis forense móvil, el análisis forense informático, el eDiscovery y la respuesta a incidentes. Un caso de compromiso del correo corporativo (BEC) necesita cabeceras de correo. Un caso de amenaza interna necesita Slack o Teams. Un caso de fraude necesita WhatsApp, Telegram y SMS, a menudo los tres para las mismas personas. La dificultad rara vez está en leer un mensaje aislado. Está en combinar cientos de miles de ellos, procedentes de formatos que discrepan en casi todo, en una única cronología defendible.

Esta guía cubre los fundamentos comunes a todas las fuentes: cómo se adquiere la evidencia, qué aspecto tiene un mensaje normalizado, cómo se codifican las marcas de tiempo, cómo se preserva la integridad, cómo se vinculan identidades y qué trampas atrapan incluso a peritos con experiencia.

Adquisición: tres vías, tres compromisos

El origen de los datos determina lo que contienen. Hay, a grandes rasgos, tres vías.

Exportaciones de la aplicación

La mayoría de las plataformas ofrecen una exportación para el usuario: «Exportar chat» de WhatsApp, la exportación JSON de Telegram Desktop, las exportaciones de espacio de trabajo de Slack, el paquete de datos de Discord, «Descargar tu información» de Meta, Google Takeout, la exportación de conversaciones de Skype, la exportación del historial de LINE.

• Ventajas: fáciles de obtener, a menudo con la colaboración del titular; no requieren acceso al dispositivo ni root; formato estructurado (JSON, CSV) o al menos texto predecible.
• Inconvenientes: el proveedor decide qué se incluye. Las exportaciones suelen omitir mensajes eliminados, historial de ediciones, confirmaciones de lectura e identificadores internos. Algunas son solo texto, con hora local del dispositivo y sin zona horaria. Muchas se limitan a lo que ve una sola cuenta.

Extracción del dispositivo y de bases de datos

La alternativa es obtener el almacén propio de la aplicación desde un dispositivo, una copia de seguridad o un perfil de escritorio: chat.db en macOS, sms.db de una copia de seguridad de iOS, msgstore.db y wa.db en Android, ChatStorage.sqlite en iOS, db.sqlite de Signal Desktop, viber.db de Viber, el antiguo main.db de Skype, mmssms.db para los SMS de Android.

• Ventajas: datos más ricos. Se obtienen identificadores internos de fila, estado de entrega y lectura, marcas de tiempo de edición, metadatos de adjuntos y, a veces, restos de registros eliminados en páginas libres o en registros de escritura anticipada (ficheros -wal).
• Inconvenientes: el problema es el acceso. Los almacenes móviles están tras el aislamiento del sistema operativo y a menudo cifrados: Signal Desktop usa SQLCipher, las copias de seguridad de WhatsApp Android están cifradas y el tdata de Telegram Desktop está cifrado en reposo. Además, los esquemas cambian entre versiones de la aplicación sin previo aviso.

Proveedor, vía judicial y eDiscovery

La tercera vía pasa por el operador del servicio: un requerimiento u orden judicial al proveedor, o una exportación administrativa desde el tenant que usted controla, como Microsoft Purview eDiscovery para Teams y Exchange, una exportación de Slack Enterprise Grid o Google Vault.

• Ventajas: cobertura completa del tenant, retención en el servidor (incluidos elementos que los usuarios borraron localmente, si hay políticas de retención) y una cadena de custodia clara desde una fuente autorizada.
• Inconvenientes: solo está disponible para la parte legitimada (empleador, fuerzas de seguridad, parte litigante), es lenta y llega en el formato del proveedor, que puede aplanar los hilos o presentar los chats como elementos similares a correos. Las exportaciones de eDiscovery de Teams, por ejemplo, representan los mensajes de chat como elementos .msg de clase IPM.SkypeTeams.Message.

En la práctica se combinan vías. Una exportación del usuario cubre huecos que una extracción del dispositivo no alcanza, y una exportación de eDiscovery corrobora lo encontrado en un portátil.

Un modelo de mensaje normalizado

Para situar un correo, una publicación de Slack y una línea de WhatsApp en la misma cronología, hay que proyectar cada fuente sobre un único esquema. La herramienta MessagingForensics usa los siguientes campos por mensaje; son una buena base para cualquier conjunto de herramientas:

Dos reglas de diseño son clave. Primero, no descarte nunca datos específicos de la fuente solo porque no encajen en una columna; guárdelos en un mapa extra para que un revisor pueda volver a ellos. Segundo, cada fila debe remitir al fichero de evidencia exacto y al parser que la produjo. Una entrada de cronología que no puede rastrearse hasta su origen es una afirmación, no una evidencia.

El zoológico de marcas de tiempo

Nada rompe una cronología de mensajería como el tiempo. Cada plataforma elige su época de referencia, su unidad y su convención de zona horaria, y a veces varias dentro de una misma base de datos. La tabla codifica el mismo instante, 2024-02-01 10:15:00 UTC, en cada formato.

Conocida la época, las conversiones son aritmética sencilla:

unix_seconds = cocoa_seconds + 978307200
unix_seconds = cocoa_nanoseconds / 1e9 + 978307200
unix_seconds = filetime / 1e7 - 11644473600

La herramienta aplica estas reglas y ajusta automáticamente la escala de los valores Unix: todo lo que supera 1e13 se reduce desde micro o nanosegundos, y todo lo que está por debajo de 1e11 se trata como segundos. Los valores que caen antes de 1990 o después de 2100 se rechazan por inverosímiles y la marca de tiempo queda vacía en lugar de inventarse. Esa salvaguarda importa: un cero, una confusión de columnas o un valor Cocoa leído como Unix producen fechas de 1970 o 2001 que parecen reales en un gráfico.

Los formatos de texto merecen especial desconfianza. Las exportaciones de texto de WhatsApp y LINE imprimen el reloj local del teléfono sin zona, y el orden de la fecha (día/mes o mes/día) depende de la configuración regional del dispositivo. Un valor como 03/04/2024 es ambiguo hasta que aparece en otro punto del fichero un día mayor que 12. La herramienta deduce el orden a partir de todo el fichero, muestra la hora local tal cual etiquetada como UTC y emite un aviso para que nadie la confunda con UTC real. Del mismo modo, las cadenas tipo ISO sin zona, como 2024-01-02 10:00:00, se leen como UTC, que es lo que quieren decir la mayoría de las exportaciones, aunque no todas. Anote su supuesto y la zona horaria configurada en el dispositivo.

El correo plantea el problema opuesto: cada cabecera lleva un desfase explícito, pero la cabecera Date: la escribe el cliente del remitente y puede contener cualquier cosa. La cadena Received:, sellada por cada servidor intermedio, es el reloj independiente con el que contrastar.

Integridad de la evidencia

La evidencia de mensajería es pequeña, mayoritariamente textual y trivial de modificar; por eso las prácticas de integridad deben ser rutinarias y constantes.

1. Calcule el hash antes de procesar. Calcule un hash criptográfico (SHA-256 es el estándar actual) de cada fichero tal como se recibió, antes de que ninguna herramienta lo abra. MessagingForensics empieza por ahí: cada fichero de entrada se somete a hash en el navegador antes de descomprimir archivos o procesar nada, y el hash figura en la tabla de evidencias y en los informes.
2. Trabaje sobre copias. SQLite, en particular, modifica sin reparos un fichero abierto en lectura-escritura: puede reproducir un diario -wal y consolidarlo en la base principal, destruyendo el estado anterior. Mantenga juntos el original, el -wal y el -shm, y procese copias.
3. Registre el parser y el formato de cada fichero. «Procesado como exportación de espacio de trabajo de Slack» o «Procesado como WhatsApp iOS (ChatStorage.sqlite)» debe figurar junto al hash. Si un fichero no se reconoció, dígalo explícitamente; las omisiones silenciosas son la forma en que los huecos pasan desapercibidos.
4. Conserve las rutas dentro de archivos. Los mensajes contenidos en un ZIP deben citar la ruta del miembro (export.zip!/Messages/c123/messages.json), no solo el archivo, para que un revisor encuentre los bytes exactos.
5. Procese en local siempre que pueda. Subir evidencias a un servicio de terceros crea una nueva copia que usted no controla. Un parser que se ejecuta en el navegador mantiene los datos en el equipo del perito.

Correlación de identidades entre plataformas

La misma persona aparece como +1 202 555 0143 en SMS, 12025550143@s.whatsapp.net en WhatsApp, jdoe en Slack, un snowflake numérico en Discord y j.doe@example.test en el correo. Los nombres visibles coinciden entre personas y cambian; los identificadores son el eje sobre el que pivotar.

Anclas útiles:

• Números de teléfono normalizados a E.164 (+12025550143). Los JID de WhatsApp, Signal, Viber, los identificadores de iMessage y las direcciones SMS se reducen a ellos.
• Direcciones de correo, en minúsculas. Vinculan correo, iMessage (identificadores de Apple ID), perfiles de Teams y Slack, y Google Chat.
• ID de usuario de las plataformas de los campos extra: ID U… de Slack, snowflakes de Discord, ID user… de Telegram. Sobreviven a los cambios de nombre.
• Indicadores compartidos en el contenido: la misma URL, cartera de criptomonedas o IBAN en varias plataformas suele ser el vínculo más sólido entre cuentas.

MessagingForensics extrae del texto y los asuntos de los mensajes URL, direcciones de correo, números de teléfono en formato internacional, direcciones IPv4, direcciones Bitcoin y Ethereum e IBAN, y cuenta cuántos mensajes contienen cada uno. Los patrones son deliberadamente conservadores: un número de teléfono debe empezar por +, por lo que no se capturan los números en formato nacional. Trate la lista como punto de partida para pivotar, no como un inventario exhaustivo. Las listas de vigilancia (palabras clave, una por línea) filtran después la cronología combinada hasta los mensajes relevantes.

Errores habituales

Almacenes cifrados. La base de datos de Signal Desktop está cifrada con SQLCipher; hace falta la clave del perfil para descifrarla antes de que un parser pueda leerla. Las copias de seguridad de WhatsApp Android (.crypt14, .crypt15) requieren el fichero de clave o la contraseña de la copia cifrada de extremo a extremo. La caché de Telegram Desktop está cifrada. Si solo tiene el fichero cifrado, la solución está en la adquisición, no en el procesamiento.

Exportaciones limitadas al titular. El paquete de datos de Discord contiene solo los mensajes que envió la cuenta solicitante, no el otro lado de la conversación. Las exportaciones de Messenger e Instagram reflejan lo que esa cuenta podía ver en el momento de exportar. Indique siempre desde qué perspectiva se ha hecho una exportación.

Mensajes eliminados. Las exportaciones rara vez los incluyen; las bases de datos a veces sí, como filas marcadas o en páginas no asignadas. Una marca de «eliminado» en el modelo normalizado significa que la fuente registró una eliminación. La ausencia de un mensaje no prueba nada sobre si existió.

Zonas horarias. Mezclar exportaciones de texto en hora local con marcas de tiempo UTC de bases de datos puede desplazar eventos varias horas y reordenar una conversación. Normalice todo a UTC, señale las filas que no se pudieron normalizar y anote los cambios de horario de verano del periodo.

Duplicados entre fuentes. El mismo mensaje puede aparecer en una exportación de WhatsApp, en msgstore.db y en el teléfono del interlocutor; el mismo correo en dos buzones y en un MBOX. Elimine duplicados por identificadores estables (Message-ID, ID de mensaje de la plataforma) cuando existan y, si no, por marca de tiempo más remitente más hash del texto, pero conserve todas las referencias de origen: un mensaje hallado en ambos dispositivos es una evidencia más sólida que uno hallado en uno solo.

Ediciones. Un mensaje editado puede conservar solo su texto final. Si la fuente registra una hora de edición, consérvela; si la plataforma guarda historial, estará en otra tabla u otro fichero.

Deriva de nombres visibles. Los contactos se renombran, los grupos cambian de título y las exportaciones imprimen el nombre vigente al exportar, no al enviar.

Próximos pasos

Pruebe el parser MessagingForensics: arrastre exportaciones o bases de datos al navegador y obtenga hashes SHA-256 de cada fichero, una cronología UTC unificada, los indicadores extraídos e informes CSV, JSON o HTML, sin subir nada.

Después, profundice por fuente (artículos en inglés):

• Análisis forense de cabeceras de correo
• Análisis forense de Microsoft Teams
• Análisis forense de exportaciones de Slack
• Análisis forense de WhatsApp
• Análisis forense del paquete de datos de Discord
• Análisis forense de chat.db (iMessage)