Problema

En entornos Windows con privilegios de administrador, el filtro Bind Filter permite crear enlaces de ruta que hacen que cualquier proceso que cargue un archivo específico reciba una versión alterada. Tres variantes – File‑Binding, Process‑Binding y Silo‑Binding – pueden engañar a defensas basadas en rutas (AppLocker, EDR user‑mode sensors, Sysmon) sin necesidad de drivers vulnerables ni exploits. El resultado típico es que la solución de seguridad muestra la ruta “legítima” mientras ejecuta código malicioso, o que la redirección solo ocurre dentro de un contenedor (silo) y permanece invisible fuera de él. Cuando el host ya está comprometido, estas técnicas se convierten en “EDR killers” que facilitan la persistencia y la escalada a SYSTEM.

Causa

El comportamiento se basa en la capacidad del Bind Filter para registrar una tabla de enlaces (bind‑link) en el registro bajo HKLM\System\CurrentControlSet\Control\Filter\BindLinks. Cada entrada asocia un target path con un link path. Cuando el kernel resuelve una ruta, consulta esa tabla antes de acceder al disco. Las variantes surgen de cómo se elige el target:

  • File‑Binding: el objetivo es un DLL o archivo que la EDR carga de forma explícita (por ejemplo amsi.dll). El atacante coloca su propio DLL bajo la ruta enlazada; cualquier proceso que intente cargar la original recibe la versión maliciosa.
  • Process‑Binding: el objetivo es el ejecutable de un proceso. El filtro altera la ruta que el kernel devuelve a los callbacks de creación de proceso, de modo que herramientas como Process Explorer o Sysmon reporten un nombre distinto al archivo realmente ejecutado.
  • Silo‑Binding: el enlace se marca como “silo‑scoped”. Dentro de un contenedor, la resolución sigue el enlace; fuera del silo, la tabla se ignora. Esto permite que la misma ruta apunte a malware dentro del contenedor y a la versión limpia en el host, evadiendo políticas globales.

Los pre‑requisitos son simples: el atacante necesita privilegios de administrador para escribir en el registro y crear los enlaces. No se requiere vulnerabilidad de kernel ni código de bajo nivel.

Solución

La defensa se divide en detección y remediación. La estrategia funciona tanto en hosts tradicionales como en máquinas que ejecutan contenedores.

El registro de enlaces es la única fuente de verdad. Un script de PowerShell que recorra HKLM:\SYSTEM\CurrentControlSet\Control\Filter\BindLinks y compare cada clave con la existencia del archivo enlazado permite identificar enlaces sospechosos.

2. Validar integridad de los archivos críticos

Para cada ruta objetivo que aparezca en la tabla, calcular un hash (SHA‑256) y compararlo con una lista de valores esperados (por ejemplo, hashes oficiales de amsi.dll, MsMpEng.exe). Cualquier desviación indica un posible File‑Binding o Process‑Binding.

Aplicar una política de AppLocker o una regla de Windows Defender Application Control (WDAC) que requiera que solo cuentas de servicio específicos puedan escribir en HKLM\System\CurrentControlSet\Control\Filter\BindLinks. Esto bloquea la fase de implantación.

4. Monitorear callbacks de creación de proceso

Sysmon con la configuración EventID 1 ya captura la ruta del proceso y el ImageLoaded del módulo. Añadir una regla de correlación que compare la ruta reportada con la ruta real del archivo en disco (usando Get-Item en PowerShell) permite detectar Process‑Binding en tiempo real.

5. Aislar contenedores con políticas de filtro de silo

En entornos Docker/Windows Containers, habilitar la opción --isolation=process y aplicar una política de WDAC que niegue cualquier Bind Link marcado como “silo‑scoped” a menos que provenga de una firma confiable. Esto elimina la ventaja de Silo‑Binding.

6. Limpieza automática

Una vez identificado un enlace malicioso, eliminar la clave del registro y restaurar el archivo original desde una copia de respaldo conocida. Automatizar este paso con un script de PowerShell que recorra la tabla, elimine entradas sospechosas y copie los binarios limpios.

Cuándo aplicar esta solución

  • Síntomas: Sysmon muestra procesos con rutas inconsistentes, AppLocker bloquea archivos que aparentemente ya están permitidos, o los sensores de EDR reportan fallos de carga de DLL sin razón aparente.
  • Entorno: Hosts Windows con privilegios de administrador concedidos a usuarios o procesos de terceros; máquinas que ejecutan contenedores Windows (silos) y que dependen de políticas basadas en rutas.
  • No aplica: Sistemas donde no se usan EDR o no se confían en políticas de ruta; entornos Linux, ya que el Bind Filter es exclusivo de Windows.

Código

# PowerShell one‑liner para listar todas las Bind Links y su destino
Get-ChildItem -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Filter\BindLinks' |
  ForEach-Object {
    $target = $_.GetValue('Target')
    $link   = $_.GetValue('Link')
    [PSCustomObject]@{
      Key    = $_.PSPath
      Target = $target
      Link   = $link
      Exists = Test-Path $link
    }
  } | Format-Table -AutoSize

Verificación

  1. Ejecutar el script anterior y revisar que Exists sea True solo para rutas oficiales (por ejemplo C:\Windows\System32\amsi.dll).
  2. En caso de detección, borrar la clave con Remove-Item -Path <KeyPath> -Force.
  3. Reiniciar el servicio afectado (por ejemplo Restart-Service -Name windefend para Defender) y confirmar que los logs de Sysmon vuelvan a mostrar la ruta real del ejecutable o DLL.
  4. Ejecutar una prueba de carga de la DLL objetivo ([System.Runtime.InteropServices.Marshal]::LoadLibrary('C:\Windows\System32\amsi.dll')) y observar que no se genera error de firma.

Notas adicionales

  • La tabla de Bind Links no se replica en el registro de 32‑bit bajo Wow6432Node; si el entorno incluye aplicaciones de 32 bits, inspecciona también esa rama.
  • En entornos con múltiples contenedores, cada silo mantiene su propia vista de la tabla. Asegúrate de ejecutar la auditoría dentro de cada contenedor si la política de aislamiento es process.
  • Algunas soluciones de EDR ya incluyen detección de Bind Links, pero la mayoría solo alerta cuando el enlace se crea, no cuando ya está activo. Mantener un script de auditoría periódico (por ejemplo, mediante Task Scheduler) cubre ese vacío.
  • Restaurar los binarios desde una copia de seguridad firmada evita falsos positivos en la validación de hashes.