Cómo le ayuda la Interfaz de detección de antimalware (AMSI) a defenderse del malware
Para obtener una introducción a la Interfaz de detección de antimalware (AMSI) de Windows, consulte Interfaz de detección de antimalware (AMSI).
Como desarrollador de aplicaciones, puede participar activamente en la defensa contra malware. En concreto, puede ayudar a proteger a sus clientes del malware basado en scripts dinámicos y de las vías no tradicionales de ciberataques.
Por ejemplo, supongamos que la aplicación admite scripts: acepta un script arbitrario y lo ejecuta a través de un motor de scripts. En el momento en que un script está listo para suministrarlo al motor de scripts, la aplicación puede llamar a las API de AMSI de Windows para solicitar un análisis del contenido. De este modo, podrá determinar con seguridad si el script es malicioso o no antes de decidirse a ejecutarlo.
Esto es así aunque el script se haya generado en tiempo de ejecución. Un script (malicioso o no), puede pasar por varias pasadas de desofuscación. Pero, en última instancia, es necesario suministrar al motor de scripts código simple y no ofuscado. Y ese es el punto en el que se invocan las API de AMSI.
Esta es una ilustración de la arquitectura AMSI, donde su propia aplicación está representada por uno de los cuadros "Otra aplicación".
La interfaz de AMSI de Windows está abierta. Esto significa que cualquier aplicación puede llamarla y que cualquier motor antimalware registrado puede procesar el contenido que se le envía.
Tampoco tenemos por qué limitar el debate a los motores de scripts. Quizá su aplicación sea de comunicación y analice los mensajes instantáneos en busca de virus antes de mostrárselos a sus clientes. O tal vez su software es un juego que valida los complementos antes de instalarlos. Existen multitud de oportunidades y escenarios para utilizar AMSI.
AMSI en acción
Veamos AMSI en acción. En este ejemplo, Windows Defender es la aplicación que llama a las API de AMSI. Pero puede llamar a las mismas API desde su propia aplicación.
Este es un ejemplo de un script que utiliza la técnica de codificación XOR para ocultar su intención (tanto si esa intención es benigna como si no). Para esta ilustración, podemos imaginar que este script se descargó de Internet.
Para hacer las cosas más interesantes, podemos introducir este script manualmente en la línea de comandos para que no haya ningún archivo real que supervisar. Esto refleja lo que se conoce como una "amenaza sin archivo". No es tan sencillo como analizar archivos del disco. La amenaza podría ser una puerta trasera que solo reside en la memoria de una máquina.
A continuación, vemos el resultado de ejecutar el script en Windows PowerShell. Verá que Windows Defender puede detectar el ejemplo de prueba de AMSI en este escenario complicado, simplemente mediante la firma de ejemplo de prueba de AMSI estándar.
Integración de AMSI con JavaScript/VBA
En el flujo de trabajo que se ilustra a continuación se describe el flujo de extremo a extremo de otro ejemplo, en el que se muestra la integración de AMSI con la ejecución de macros en Microsoft Office.
- El usuario recibe un documento que contiene una macro (maliciosa) que elude los análisis estáticos del software antivirus empleando técnicas como la ofuscación, archivos protegidos con contraseña u otras.
- A continuación, el usuario abre el documento que contiene la macro (maliciosa). Si el documento se abre en vista protegida, el usuario hace clic en Habilitar edición para salir de la vista protegida.
- El usuario hace clic en Habilitar macros para permitir que se ejecuten las macros.
- A medida que se ejecuta la macro, el entorno de ejecución de VBA usa un búfer circular para registrar [1] datos y parámetros relacionados con las llamadas a las API de Win32, COM y VBA.
- Cuando se observan API Win32 o COM específicas que se consideran de alto riesgo (también conocidas como desencadenadores) [2], se detiene la ejecución de la macro y el contenido del búfer circular se transfiere a la AMSI.
- El proveedor de servicios antimalware de AMSI registrado responde con un veredicto para indicar si el comportamiento de la macro es malicioso o no.
- Si el comportamiento no es malicioso, se procede a la ejecución de la macro.
- De lo contrario, si el comportamiento es malicioso, Microsoft Office cierra la sesión en respuesta a la alerta [3] y el antivirus puede poner el archivo en cuarentena.
¿Qué significa esto para usted?
Para los usuarios de Windows, cualquier software malicioso que utilice técnicas de ofuscación y evasión en los hosts de scripts integrados de Windows se inspecciona automáticamente en un nivel mucho más profundo que antes, lo que proporciona niveles adicionales de protección.
Para usted, como desarrollador de aplicaciones, considere la posibilidad de que la aplicación llame a la interfaz de AMSI de Windows si desea proteger a sus clientes con análisis y exploraciones adicionales de contenido potencialmente malicioso y beneficiarse de ellos.
Como proveedor de software antivirus, puede plantearse implementar la compatibilidad con la interfaz AMSI. Al hacerlo, el motor tendrá información mucho más detallada sobre los datos que las aplicaciones (incluidos los hosts de scripts integrados de Windows) consideran potencialmente maliciosos.
Más información general sobre las amenazas sin archivos
Puede que tenga curiosidad por saber más sobre los tipos de amenazas sin archivos contra las que la AMSI de Windows está diseñada para ayudarle a defenderse. En esta sección, echaremos un vistazo al tradicional juego del gato y el ratón que se desarrolla en el ecosistema del malware.
Usaremos PowerShell como ejemplo. Pero puede aprovechar las mismas técnicas y procesos que mostraremos con cualquier lenguaje dinámico: VBScript, Perl, Python, Ruby, etc.
A continuación se muestra un ejemplo de script de PowerShell malicioso.
Aunque este script simplemente escribe un mensaje en la pantalla, el malware suele ser más nefasto. Pero podría escribir fácilmente una firma para detectarlo. Por ejemplo, la firma podría buscar la cadena "Write-Host 'pwnd!' en cualquier archivo que abra el usuario. Genial: ¡Hemos detectado nuestro primer malware!
Sin embargo, tras haberlos detectado con nuestra primera firma, los autores de malware responderán. Responden creando scripts dinámicos como este ejemplo.
En ese escenario, los autores de malware crean una cadena que representa el script de PowerShell que se va a ejecutar. Pero usan una técnica de concatenación de cadenas sencilla para interrumpir la firma anterior. Si alguna vez consulta la fuente de una página web cargada de anuncios, verá muchos casos en los que se utiliza esta técnica para evitar el software de bloqueo de anuncios.
Por último, el autor del malware pasa esta cadena concatenada al cmdlet Invoke-Expression: el mecanismo de PowerShell para evaluar los scripts que se componen o crean en tiempo de ejecución.
En respuesta, el software antimalware comienza a realizar la emulación básica del lenguaje. Por ejemplo, si vemos dos cadenas concatenadas, emulamos la concatenación de esas dos cadenas y, a continuación, ejecutamos nuestras firmas en el resultado. Desafortunadamente, este es un enfoque bastante frágil, porque los lenguajes tienden a tener muchas formas de representar y concatenar cadenas.
Así que, después de que se detecten con esta firma, los autores de malware pasarán a algo más complicado, por ejemplo, codificar el contenido del script en Base64, como en el siguiente ejemplo.
Siendo ingeniosos, la mayoría de los motores antimalware implementan también la emulación de descodificación Base64. Así que, como también implementamos la emulación de descodificación Base64, llevamos ventaja por un tiempo.
En respuesta, los autores de malware recurren a la ofuscación algorítmica, como un simple mecanismo de codificación XOR en los scripts que ejecutan.
En este punto, generalmente estamos más allá de lo que los motores antivirus emularán o detectarán, por lo que no necesariamente detectaremos lo que este script está haciendo. Sin embargo, podemos empezar a escribir firmas contra las técnicas de ofuscación y codificación. De hecho, eso es lo que explica la gran mayoría de las firmas de malware basado en scripts.
Pero, ¿y si el ofuscador es tan trivial que se parece a muchos scripts con buen comportamiento? Una firma para ello generaría un número inaceptable de falsos positivos. Este es un ejemplo de script por fases que es demasiado benigno para detectarlo por sí mismo.
En este ejemplo, estamos descargando una página web e invocando contenido de la misma. Es el equivalente al script de Visual Basic.
Lo que empeora las cosas en estos dos ejemplos es que el motor antivirus inspecciona los archivos que abre el usuario. Si el contenido malicioso solo reside en la memoria, el ataque podría pasar desapercibido.
En esta sección se han mostrado las limitaciones de la detección mediante firmas tradicionales. Pero, aunque un script malicioso puede pasar por varias pasadas de desofuscación, en última instancia necesita suministrar al motor de scripts código sin formato y sin ofuscar. Y en ese momento, como hemos descrito en la primera sección, los hosts de scripts integrados en Windows llaman a las API de AMSI para solicitar un análisis de este contenido desprotegido. Y la aplicación puede hacer lo mismo.