Análisis de ingeniería inversa del troyano AntiCloud

Análisis de malware

Análisis de ingeniería inversa del troyano AntiCloud

noviembre 2, por Giuseppe Bonfa

Introducción

En este artículo vamos a hablar sobre el troyano Anticloud, también conocido como TrojanDropper:Win32/Bohu.A y variante B. Este malware se originó en China y fue diseñado para atacar la tecnología basada en la nube de los principales proveedores antivirus chinos. Por este motivo, a Bohu también se le ha denominado troyano AntiCloud .

Este es el primer malware dirigido específicamente a tecnologías basadas en la nube y probablemente marcará una tendencia. A medida que más corporaciones y gobiernos trasladen aplicaciones y servicios a la nube, ésta se convertirá en un objetivo cada vez más importante para los desarrolladores de malware. Podemos esperar malware sofisticado que ataque a los clientes y se integre en aplicaciones basadas en la nube, potencialmente sin que el usuario pueda determinar que el servicio basado en la nube está comprometido.

Este troyano presenta algunas características interesantes, como:

Algunos de los proveedores de antivirus a los que se dirige son Kingsoft, Qihoo y Rising.

Según Microsoft Malware Protection Center, Bohu es la primera ola de troyanos dirigidos a antivirus basados ​​en la nube.

Puede encontrar un buen resumen del atractivo global de Bohu aquí: http://blogs.technet.com/b/mmpc/archive//01/19/bohu-takes-aim-at-the-cloud.aspx

El alcance

Trojan.Bohu actúa esencialmente como una puerta trasera que monitorea el tráfico web de la víctima a través de varios motores de búsqueda. Bohu también llega a un servidor malicioso y descarga componentes y configuraciones adicionales.

Anatomía genérica de los ejecutables de Trojan.Bohu

El vector de infección es un archivo .exe ejecutado por la víctima mediante un ataque de ingeniería social clásico . Cada análisis basado en ingeniería inversa comienza con la inspección de las características genéricas del binario con el que estamos tratando. En nuestro caso, como debería ser obvio, tenemos que comprobar la Anatomía PE de nuestra muestra.

Para este tipo de tarea, utilizo CFF Explorer.

MD5: 179743623A423D5239B91E6A343FAC23
SHA-1: D40874EE670EB87F0D60AA083B40EABB45F0
Información del archivo: Nullsoft PiMP Stub - SFX
Tamaño del archivo: 2,13 MB (2229512 bytes)


La información del archivo indica claramente el código auxiliar de Nullsoft PiMP . Esto significa que la aplicación está comprimida (empaquetada) con tecnología NSIS ( Nulsoft Scriptable Install System ), un sistema profesional de código abierto para crear instaladores de Windows .

De la información básica, veamos ahora información más específica sobre su Geometría PE. Aquí está la entrada de encabezados de sección :

El punto de entrada pertenece a la sección .text y .ndata pertenece al instalador de Nullsoft. Además, también puede ver la presencia de una Sección de Recursos, por lo que ahora tenemos que verificar el contenido del Directorio de Recursos.

Como puede ver, la aplicación tiene incrustada una imagen que la hace parecer una aplicación legítima. Esta es la primera técnica básica de ingeniería social utilizada para engañar a los usuarios comunes.

→ ID DE IDIOMA

La ID de configuración regional/idioma proporciona información adicional que podría ayudarnos a establecer los orígenes de un determinado ejecutable. Para cada País existe un ID unívoco para identificarlo. Aquí hay una lista: http://msdn.microsoft.com/en-us/goglobal/bb964664

Pero es importante aclarar que este método de Identificación del Origen de la Amenaza no es 100% seguro, ya que depende del lenguaje de PC utilizado por el usuario (atacante).

En concreto, en este caso descubriremos que Lang ID 1033 pertenece únicamente al infectador principal. Dentro del ejecutable caído, observaremos otra identificación.

Extracción de archivos NSIS y análisis adicional de archivos

Como se indicó anteriormente, la muestra se entrega como Windows Installer , empaquetada y comprimida con tecnología NSIS . Ahora necesitamos estudiar la estructura de este paquete y eliminar todos sus archivos.

Es bastante fácil descomprimir una aplicación NSIS. Todo lo que se necesita es un administrador de archivos como 7Zip .

Examinemos el contenido abriendo el ejecutable con la aplicación 7Zip:

Como puede ver, tenemos 4 entradas de directorio:

Ahora podemos examinar el contenido de cada directorio:

EXEDIR contiene:

Hay dos pistas importantes: primero, la presencia de otro ejecutable llamado uuse-5905.exe . El segundo es una marca de tiempo que nos da una indicación clara del período en el que este paquete fue modificado por última vez.

NSIS también tiene una amplia gama de complementos para realizar diversas tareas de instalación. PLUGINSDIR, como su nombre indica, es el directorio contenedor de estas DLL. En nuestro caso, tenemos nsExec.dll

Los complementos se pueden investigar fácilmente consultando el siguiente sitio web: http://nsis.sourceforge.net/Category:Plugins

PLUGINSDIR contiene System.dll , que es el componente principal de NSIS.

SHELL[17] contiene otro directorio llamado ‘baidu’ y dentro de este:

Tenemos más archivos ejecutables: msfsg.exe y dsop7.xml (que es un archivo cifrado).

Finalmente está el directorio TEMP que contiene algunos complementos:

Descripción general de los componentes de la primera capa

Como se muestra en el párrafo anterior, el dropper principal contiene también dos ejecutables:

Claramente también necesitamos inspeccionar estos ejecutables.

Análisis uuse-5905.exe

MD5: 6158AFB0A85C29748126B2F49E34C1B6
SHA-1: 01D7FF02315E53FC4E9076BA31223E10E159
Información de archivo: Nullsoft PiMP Stub - SFX
Tamaño del archivo: 749,66 KB (767648 bytes)

Debido a que este ejecutable está incrustado dentro del cuentagotas principal, mantiene las marcas de tiempo originales. Vamos a enumerarlos:

Creado: domingoe marzo de, 13.18.18 Modificado: lunes 19 de julio de, 19.2


Desde el Directorio de recursos, podemos ver nuevamente que la aplicación tiene algún elemento de una aplicación pierna:

Como probablemente ya habrás notado, este ejecutable nuevamente incluye NSIS. Sería trivial ahora obtener información adicional de él.

Extraigamos e inspeccionemos su contenido.

Como es habitual, PLUGINSDIR contiene una dll y algunos archivos de instalación que no son relevantes para nuestro análisis. Además, hay otro ejecutable llamado UUPlayer.exe , además de un archivo main.ini que contiene la siguiente cadena.

[SETUP]

url=kvsq=10wx/84y0mfw1jpgfw0kvl

Ahora es el momento de observar las características genéricas de este ejecutable recién creado.

Descripción general del componente UUPlayer.exe

Ya no tenemos que lidiar con un ejecutable de NSIS, podemos redescubrir algunos elementos vistos anteriormente en el dropper principal.

MD5: E7AA331D4F8669C531FBDF559DBC99FF
SHA-1: A0E19AA2CAFC29064F0D950426504A72FC03568B
Información de archivo: Microsoft Visual C++ 8
Tamaño del archivo: 685,00 KB (701440 bytes)


Finalmente, echemos un vistazo a los Recursos:

Tenemos la misma imagen del infector base, pero esta vez la identificación del idioma cambia en .

Chino – República Popular China →

De la consulta de la lista Lang ID llegamos a otra confirmación del origen chino de este troyano .

El objetivo esencial de este ejecutable insertado es engañar a la víctima, que verá una aplicación de reproductor multimedia legítima durante esta infección de malware.

Descripción general de msfsg.exe

Ahora procedemos al ejecutable final a inspeccionar, contenido en SHELL[17]baidu

MD5: 308BF66610B82E2E1D8A982B0A111FA6
SHA1: 2BE86869D33A5098F8C2FE68A33EB55EE1774AE7
Información de archivo: Microsoft Visual C++ 8
Tamaño del archivo: 361,00 KB (369664 bytes)


Este ejecutable no está empaquetado en NSIS y nuevamente revela sus orígenes chinos ( LangID ).

Como recordarás, también tenemos un archivo cifrado en el mismo directorio, dsop7.xml . Este es un recurso comprimido que será descomprimido por el ejecutable msfsg.

Descripción general global del instalador

Cuando tratamos con malware basado en instaladores, debemos seguir dos puntos esenciales para perfilar el comportamiento global de esta aplicación maliciosa:

  1. Identifique todos los componentes eliminados por el instalador.
  2. Identificar secuencias de operaciones en el momento de la instalación.

Ya hemos realizado la primera tarea enumerando todos los elementos. Ahora necesitamos establecer y esquematizar su flujo de ejecución.

Las secuencias de ejecución del instalador se pueden perfilar de dos maneras:

El primer enfoque implica realizar un seguimiento de todos los procesos creados en el momento de la instalación: revelar, por ejemplo, todos los puntos de interrupción en los que se llama a la función CreateProcess() . Pero este enfoque es demasiado lento.

Existe un enfoque más rápido que nos permitirá rastrear más fácilmente operaciones adicionales realizadas por el instalador, como archivos creados , escritos , registro y operaciones de red . (Podemos llegar al mismo punto con el enfoque de depuración, pero esto implica colocar más puntos de interrupción y, por lo tanto, lleva más tiempo).

Seguiremos la supervisión de API utilizando la herramienta iDefense SysAnalyzer diseñada específicamente para monitorear las API más comunes que utilizan malware.

Análisis de registros de SysAnalyzer

Después de ejecutar nuestro ejemplo en un entorno controlado (máquina virtual), podemos guardar un registro de todas las actividades de la API.

Ahora vamos a perfilar el proceso de instalación de malware mediante el análisis de registros , que también proporcionará sugerencias valiosas para obtener información adicional.

40562e CreateFileA(C:ToolsBohumalwaremalware.exe)
403083 Leer archivo()
402dc2 GlobalAlloc()
405841 RegOpenKeyExA (HKLMSoftwareMicrosoftWindowsCurrentVersion)
40562e CrearArchivoA(C:Programmibaidudsop7.xml)
403042 Escribir archivo(h=218)
40562e CreateFileA(C:Programmibaidumsfsg.exe)
402fbf Escribir archivo(h=218)
40562e CreateFileA(C:ToolsBohumalwareuuse-5905.exe)
402fbf Escribir archivo(h=7/p>
40562e CreateFileA(C:Programmibaiduuninst18.exe)
4026c4 GlobalAlloc()
4026e0 GlobalAlloc()
40272f Escribir archivo (h = 710)
403042 Escribir archivo(h=710)


Es bastante fácil captar el orden de creación del archivo, lo que nos brinda pistas valiosas adicionales. Los archivos maliciosos se colocan en la ruta %Programsbaidu . A partir de la correlación de los nombres de archivos conocidos y la ruta descubierta, podemos producir evidencia de infección.

Prosigamos el análisis de registros:

4051b6 CreateProcessA((nulo),C:ToolsBohumalwareuuse-5905.exe,0,(nulo))2111b7 Copiar (C:DOCUME~1evilcryIMPOST~1Tempnsc4.tmpnsExec.dll-C:DOCUME~1evilcryIMPOST~1Tempnsc4.tmpns5.tmp)

El primer proceso creado pertenece a uuse-5905.exe , que contiene la aplicación engañosa de reproducción multimedia.

4051b6 CreateProcessA((nulo),C:ToolsBohumalware uuse-5905.exe ,0,(nulo))2111b7 Copiar (C:DOCUME~1evilcryIMPOST~1Tempnsc4.tmpnsExec.dll-C:DOCUME~1evilcryIMPOST~1Tempnsc4.tmpns5.tmp)


Netsh es una utilidad de línea de comandos que le permite mostrar o modificar la configuración de red de una computadora que se está ejecutando actualmente.

-c: cambia el contexto netsh especificado .

En nuestro caso, Netsh se utiliza para volcar nuestra configuración de IP actual en un archivo llamado ipconfig.txt.

7c81628b Esperar para un solo objeto (70,64)
10001a11 Esperar para un solo objeto (8c, ffffffff)
4051b6 CreateProcessA((nulo),msfsg.exe descomprimir -s dsop7.xml -d setup109807.exe,0,(nulo))
76bb183b Memoria de proceso de lectura (h = 590)
76bb185a Memoria de proceso de lectura (h = 590)


Esta es una pista muy importante que nos permite entender dos cosas:

El archivo descomprimido es un ejecutable llamado setup109807.exe. Ahora podemos descomprimir este archivo y monitorear lo que produce setup109807.exe con el mismo enfoque API Spy.

Setup109807.exe API Espía

40562e CreateFileA(C:Programmibaidusetup109807.exe)
40562e CreateFileA(C:Programmibaidusiglow.dll)
40562e CreateFileA(C:Programmibaidudsetup.exe)
40562e Crear archivo A (C:Programmibaidusiglow.sys)
40562e CreateFileA(C:Programmibaidumpflt_m.inf)
40562e CreateFileA(C:Programmibaidumpflt.inf)
40562e CreateFileA(C:Programmibaidunewnetgar.dll)
40562e CreateFileA(C:Programmibaiduspass.dll)
40562e CreateFileA(C:ProgrammibaiduSysDat.bin)
40562e CreateFileA(C:Programmibaiduuninst13.exe)


Este ejecutable coloca varios archivos nuevos en el sistema:

Tenga en cuenta que también tenemos un componente de modo kernel , siglow.sys. Además , NSIS produce una aplicación de desinstalación llamada uninst13.exe .

El sistema de evasión de hash

Podemos aislar las siguientes operaciones realizadas en los archivos recién eliminados:

4051b6 CreateProcessA((nulo),msfsg.exe md5 -s dsetup.exe -d dsetup.exe,0,(nulo))
4051b6 CreateProcessA((nulo),msfsg.exe md5 -s newnetgar.dll -d newnetgar.dll,0,(nulo))
4051b6 CreateProcessA((nulo),msfsg.exe md5 -s spass.dll -d spass.dll,0,(nulo))
4051b6 CreateProcessA((nulo),msfsg.exe md5 -s siglow.sys -d siglow.sys,0,(nulo))
4051b6 CreateProcessA((nulo),msfsg.exe md5 -s siglow.dll -d siglow.dll,0,(nulo))


As is clear, msfsg.exe is a core component used for a number of support operations.This time, it uses the MD5 functionality in the following way:

msfsg.exe MD5
Source → File Destination → File

This is the first Defensive feature of Trojan.Bohu, the Hash Evasion.

By Appending GarbageData at the end of the file, this will change the MD5 hash signature of the malicious file. In so doing, all hash based checks will be deceived.

Final Installation Phase

After hash alteration let’s see what the executables are called:

4051b6       CreateProcessA((null),rundll32.exe C:WINDOWSsystem32nethome32.dll RundllInstall NetHomeIDE,0,(null))
10002af4     RegOpenKeyExA (HKLMSYSTEMCurrentControlSetServicesNetHomeIDE)
10002b21     RegCreateKeyA (Parameters)
77f6d5f4     RegCreateKeyExA (Parameters,(null))
10002ba2     RegSetValueExA (ServiceDll)

nethome32.dll is the previously created newnetgar.dll, renamed, copied and successively installed as Service.

4051b6 CreateProcessA((null),C:Programmibaidudsetup.exe install,0,(null))


dsetup.exe installs the NDIS protection system, that is composed by:

4051b6     CreateProcessA((null),C:Programmibaidudsetup.exe install,0,(null))


The user deception application is executed.

Global View

In this chart, you can see entire look of Bohu Infection. The Global View is especially handy during the Analysis Process if designed with the aim to identify components that don’t need additional investigations as well as ones that need in-depth analysis.

As you can see, UUPlayer.exe represents the endpoint of the first branch but doesn’t present any other particular implications. Otherwise, setup109807 produces a wide range of elements that need to be further inspected.

Next, we’ll work on these executables.

Synthesis of Forensic Evidences of Infection Produced

We now have a clear view of the major modifications produced by Trojan.Bohu , on the system. This allow us to produce a certain number of elements that can lead univocally to the identification of an infected system.

File Modification →

Registry Modification →

Mutex Opened →

Network Activity →Window showing the infected victim:

User Mode Component siglow.dll

siglow.dll is the first of a two system components used by the trojan to protect itself from Cloud-Based Antiviruses.

Let’s disassemble this dll and inspect Exported Functions.

The most interesting function is DllRegisterServer. According to this, siglow is going to register a server DLL.

Let’s take a look at the Graph of Function Calls.

There are a certain number of function chunks, →

In this case, it will be much easier to analyze the component by starting with String Observation before coming back to the code via X-Refs.

As you recall, ms_siglow.inf is a file dropped by setup109807 installer.

[Version]
signature  = "$Windows NT$"
Class      = Net
ClassGUID  = {4d36e972-e325-11ce-bfc1-08002be10318}
Provider   = %Msft%
DriverVer  = 03/17/,5.00..1
[netsfltMP.AddService]
DisplayName    = %netsfltMP_Desc%
ServiceType    = 1
StartType      = 3
ErrorControl   = 1
ServiceBinary  = %12%siglow.sys
LoadOrderGroup = PNP_TDI
AddReg         = netsfltMP.AddService.AddReg


It’s interesting to note the ClassGUID value. Aquick search reveals that {4d36e972-e325-11ce-bfc1-08002be10318} represents the class of network adapter devices that the system supports. We will see in the kmode component analysis paragraphs exactly why this value is used.

Using X-Ref navigation, we land to sub_404A11 (renamed in InstallInf). It copies a specified .inf file to the %windir%/Inf directory by way of SetupCopyOEMInf. Going a step up via cross refs:

GetVersionEx retrieves information about the current operating system. The corresponding Major and Minor Version can be seen here:http://msdn.microsoft.com/en-us/library/ms724833%28v=vs.85%29.aspx

This means that the Inf file will be installed only under certain conditions.

Returning to string inspection, the next entry catching our attention is:

SystemCurrentControlSetServicesnetsfltParameters

This string is clearly derived from Registry Key Operations referring to the management of the NDIS filter (analyzed below).

There is not much to say about this dll. It’s the usermode installation component for siglow.sys, whose sole purpose is to driver (service) management tasks.

→ Produces Forensics Evidences

Finally, this curiosity: the dll is delivered with debugging informations. Here’s a path that shows where the coder is used to develop this component:

E:passthrusiglownotifyobobjfrei386siglow.pdb

Kernel Mode Component siglow.sys

Between the various executables dropped by setup109807, we also have this Kernel Mode component responsible for the second feature mentioned in the introduction, Packet Interception and Deny, if the request is directed to Antivirus Servers.

Its relative User Mode component is siglow.dll.Let’s start by disassembling the siglow.sy and locating DriverEntry() function:

At first glance, we can immediately see the nature of the component. This is a NDIS ( Network Driver Interface Specification )-based driver. NDIS defines the standard interface between hardware drivers for devices such as network cards and the windows network subsystem. Windows uses NDIS to communicate with these devices.

Network cards communicate packets received upward to the TCP/IP Stack through NDIS, and the TCP/IP stack sends packets out to the network by communicating with network card drivers through NDIS.

Additional information about NDIS architecture can be found here:http://msdn.microsoft.com/en-us/library/ms817945.aspx

It’s become clear that by working with NDIS technology, we have extremely low level access to network functionalities of the OS. This means that we can accomplish a wide range of operations, including Packet Interception.

The first function called is NdisAcquireSpinLock. It acquires a spin lock so that the caller gains exclusive access to the resources shared among driver functions that the spin lock protects.

Immediately after, we have NdisInitializeWrapper. According to MSDN, this is an obsolete function, so we must look for the NdisMInitializeWrapper.

VOID NdisMInitializeWrapper(
  __out  PNDIS_HANDLE NdisWrapperHandle,
  __in   PVOID SystemSpecific1,
  __in   PVOID SystemSpecific2,
  __in   PVOID SystemSpecific3
);


This notifies NDIS that a new miniport driver is initializing. The most important parameter for our analysis is NdisWrapperHandle:, a pointer to the caller-supplied variable in which NDIS returns a handle representing itself.

NdisIMRegisterLayeredMiniport

This defines the function:

NDIS_STATUS
  NdisIMRegisterLayeredMiniport(
    IN NDIS_HANDLE  NdisWrapperHandle,
    IN PNDIS_MINIPORT_CHARACTERISTICS  MiniportCharacteristics,
    IN UINT  CharacteristicsLength,
    OUT PNDIS_HANDLE  DriverHandle
    );


This function registers an intermediate driver’s miniport entry points.

As noted, there is a sequence of mov dword, offset; these instructions belongs to NDIS_MINIPORT_CHARACTERISTICS, by inspecting its members we can obtain additional information about this component.

typedef struct _NDIS_MINIPORT_CHARACTERISTICS {
    UCHAR MajorNdisVersion;
    UCHAR MinorNdisVersion;
    UINT Reserved;
    W_CHECK_FOR_HANG_HANDLER CheckForHangHandler;
    W_DISABLE_INTERRUPT_HANDLER DisableInterruptHandler;
    W_ENABLE_INTERRUPT_HANDLER  EnableInterruptHandler;
    ...


NDIS version adopted is 5.1 successively. We have a sequence of handlers passed to the struct, with each entry representing a function. Further explanations about the handler’s meaning can be found here: http://www.osronline.com/ddkx/network/103ndisx_0sj7.htm

The NdisMRegisterUnloadHandler function registers an unload handler for a driver. Driver unloading is performed via the NdisDeregisterProtocol function.

Another interesting and important struct is the NDIS_PROTOCOL_CHARACTERISTICS. It is used by NdisRegisterProtocol as follows:

typedef struct _NDIS_PROTOCOL_CHARACTERISTICS { 
    UCHAR MajorNdisVersion;
UCHAR MinorNdisVersion;
UINT Reserved;
OPEN_ADAPTER_COMPLETE_HANDLER OpenAdapterCompleteHandler;
CLOSE_ADAPTER_COMPLETE_HANDLER CloseAdapterCompleteHandler;
SEND_COMPLETE_HANDLER SendCompleteHandler;
TRANSFER_DATA_COMPLETE_HANDLER TransferDataCompleteHandler;
RESET_COMPLETE_HANDLER ResetCompleteHandler;
REQUEST_COMPLETE_HANDLER RequestCompleteHandler;
RECEIVE_HANDLER ReceiveHandler;
RECEIVE_COMPLETE_HANDLER ReceiveCompleteHandler;
STATUS_HANDLER StatusHandler;
STATUS_COMPLETE_HANDLER StatusCompleteHandler;
NDIS_STRING Name;
//
// MajorNdisVersion must be set to 0x04 or 0x05
// with any of the following members.
//
RECEIVE_PACKET_HANDLER ReceivePacketHandler;
    BIND_HANDLER BindAdapterHandler;
    UNBIND_HANDLER UnbindAdapterHandler;
    PNP_EVENT_HANDLER PnPEventHandler;
    UNLOAD_PROTOCOL_HANDLER UnloadHandler;
//
// MajorNdisVersion must be set to 0x05
// with any of the following members.
//
CO_SEND_COMPLETE_HANDLER CoSendCompleteHandler;
    CO_STATUS_HANDLER CoStatusHandler;
    CO_RECEIVE_PACKET_HANDLER CoReceivePacketHandler;
    CO_AF_REGISTER_NOTIFY_HANDLER CoAfRegisterNotifyHandler;
} NDIS_PROTOCOL_CHARACTERISTICS, *PNDIS_PROTOCOL_CHARACTERISTICS;


NdisRegisterProtocol registers a set of functions necessary to handle a certain number of network events. In this way, the malicious driver can intercept packets, parse their contents and take required actions; in thiscase drop requests to a well-defined list of servers.

If the protocol registration is successful NdisIMAssociateMiniport informs NDIS that the specified lower and upper interfaces for miniport and protocol drivers respectively belong to the same intermediate driver.

The filter is now fully operational.

Elsewhere, if protocol registration fails, the malicious driver can remove its own network event handlers by deregistering protocol via NdisIMDeregisterLayeredMiniport and NdisTerminateWrapper.

Until now, we have examined the filter installation process. Now, we will deal with the handlers that effectively drop antivirus requests.

There are two ways to reach this point:

We will use the second approach. It’s much more interesting, though a little bit slower.

Packet Interception and Request Dropper

An NDIS driver that needs to parse a network packet should start by getting the Current Packet Stack.This can be achieved by using NdisIMGetCurrentPacketStack(). Aquick search through the IDA will give reveal the effective presence of that function to us in perfect back-trace style. We can quickly determine what the function is called by using Cross References.

We finally land here:

sub_10970 is one of the Handling Functions used specified into Miniport Characteristics structure.

The code should be clear: the incoming Send Request passes through the malicious driver, pasring the packet content by calling PacketParser subroutine. If the packet contains unallowed sends to AV servers, the request is dropped. Otherwise, it will be transparently delivered to the underlying driver. Let’s see how the PacketParser function works:

This function works with memory containing the data to be delivered to and from our Network Interface Card. The code is fully commented; in other words, we are going to send a block of memory containing the request to the data parser.

The function that processes the recently built block of data is LookForUnallowedURL. As you can see, it takes two arguments: the VirtualAddress and the Length, according to whether its return value esi is cleared or not. This reflects whether an invald url has been found or not. Finally, memory is released with NdisFreeMemory. Let’s see how a url request is checked:

You’ll immediately notice the GET request in