KR101097590B1 - Method for defending against dll injection without hooking - Google Patents

Abstract

PURPOSE: A DLL injection blocking method is provided to establish a safe user environment by safely blocking a DLL injection in a 32 bit and 64 bit OS over Windows 2000. CONSTITUTION: A kernel mode controller installs a thread generating monitor to an OS(Operating System)(S21). The OS informs a thread generation to a kernel mode thread monitor by monitoring thread generation from an attack process which perform an DLL(Dynamic Link Library) injection(S32). The kernel mode thread monitor request the analysis of the thread in which the thread is included by transmitting thread information to the kernel mode process analyzer(S34). The kernel mode process analyzer analyzes and processes a virtual memory of a general process which is a target for an injection.

Description

Dynamic Link Library Injection Defense Method {Method for Defending Against DLL Injection without Hooking}

The present invention relates to a dynamic linking library (DLL) injection defense method, and more particularly, to all malicious code that performs dynamic link library injection to another process through remote thread creation without kernel hooking A method of disabling dynamic link library injection for defense in the operating system (OS).

In general, malware or malware is executable code written for malicious purposes and is the collective name for all software that can adversely affect a computer. Viruses, worms, and Trojans depend on their ability to replicate and to be infected. Horses are classified.

Malicious code is a method of injecting the dynamic link library (hereinafter referred to as 'DLL') through the creation of a remote thread as one of methods for infiltrating a normal process. DLL is a DLL implemented in Microsoft Windows.

Currently, most security solutions use the Windows Operating System (SSD) System Service Dispatch Table (SSDT) to change the address of the function address to be hooked into the Kiservice Table. Defending through. However, this method is only available on 32-bit Windows operating systems. On 64-bit Windows operating systems, SSDT hooking is not possible due to the built-in patch guard. As a result, kernel-level protection is not achieved on 64-bit operating systems. In addition, many 32-bit operating systems frequently encounter collisions due to hooking competition among security solutions.

In order to inject DLL through remote thread creation, make sure to record the path of DLL to be injected into the target process virtual memory space, and then create a remote thread and write the thread's start function as a function of LoadLibrary (xx) of kernel32.dll Pass the path of the DLL as a parameter. This process creates a threaded kernel object and loads the DLL into the target process.

The Windows operating system provides a way to detect thread creation at the kernel level, and you can see when a DLL injection through remote thread creation occurs. However, only detection is possible, and no blocking or manipulation of the thread creation is provided.

In addition, the operation principle and defense principle of the DLL injection through the remote thread generation in the prior art is the same as the flowchart of FIG.

First, DLL injection by creating a remote thread is performed using the following procedure. Acquire a target process handle to be penetrated (S1), and load the LoadLibrary (xx) function address of kernel32.dll into the obtained virtual memory space of the target process to be penetrated (S2). For applications on the same platform, kernel32.dll uses the same virtual memory address. The full path string of the DLL to be injected is recorded in the target process virtual memory space (S3). Requests to create a remote thread by using the CreateRemoteThread or NtCreateThreadEx API depending on the operating system, passing the thread start address to the LoadLibrary (xx) function address recorded in (S2) above, and using the parameter as the full path of the DLL to inject recorded in the above (S3). Pass the string address (S4).

Also, after creating the thread kernel object, the Windows kernel starts the thread with the start address and the parameter passed in (S4) (S5-S7).

Remote thread DLL injection defense of conventional security solutions for DLL injection via the remote thread creation is shown in the flowchart of FIG.

That is, many security solutions monitor and block API requests by hooking functions of a service function table called SSDT for processing API requests existing in the kernel (S8).

However, the conventional DLL injection defense technique using SSDT hooking has some problems. When security solutions of similar nature exist on a PC, conflicts frequently occur due to SSDT hooking and unhooking competition, such as a blue screen. It also blocks unconditionally whether or not a remote thread is created for actual DLL injection. In addition, SSDT hooking is not available due to Patch Guard on 64-bit Windows operating systems. Therefore, the defense is not achieved in the 64-bit Windows operating system.

SUMMARY OF THE INVENTION The present invention has been made to solve the above problem, and an object of the present invention is to enable malicious defense of DLL injection in all computer operating systems without kernel hooking of malicious codes that perform DLL injection to other processes through remote thread creation.

In order to achieve the above object, the present invention provides a dynamic link library (DLL) injection defense method, comprising: (a) installing a kernel mode controller under the control of a user mode controller, and installing a thread generation monitor in a computer operating system in the kernel mode controller; Doing; (b) monitoring, by the operating system, the thread creation from an attack process that performs external DLL injection, and notifying the thread generation to the kernel mode thread watcher; (c) the kernel mode thread monitor requesting an analysis of a process to which a thread belongs to a kernel mode process analyzer from the notified thread information; (d) the kernel mode process analyzer analyzing and processing the virtual memory of the general process targeted for injection; (e) The kernel mode process analyzer includes analyzing and processing the result of the kernel mode thread monitoring and the kernel mode controller and transmitting the result to the user mode controller.

Also, in the present invention, the kernel mode process analyzer attaches a kernel stack to a virtual memory space of a general process that is an injection target to which a thread of a kernel mode thread monitor belongs, and analyzes DLLs loaded in a process to determine a LoadLibrary address. After analyzing the start address and arguments of the threads belonging to the process to determine whether the start address is LoadLibrary, it modifies the thread's parameter memory, sends the processing result to the kernel mode thread monitor, and loads the kernel stack into the process's virtual memory. It may further comprise the release.

In addition, in the present invention, the modulation of the parameter memory of the thread may be initialized to zero or changed to a meaningless value.

In the present invention, the operating system may include 32-bit and 64-bit Windows operating systems.

According to the present invention, a 64-bit Windows operating system is gradually being spread to computer systems by the above-mentioned solutions, and accordingly, 64-bit malicious code is also increasing, thereby safer user environment by protecting DLL injection in 32-bit and 64-bit operating systems. Since it is possible to build a system and does not use hooking as in the related art, there is no possibility of collision due to a hooking competition, thereby enabling safe and efficient security. In addition, the present invention can protect all processes running in the system, and can also protect only selective processes, so that security solutions can be applied to techniques such as self-protection to protect themselves without affecting the entire system. .

1 is a flowchart illustrating the operation principle of a DLL injection through a conventional remote thread creation.
2 is a flowchart illustrating a defense principle of DLL injection through a conventional remote thread creation.
Figure 3 illustrates the overall flow for dynamic link library injection defense in accordance with the present invention.
Figure 4 shows the detailed flow of the configuration for the dynamic link library injection defense in accordance with the present invention.
Figure 5 is an embodiment of the present invention, Figure 5a shows a list of normal notepad process DLL before the DLL injection is made, Figure 5b shows a successful DLL injection with a DLL injector, Figure 5c is a notepad with a DLL injection Figure 5d shows a list of process DLLs, Figure 5d shows that the DLL injection failed in the environment in which the secure kernel driver is running, Figure 5e shows the fact that the DLL injection blocking in the secure kernel driver to the security program.

Hereinafter, a dynamic link library injection defense method according to the present invention will be described in detail with reference to the accompanying drawings.

First, the principle of the DLL injection defense method of the present invention is as follows.

Monitoring is performed after registering a notification callback about creating a thread kernel object in kernel mode. This is possible with the PsSetCreateThreadNotifyRoutine kernel API (Application Programming Interface, the language or message format used to communicate between the operating system and the program). At this time, when the DLL injection through the remote thread generation by the malicious code occurs, it is possible to check the process ID and thread ID belonging to the thread kernel object generated by the registered callback and whether or not it is created. The context at the time the callback is called is the context of the process that requested the creation of the thread. By comparing the requested process ID with the process ID where the actual thread kernel object was created, it is possible to check whether the remote thread is created first.

If it is determined that the remote thread, it is necessary to check whether the remote thread generation for the actual DLL injection. To do this, we need to analyze the actual start function address (User Space) of the thread and determine if the function address is a function address of LoadLibrary (xx) class loaded in the target process.

In addition, in order to analyze the actual start function address of the thread, first, the process kernel object and the thread kernel object from which the thread kernel object is created must be obtained. The API provided by the kernel obtains a process kernel object matching the target process ID. Apply the current stack to the virtual memory address space of the obtained process kernel object. In order to obtain the function address of LoadLibrary (xx) type loaded in the process, process environment variable information (PEB) is obtained from the process kernel object. The PEB information analyzes the PE information of the DLLs loaded in the process virtual memory to obtain the start address of the kernel32.dll (or ntdll.dll) in which the LoadLibrary (xx) function exists. Environment variable information (PEB) is analyzed based on the obtained start address of kernel32.dll (or ntdll.dll) to obtain a LoadLibrary (xx) function address included in an export table.

It then analyzes the actual start function address of the thread kernel object. However, the API provided by the kernel cannot obtain thread kernel objects at this point. This is because the thread kernel object creation has not been completed at this point, so the information is not registered in the kernel-managed CID table. In order to obtain the target thread kernel object, an undocumented process kernel object must be analyzed to obtain an actual thread kernel object, and the following process is performed.

First, obtain the process kernel object matching the target process ID by using the kernel API. Second, obtain the starting point of the thread kernel object list by analyzing the process kernel object structure. Third, the actual thread kernel is traversed through the thread kernel object list. Acquire an object. For example, if you refer to the following part of the process kernel object structure used by the Windows 7 64-bit operating system, there is a list start point of the thread kernel objects 0x30 bytes after the start of the process kernel object.

(Process Kernel Object Structure)

[0: kd> dt nt! _KPROCESS

+ 0x000 Header: _DISPATCHER_HEADER

+ 0x018 ProfileListHead: _LIST_ENTRY

+ 0x028 DirectoryTableBase: Uint8B

+ 0x030 ThreadListHead: _LIST_ENTRY

+ 0x040 ProcessLock: Uint8B

+ 0x048 Affinity: _KAFFINITY_EX

… ]

The actual start function address of the thread and the parameters passed to the thread are analyzed using the undocumented thread kernel object information and the location of the thread stack information stored in the thread kernel object structure. Obtain by

When the LoadLibrary (xx) function address obtained is compared with the actual start function address of the thread kernel object, the DLL injection is performed. When it is determined that the DLL injection is made, the full path of the DLL to be injected is present in the parameter memory of the obtained thread kernel object, and the memory is initialized. This causes the LoadLibrary (xx) function to fail naturally because there is no path to the DLL to load and no injection occurs.

The present invention will be described with reference to FIGS. 3 and 4 in a specific embodiment of the DLL injection defense method.

In FIG. 3, the user mode controller 10 installs the kernel mode controller 11 in the kernel mode (S11), and the kernel mode controller 11 installs a monitor that monitors thread generation in the computer operating system 20 ( S12). The operating system 20 monitors thread generation from the attack process 21 that performs external DLL injection and notifies the thread generation to the kernel mode thread monitor 12 (S13).

The kernel mode thread monitor 12 requests the kernel mode process analyzer 13 to analyze the process to which the thread belongs to the notified thread information (S14). The kernel mode process analyzer 13 analyzes and processes the virtual memory of the injection process, that is, the general process 22 to be protected (S15). The kernel mode process analyzer 13 transmits the analyzed and processed result to the user mode controller 10 through the kernel mode thread monitor 12 and the kernel mode controller 11 (S16 to S18).

In addition, in FIG. 4, the flow according to the operation of the kernel mode controller 11 is installed in the operating system 20 under the control of the user mode controller 10 to monitor the thread generation (S21), which is an injection target. Determination of whether or not the general process 22 is protected (S22), that is, if the protection is not stopped waiting for the blocking of the DLL injection from the thread creation monitoring (S23), blocking information to the controller for the DLL injection defense from the thread creation monitoring Transmit (S24). The determination of whether the protection is performed, that is, when the protection is stopped, the thread generation monitoring is removed from the operating system (S25).

In addition, the flow according to the operation of the kernel mode thread monitor 12 determines whether or not the general process 22 to be injected is protected (S31), that is, the kernel mode thread watcher from the operating system 20 when the protection is not stopped. Wait for a notification regarding thread creation according to DLL injection (S32). In this case, when a thread is generated from the operating system, a process that owns the generated thread is acquired (S33), and a DLL injection analysis and processing is requested to the kernel mode process analyzer 13 (S34). The kernel mode process analyzer 13 waits for the analysis and processing result to be received (S35), and transmits the corresponding analysis and processing result to the DLL injection defense processing result to the kernel mode controller 11 (S36).

In addition, the flow according to the operation of the kernel mode process analyzer 13 waits for a processing request from the thread monitor (S41), and the virtual memory space of the general process 22 that is the target of injection corresponding to the thread of the kernel mode thread monitor. Attach the kernel stack (S42). After analyzing the DLLs loaded in the process, the LoadLibrary address is analyzed (S43), the start address and the arguments of the threads belonging to the process are analyzed (S44), and after determining whether the start address is LoadLibrary (S45), The parameter memory of the thread is modulated (S46). Modulation of a thread's parameter memory initializes it to zero or changes it to a meaningless value. The processing result is transmitted to the kernel mode thread monitor 12 (S47), and the kernel stack is released to the virtual memory of the process (S48).

Next, the process of actual defense is achieved by using a secure kernel driver and a sample program to protect the DLL injection of the present invention by way of example. The target operating system used in the present invention is Windows 7 64bit, it can be applied to other operating systems. It can also include 32-bit and 64-bit operating systems on Windows 2000 and above. The sample program includes a security kernel driver for applying the present invention, a security program that communicates with the security kernel driver and starts or stops DLL injection blocking, and an injection program that performs DLL injection.

5A is a list of Notepad process DLLs showing the state of DLL injection performed on a Windows 7 64bit PC without a security program. Here, we ran Notepad as the process to be used for the penetration target and checked the list of DLLs loaded in the process. You can see that only normal DLLs are currently loaded.

In FIG. 5B, the DLL list is checked after performing DLL injection using the DLL injector in the notepad. The DLL injector indicates that the injection was successful, and in FIG. 5C, it can be seen that the DLL 'knhookdll.dll' is injected into the notepad process virtual memory.

In addition, in FIG. 5D, after initiating DLL injection protection for system-wide processes using a security driver, DLL injection is again performed to a clean notepad process using the used DLL injector. In FIG. 5E, the DLL injector indicates that the DLL injection has failed, and the security program communicating with the security driver informs the DLL injection blocking result.

Therefore, the method for blocking the remote thread DLL injection of the present invention analyzes undocumented kernel object information different for each operating system version, obtains a thread kernel object list through process kernel object analysis, and process environment variable block through process kernel object analysis. Obtain PEB, analyze PE information of DLLs loaded in process virtual memory through PEB analysis, obtain thread kernel object through thread kernel object list analysis, and actually start the thread through thread kernel object analysis. It acquires the address and parameters to be passed, analyzes the obtained process and thread object information, and initializes the thread parameters in the virtual memory of the target process.

As described above, the DLL injection defense method of the present invention analyzes a target process kernel object and a thread kernel object when a thread generation is detected in kernel mode, analyzes whether a remote thread is generated for DLL injection, and a function address at which an actual thread operates. If the DLL path memory to be injected from the target process virtual memory is initialized after analyzing the DLL injection, the LoadLibrary (xx) -type function fails, and as a result, the DLL injection can be defended. In addition, the technology does not require any kernel hooking, so it can be applied to not only 32-bit Windows 2000 but also 64-bit Windows operating systems.

While the invention has been shown and described with respect to the specific embodiments thereof, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention as defined by the appended claims. Anyone who has it will know it easily.

10: User Mode Controller 11: Kernel Mode Controller 12: Kernel Mode Thread Monitoring 13: Kernel Mode Process Analyzer 20: Operating System 21: Attack Process Performing DLL Injection 22: Common Target Process for Injection

Claims (4)

In the dynamic link library (DLL) injection defense method,
(a) installing a kernel mode controller under the control of the user mode controller and installing a thread generation monitor in the computer operating system in the kernel mode controller;
(b) monitoring, by the operating system, the thread creation from an attack process that performs external DLL injection, and notifying the thread generation to the kernel mode thread watcher;
(c) the kernel mode thread monitor requesting an analysis of a process to which a thread belongs to a kernel mode process analyzer from the notified thread information;
(d) the kernel mode process analyzer analyzing and processing the virtual memory of the general process targeted for injection;
(e) the kernel mode process analyzer transmitting the analyzed and processed result to a user mode controller via a kernel mode thread monitor and a kernel mode controller;
The kernel mode process analyzer attaches the kernel stack to the virtual memory space of the general process that is the target of injection corresponding to the thread of the kernel mode thread monitor, analyzes the DLLs loaded in the process, analyzes the LoadLibrary address, and belongs to the process. A dynamic link library that analyzes the starting address and arguments of the threads to determine whether the starting address is LoadLibrary, modifies the thread's parameter memory, sends the processing result to the kernel mode thread watcher, and frees the kernel stack in the process's virtual memory. DLL) Injection Defense Method.
delete The method of claim 1, wherein the modulation of the parameter memory of the thread initializes the memory to zero or changes it to a meaningless value.
The method of claim 1, wherein the operating system comprises 32-bit and 64-bit Windows operating systems.

Images