Leer en inglés

Compartir a través de


Integración de la interfaz de examen antimalware (AMSI) con Microsoft Defender Antivirus

Se aplica a:

  • Microsoft Defender XDR
  • Antivirus de Microsoft Defender
  • Microsoft Defender para punto de conexión P1 & P2
  • Microsoft Defender para Empresas
  • Microsoft Defender para individuos

Plataformas:

  • Windows 10 y versiones posteriores
  • Windows Server 2016 y versiones más recientes

Microsoft Defender para punto de conexión utiliza la interfaz de examen antimalware (AMSI) para mejorar la protección contra malware sin archivos, ataques dinámicos basados en scripts y otras ciberamenazas no tradicionales. En este artículo se describen las ventajas de la integración de AMSI, los tipos de lenguajes de scripting que admite y cómo habilitar AMSI para mejorar la seguridad.

¿Qué es el malware sin archivos?

El malware sin archivos desempeña un papel fundamental en los ciberataques modernos, usando técnicas sigilosas para evitar la detección. Varios brotes de ransomware principales utilizaron métodos sin archivos como parte de sus cadenas de eliminación.

El malware sin archivos usa herramientas existentes que ya están presentes en un dispositivo en peligro, como PowerShell.exe o wmic.exe. El malware puede infiltrarse en un proceso, ejecutar código dentro de su espacio de memoria e invocar estas herramientas integradas. Los atacantes reducen significativamente su superficie y eluden los mecanismos de detección tradicionales.

Dado que la memoria es volátil y el malware sin archivos no coloca archivos en el disco, el establecimiento de la persistencia mediante el uso de malware sin archivos puede ser complicado. Un ejemplo de cómo el malware sin archivos logró la persistencia fue crear una clave de ejecución del Registro que inicia un cmdlet de PowerShell "one-liner". Este comando inició un script de PowerShell ofuscado que se almacenó en el BLOB del Registro. El script ofuscado de PowerShell contenía un cargador portable ejecutable reflectante (PE) que cargó un PE codificado en Base64 desde el registro. El script almacenado en el registro garantizaba que el malware persistía.

Los atacantes usan varias técnicas sin archivos que pueden hacer que los implantes de malware sean sigilosos y evasivos. Estas técnicas incluyen:

  • Inyección dll reflectante: la inyección de DLL reflectante implica la carga manual de archivos DLL malintencionados en una memoria de proceso sin necesidad de que dichos archivos DLL estén en el disco. El archivo DLL malintencionado se puede hospedar en una máquina remota controlada por atacantes y entregarse a través de un canal de red preconfigurado (por ejemplo, protocolo de seguridad de la capa de transporte (TLS) o incrustado en forma ofuscada dentro de vectores de infección, como macros y scripts. Esta configuración da como resultado la evasión del mecanismo del sistema operativo que supervisa y realiza un seguimiento de la carga de módulos ejecutables. Un ejemplo de malware que usa la inserción de DLL reflectante es HackTool:Win32/Mikatz!dha.

  • Vulnerabilidades de memoria: los adversarios usan vulnerabilidades de seguridad de memoria sin archivos para ejecutar código arbitrario de forma remota en las máquinas víctimas. Por ejemplo, la amenaza UIWIX usa la vulnerabilidad de seguridad EternalBlue, que usaron Petya y WannaCry, para instalar la puerta trasera DoublePulsar y se encuentra completamente en la memoria del kernel (tabla de distribución smb). A diferencia de Petya y Wannacry, UIWIX no coloca ningún archivo en el disco.

  • Técnicas basadas en scripts: los lenguajes de scripting proporcionan medios eficaces para entregar cargas ejecutables de solo memoria. Los archivos de script pueden insertar códigos de shell codificados o archivos binarios que pueden descifrar sobre la marcha en tiempo de ejecución y ejecutarse a través de objetos .NET o directamente con API sin necesidad de escribirlos en el disco. Los propios scripts se pueden ocultar en el registro, leer de secuencias de red o ejecutarse manualmente en la línea de comandos por un atacante, sin tocar nunca el disco.

    Nota

    No deshabilite PowerShell como medio para bloquear el malware sin archivos. PowerShell es una herramienta de administración eficaz y segura y es importante para muchas funciones del sistema y de TI. Los atacantes usan scripts malintencionados de PowerShell como técnica posterior a la explotación que solo puede tener lugar después de que ya se haya producido un compromiso inicial. Su uso indebido es un síntoma de un ataque que comienza con otras acciones malintencionadas como la explotación de software, la ingeniería social o el robo de credenciales. La clave es evitar que un atacante entre en la posición en la que puede usar PowerShell de forma incorrecta.

    Sugerencia

    Reducir el número de scripts de PowerShell sin firmar en el entorno ayuda a aumentar la posición de seguridad. Estas son instrucciones sobre cómo puede agregar la firma a los scripts de PowerShell usados en su entorno Hey, Scripting Guy! ¿Cómo puedo firmar scripts de Windows PowerShell con una PKI de Windows enterprise? (Parte 2 de 2) | Blog de scripting

  • Persistencia de WMI: algunos atacantes usan el repositorio instrumental de administración de Windows (WMI) para almacenar scripts malintencionados que, a continuación, se invocan periódicamente mediante enlaces WMI. Microsoft Defender Antivirus bloquea la mayoría del malware mediante detecciones genéricas, heurísticas y basadas en comportamiento, así como modelos de aprendizaje automático locales y basados en la nube. Microsoft Defender Antivirus protege contra el malware sin archivos a través de estas funcionalidades:

    • Detección de técnicas basadas en scripts mediante AMSI, que proporciona la capacidad de inspeccionar PowerShell y otros tipos de script, incluso con varias capas de ofuscación
    • Detección y corrección de técnicas de persistencia de WMI mediante el examen del repositorio WMI, tanto periódicamente como siempre que se observa un comportamiento anómalo
    • Detección de la inyección de DLL reflectante mediante técnicas mejoradas de análisis de memoria y supervisión del comportamiento

¿Por qué AMSI?

AMSI proporciona un nivel más profundo de inspección de software malintencionado que emplea técnicas de ofuscación y evasión en los hosts de scripting integrados de Windows. Mediante la integración de AMSI, Microsoft Defender para punto de conexión ofrece capas adicionales de protección contra amenazas avanzadas.

Lenguajes de scripting admitidos

  • PowerShell
  • Jscript
  • VBScript
  • Host de scripts de Windows (wscript.exe y cscript.exe)
  • .NET Framework 4.8 o posterior (examen de todos los ensamblados)
  • Instrumental de administración de Windows (WMI)

Si usa Aplicaciones Microsoft 365, AMSI también admite JavaScript, VBA y XLM.

AMSI no admite actualmente Python ni Perl.

Habilitación de AMSI

Para habilitar AMSI, debe habilitar el examen de scripts. Consulte Configuración de opciones de examen para Microsoft Defender Antivirus.

Consulte también CSP de directiva de Defender: Administración de cliente de Windows.

Recursos de AMSI

Las API de la interfaz de examen antimalware (AMSI) están disponibles para que los desarrolladores y proveedores de antivirus lo implementen.

Otros productos de Microsoft, como Exchange y Sharepoint , también usan la integración de AMSI.

Más recursos para protegerse frente a ataques sin archivos

  • Control de aplicaciones de Windows Defender y AppLocker. Aplica directivas de integridad de código seguro y permite que solo se ejecuten aplicaciones de confianza. En el contexto de malware sin archivos, WDAC bloquea PowerShell en modo de lenguaje restringido, lo que limita las características de lenguaje extendidas que pueden dar lugar a la ejecución de código no comprobable, como scripting directo de .NET, invocación de API win32 a través del cmdlet Add-Type e interacción con objetos COM. Esto básicamente mitiga los ataques de inyección de DLL reflexivos basados en PowerShell.

  • La reducción de la superficie expuesta a ataques ayuda a los administradores a protegerse frente a vectores de ataque comunes.

  • Habilite la protección basada en virtualización de la integridad del código. Mitiga las vulnerabilidades de seguridad de memoria del kernel a través de la integridad de código del hipervisor (HVCI), lo que dificulta la inserción de código malintencionado mediante vulnerabilidades de software en modo kernel.

Nota: El autor ha creado este artículo con ayuda de inteligencia artificial. Más información