Desmitificación de técnicas de ransomware usando Ensamblados.net: Ensamblables EXE frente a DLL

En primera parte de esta serie, examinamos algunas técnicas utilizadas por el malware, ransomware especificamente. Como vimos, estas técnicas individuales como los descargadores, goteros y cargadores, así como la codificación y el cifrado son capacidades legítimas y programables que ofrece .Net (dot net) marco de software y muchos otros marcos de programación y lenguajes de código. A continuación se muestra un collage de algunas de las técnicas discutidas en el artículo anterior.

‍

En este segundo artículo, procederemos a examinar los fundamentos de los ensamblajes a través del marco de Microsoft .Net. Profundizaremos en las diferencias entre ensamblajes (EXE vs. DLL) y sus relaciones, lo que permite cómo estas capacidades se ejecutan eventualmente desde un código inicial de alto nivel como el código de programación C #. Utilizaremos el código introducido en el artículo anterior para explorar estas diferencias y relaciones.‍

¿Qué es Microsoft .Net?

Microsoft .Net es un marco de desarrollo de software diseñado para soportar varios lenguajes de programación y apuntar a diferentes sistemas operativos. Los lenguajes de programación soportados como C # (pronunciado C sharp) se compilan y ejecutan como lo que se conoce como código administrado (a diferencia del código no administrado o nativo). Para lograr esto, .Net ejecuta su código en una máquina virtual dedicada en lugar de hacerlo directamente a la plataforma de destino. Esta máquina virtual se conoce como .Net tiempo de ejecución de lenguaje común (CLR). Se puede pensar como el intermediario común que eventualmente ejecuta el código compilado o ensamblado de todos los diferentes lenguajes de programación, como C #, VB.Net y F #, que .Net apoyos. Este ejemplo a continuación muestra el código del lenguaje de programación C# del artículo anterior.

El código administrado significa que el código del lenguaje de programación C# de alto nivel anterior y otros como F # y VB.Net se compilan primero en un lenguaje intermedio (IL). El código de alto nivel C # que se muestra arriba compila las instrucciones de lenguaje intermedio que se muestran en la imagen de abajo. Este código se asemeja a la sintaxis de programación de ensamblajes de bajo nivel.

A continuación, este lenguaje intermedio (IL) se compila en código nativo o de máquina dirigido a la plataforma de máquina correspondiente. Esta compilación es realizada por otro .Net componente llamado compilador Just-in-Time (JIT).

El código nativo o de máquina es el conjunto de instrucciones (ceros y unos) que el procesador (CPU) de una computadora en particular entiende. Este último paso es administrado por Common Language Runtime (CLR), que también contiene el JIT. El CLR es el .Net entorno de ejecución o máquina virtual. Java es otro framework de software que utiliza el concepto de tiempos de ejecución intermedios. Similar a la Máquina Virtual Java, es una parte principal de lo que hace que el .Net plataforma independiente. .Net  el código se llama código administrado porque el código de programación es administrado por el CLR intermediario y no es ejecutado directamente por la CPU de la computadora.

Una ventaja del código administrado en .Net es administración automática de memoria y recolección de basura. Esto significa que el desarrollador no necesita preocuparse por asignar y desasignar memoria de computadora en su código para ahorrar recursos del sistema como en el caso de por ejemplo código C o C++. En .Net, existe el recolector de basura que se ejecuta periódicamente para manejar la memoria deslocalizada. También puede ser llamado por el programador cuando sea necesario. El siguiente diagrama muestra la arquitectura de un .Net aplicación.

Por el contrario, los no.Net compiladores como VB6, C y C++ compilan su código de alto nivel directamente en el código de máquina de la plataforma de destino (SO y CPU). Por lo tanto, el ejecutable o ensamblaje de código resultante está vinculado a la plataforma de máquina de destino del compilador. Esto también se conoce como código no administrado o nativo. Aunque arquitectónicamente diferente, es posible usar código de ensamblajes, especialmente DLL desarrolladas en código nativo en un .Net-aplicación administrada por medio de una capacidad conocida como Marshalling Interop (invocación de plataforma). Ejemplos de esto serán el uso de archivos DLL nativos del sistema operativo Windows o bibliotecas externas, como el código escrito en C ++, siendo referenciado en un sistema administrado .Net aplicación para permitir algunas funcionalidades de bajo nivel del sistema operativo. En este caso, .Net en sí mismo se puede pensar como un contenedor seguro alrededor de las DLL nativas en las que se basa el sistema operativo Windows y gran parte de las cuales están escritas en C ++.‍

¿Qué es un ensamble.Net?‍

Microsoft describe .Net ensamblajes como una sola unidad de implementación. Lo que esto significa es que un ensamblado es una colección de varios tipos de código y archivos asociados que se han compilado (ensamblado) en alguna forma que se puede ejecutar en cualquier compatible .Net plataforma de destino. La ejecución se realiza mediante .Net tiempo de ejecución de lenguaje común. Ejemplos de ensamblados en el sistema operativo Windows son archivos ejecutables (.exe) y archivos de biblioteca de clases o biblioteca de vínculos dinámicos (.dll).

Profundizando en la imagen de código de ejemplo a continuación, se muestra el ensamblaje ejecutable C # a la izquierda y otro código de ensamblaje DLL de C # (también conocido como biblioteca de clases) a la derecha. El código ejecutable hace referencia al archivo DLL y luego llama a un método específico (función) del código DLL durante la ejecución. Estas referencias y convocatorias han sido resaltadas en la imagen de abajo. Explicaremos los detalles de ambas piezas de código más adelante en este artículo. También mostraremos cómo esta combinación puede ser utilizada para objetivos maliciosos en esta serie.

En el siguiente ejemplo, el archivo DLL se hace referencia manualmente en el código ejecutable Esto significa que la DLL y la información relacionada sobre sus metadatos así como el código (hecho de módulos, clases y métodos) son referenciados durante el tiempo de compilación del código ejecutable.

Como biblioteca compartida, el código DLL no se puede ejecutar por sí solo directamente. Desde el punto de vista del código, esto se debe a que las DLL no tienen una función de punto de entrada principal para ejecutarse y, por lo tanto, no se pueden ejecutar como código independiente de la manera en que un código ejecutable (.exe) está configurado para hacerlo. Como ejemplo, el siguiente mensaje de error muestra las consecuencias de intentar ejecutar una biblioteca de clases o un archivo DLL directamente desde un compilador.

El código ejecutable, por otro lado, tendrá una función o método de punto de entrada principal donde comienza la ejecución, pero una DLL realmente no necesita una función de punto de entrada principal ya que es principalmente una biblioteca de bloques de código referenciados por otros ensamblajes.

Una vez referenciado, el código específico en el archivo DLL que es de interés puede ser llamado para su ejecución. Como se muestra en el artículo anterior, los ejemplos de código (EXE y DLL) a continuación reiteran este punto.

La aplicación ejecutable se ejecuta y llama al código de la DLL a la que hace referencia para producir la salida que se muestra en la siguiente imagen.

Este sencillo programa muestra cómo .Net ensamblajes como EXEs y DLL se pueden usar juntos.

El código DLL al que se hace referencia anteriormente tiene un método (función) que toma dos parámetros por entrada, un nombre y una edad, y luego muestra un mensaje de saludo utilizando esta información. El código ejecutable, por otro lado, ejecuta código que acepta detalles de entrada del usuario de nombre y edad desde la línea de comandos y luego pasa esa información al método DLL como argumentos o entradas. El mensaje del código DLL se vuelve a mostrar en la pantalla de la consola utilizando la información que la aplicación EXE recopiló del usuario. ‍

Análisis de ensamblados de.NET

‍La realización de un análisis estático en el ejecutable muestra las diversas referencias de DLL y otros componentes importados para su ejecución. Además de nuestra propia DLL personalizada, el ensamblado ejecutable también importa DLL adicionales asociadas con .Net en sí mismo como mscorlib que es una DLL que contiene código base (clases, tipos, etc.) y es algo que nuestro programa necesita para ejecutarse sin problemas.

En nuestro entorno de desarrollo de código Visual Studio, podemos confirmar el uso de mscorlib  rastreando sus orígenes en uno de los tipos de datos (en este caso, cuerda de System.String en .Net). Esto revela el .Net ensamblado donde se origina ese tipo que es mscorlib como se muestra a continuación.

String es un tipo de datos en términos de programación donde se almacena el texto que el usuario escribe y luego vuelve a mostrarse. También podemos ver en nuestro análisis estático la DLL llamada”DLL_DontNet_Assembly.” Esta es nuestra DLL personalizada que contiene el”Método DisplayMSG” método que muestra al usuario un mensaje después de haber ingresado sus datos.

En nuestro ejemplo, hicimos referencia y cargamos nuestra DLL personalizada manualmente durante la compilación de todo nuestro código antes de que el programa comenzara a ejecutarse. También es posible hacer referencia a una DLL durante la ejecución de un ejecutable. Esto puede ser especialmente útil en los casos en que es posible que no tengamos acceso a la DLL deseada durante la compilación de nuestro código. Este proceso se conoce como reflexión, y permite la capacidad de examinar un .Net ensamblaje (metadatos y atributos) y también para usar código (módulos, clases, métodos y propiedades) contenido dentro de él durante el tiempo de ejecución de nuestro programa. Esta técnica también puede ser ajustada por intención maliciosa en lo que se conoce como ataques de inyección DLL reflexivos.‍

.Net Los ensamblados (ejecutables y bibliotecas de clases) también consisten en un archivo de manifiesto que contiene metadatos sobre el ensamblado y el código de lenguaje intermedio (IL) que juntos permiten que el tiempo de ejecución del lenguaje común ejecute el ensamblado en cualquier plataforma compatible que pueda ejecutarse .Net. La imagen siguiente muestra las instrucciones de ensamblaje de IL y la estructura de manifiesto de los dos ensamblajes: EXE y DLL. El archivo de manifiesto contiene los metadatos sobre .Net ensamblaje como número de versión, descripción, etc.

Ahora deberíamos tener una comprensión fundamental de .Net entorno de software, sus ensamblajes asociados y cómo pueden interactuar entre ellos.

En el siguiente artículo, pondremos las técnicas y capacidades que hemos discutido y aprendido hasta ahora en un único ejecutable malicioso de ransomware.

Más información acerca de cómo la Segmentación de confianza cero de Illumio puede ayudarle a contener las brechas de ransomware.