El ransomware hace aproximadamente lo mismo en cada host, cada vez: enumerar archivos, leer cada uno, escribir una copia cifrada, eliminar el original. Cada paso aterriza en $MFT. Si conoces el aspecto de la forma, puedes confirmar que un incidente es una corrida de ransomware en minutos desde que tienes la MFT, sin encontrar nunca el binario ni leer la nota de rescate.
Este es el patrón, las variaciones que he visto y cómo separo el ransomware de otras formas de actividad masiva de archivos que se parecen superficialmente.
Las tres señales
Cambios masivos de extensión. Aparece un nuevo archivo con el mismo directorio padre y nombre base que un archivo existente, pero con una extensión diferente. report.docx se vuelve report.docx.locked, report.encrypted, report.crypted_{guid} o report.docx.[victim_id].lockbit. Contar cuántos pares así aparecen en una ventana corta es uno de los indicadores más limpios de ransomware en $MFT. Cientos en un minuto, en el perfil de un solo usuario o un share, es la firma.
Una ráfaga de marcas de tiempo SI creado de $STANDARD_INFORMATION agrupadas en segundos. La actividad normal de usuario crea archivos en arranques de uno o dos. El ransomware los crea a miles. Grafica las marcas SI creado como histograma a lo largo de la ventana sospechosa y la corrida de cifrado aparece como un pico vertical que ahoga la línea base. La anchura del pico te dice qué tan rápido corrió el ransomware (variantes modernas multihilo terminan el perfil de un usuario en menos de un minuto; las antiguas monohilo tardan más y el pico se extiende).
Originales eliminados coincidiendo con duplicados cifrados. Por cada report.docx.locked típicamente hay un report.docx correspondiente cuya bandera IN_USE está ahora limpia. El registro eliminado se queda en $MFT hasta que el slot se reutiliza. Puedes recuperar el nombre, los tamaños y las marcas de tiempo del original directamente del slot eliminado. Empareja esto con las razones FILE_DELETE de $UsnJrnl en la misma ventana y el orden de operaciones se vuelve inequívoco.
Variaciones que vale la pena conocer
No toda familia sigue el mismo patrón. Las variaciones que veo:
- Cifrado en su sitio. Algunas familias (variantes antiguas de Sodinokibi, ciertas builds de Conti) abren el archivo original, escriben los bytes cifrados de vuelta en el mismo archivo y renombran. No existe un archivo separado de "copia cifrada"; el patrón del original eliminado desaparece.
DATA_OVERWRITEde$UsnJrnlpara miles de archivos en un minuto sigue siendo ruidoso, y el renombrado deja un parRENAME_OLD_NAME/RENAME_NEW_NAME. - Cifrado intermitente. BlackCat y varias familias recientes cifran solo trozos del archivo (cada otro bloque de 100 KB, por ejemplo) para acelerar la corrida. El tamaño del archivo apenas cambia, la hora de modificación se actualiza, pero los clusters
$DATAestán en su mayoría intactos. Se ve más ligero en$MFTpero el diario USN aún muestra las escrituras. - Solo renombrado. Un puñado de wipers "ransomware falso" renombran archivos sin cifrarlos. El patrón MFT es idéntico al de una corrida de ransomware real; solo el análisis de contenido distingue los dos.
- Impacto en unidades de red. Muchas familias enumeran unidades mapeadas y cifran a través de la red. La MFT local muestra menos cambios de los que esperarías para un incidente real; la MFT del servidor de archivos lleva el grueso.
Notas de rescate
La mayoría de las familias dejan una nota de rescate en cada directorio afectado, con un nombre como HOW_TO_DECRYPT.txt, README_FOR_DECRYPT.html, restore-files.txt o una variante específica de marca. Las notas tienen contenido idéntico, tamaño idéntico y horas de creación agrupadas en la misma ventana que el cifrado. Recorrer la MFT buscando muchos archivos de texto o HTML de tamaño idéntico repartidos por muchos directorios padre a menudo los encuentra antes que cualquier patrón de nombre.
Las notas también son útiles forenseamente como línea base. Su hora de creación es esencialmente el sello "momento más temprano en el que el ransomware estuvo activo en este directorio". Si un directorio tiene una nota fechada 02:14 pero archivos cifrados fechados 02:09 en el mismo directorio, el ransomware enumeró y cifró antes de dejar la nota. Eso te dice algo sobre el flujo de la familia.
Lo que $MFT no te dice
La MFT confirma el qué y el cuándo. No te dice qué proceso hizo la escritura, por dónde entró el operador o cómo llegó el ransomware al host. Para eso:
- Prefetch, Amcache y Shimcache para evidencia de qué ejecutable corrió en la ventana.
- Sysmon Event ID 1 para creación de proceso con línea de comandos, padre y hashes.
- Security Event 4688 para creación de proceso si la auditoría de línea de comandos estaba habilitada.
- Diario USN
$Jpara el orden preciso de operaciones de abrir/leer/escribir/renombrar/eliminar archivos. - Volcado de RAM si la máquina aún está viva y el proceso de cifrado aún reside. A veces obtienes la clave de cifrado en memoria.
- Historial del navegador y artefactos de correo para el vector de acceso inicial.
La MFT por sí sola responde las preguntas operativas urgentes: cuándo empezó la corrida, qué tan extendida es y qué archivos fueron tocados. Eso es suficiente para tomar la decisión de recuperación. La atribución es un ejercicio separado que usa la MFT como un input.
La eliminación de VSS como pista
La mayoría de las familias de ransomware intenta borrar las Volume Shadow Copies antes de empezar a cifrar, porque las instantáneas VSS permitirían a la víctima restaurar sin pagar. El comando habitual es vssadmin delete shadows /all /quiet. Esto deja:
- Una entrada en el registro de eventos del sistema de Windows (
Event ID 8224para mensajes de servicio VSS). - Un Sysmon Event ID 1 para la invocación de
vssadmin.exesi Sysmon está desplegado. - El estado VSS fresco-pero-vacío en el host.
vssadmin list shadowsno devuelve nada o solo instantáneas posteriores al incidente.
Si ves un host sin instantáneas VSS y números de secuencia del registro MFT \$Extend\$UsnJrnl indicando recreación reciente, tienes preparación de ransomware aunque la corrida de cifrado todavía no haya empezado visiblemente. Mira VSS y $MFT para lo que aún podrías recuperar.
La secuencia de triage que sigo
- Saca
$MFTy$UsnJrnl:$Jdel host sospechoso (o de la instantánea, si VSS aún tiene una previa). - Parsea la MFT con MFTECmd o
mft_dump. Ordena SI creado descendente. Mira las 1.000 entradas más altas. - Si las entradas superiores se agrupan en una ventana de minutos y muchas tienen extensiones inusuales, tienes una huella de ransomware.
- Saca los registros eliminados correspondientes. Sus atributos
$FILE_NAMEte dan los nombres de archivo originales. Ahora sabes qué fue cifrado. - Cruza con el diario USN.
FILE_CREATEpara el archivo cifrado másFILE_DELETEpara el original en el mismo instante confirma el patrón. - Identifica la nota de rescate: un archivo pequeño con un nombre inusual (HOW_TO_DECRYPT, RECOVERY, README_RESTORE) apareciendo en muchos directorios a la vez. Su contenido nombra la familia.
- Pivota del nombre de la familia a IOCs conocidos: hashes de archivo, dominios C2, persistencia en el registro y artefactos de kill chain conocidos en tus otros logs.
Esa secuencia suele tomar menos de treinta minutos en un solo host y te da suficiente para decidir contención y empezar la planificación de recuperación.
Lecturas adicionales
- Los estudios de caso de ransomware de The DFIR Report. Cada escrito empareja evidencia de MFT y diario con el resto de la kill chain.
- Análisis técnicos de LockBit, BlackCat, Cl0p en The Record y Microsoft Security Blog. Las huellas MFT específicas de familia difieren en detalle.
- MITRE ATT&CK, T1486 Data Encrypted for Impact. El catálogo de técnicas de lo que hace el ransomware y los artefactos que cada comportamiento deja.