Backdoor! I believe this word is definitely not unfamiliar to you. Its harm is not a desire. However, as people's security awareness gradually increases, and the "strong support" of anti-virus software makes traditional backdoor unable to hide itself. Anyone with a little computer knowledge knows "checking the port" and "looking at the process" in order to find some "clues". Therefore, the writer of the backdoor adjusted his thinking in time and focused on the dynamic linking program library. That is to say, the backdoor is made into a DLL file, and then started with a certain EXE as a carrier or using it. In this way, there will be no processes or ports, and the hiddenness of processes and ports is realized. This article takes the theme of "Principles of DLL", "Clearing of DLLs", and discusses it, aiming to enable everyone to "quickly get started" with DLL backdoors and no longer be afraid of DLL backdoors. OK, get into our topic.
1. The principle of DLL
1. Dynamic linking program library
Dynamic link program library, full name ynamic Link Library, referred to as LL, is to provide extended functions for applications. If an application wants to call a DLL file, it needs to "dynamic link" with it; from a programming perspective, the application needs to know the API functions exported by the DLL file before it can be called. It can be seen that the DLL file itself cannot run and requires application calls. It is precisely because the DLL file must be inserted into the application's memory module when it is running, which means that the LL file cannot be deleted. This is due to the Windows internal mechanism: the running program cannot be closed. So, the DLL backdoor was born from this!
2. Principles and features of DLL backdoor
Write a code that implements the backdoor function into a DLL file, and then insert it into an EXE file to enable it to be executed, so that it does not need to occupy the process, and there is no corresponding PID number, and it can be hidden in the task manager. The DLL file itself is not much different from the EXE file, but it must be called using a program (EXE) to execute the DLL file. The execution of DLL file requires the loading of the EXE file, but if EXE wants to load the DLL file, it needs to know the entry function of the DLL file (which is the export function of the DLL file). Therefore, according to the writing standards of the DLL file: EXE must execute DLLMain() in the DLL file as the loading condition (like EXE's mian()). There are basically two types of DLL backdoors: 1) Implement all functions in the DLL file; 2) Make the DLL into a startup file and start a normal EXE backdoor when needed.
Common writing methods:
(1), only one DLL file
This type of backdoor is very simple. It only makes itself a DLL file and is automatically started using it in the registry Run key value or other places that can be automatically loaded by the system. What is it? As the name implies, "execute 32-bit DLL file". Its function is to execute internal functions in the DLL file, so that in the process, there will be only processes with DLL backdoors, and thus, the process is hidden. If you see multiple in the system, don't panic, it proves how many DLL files are started. Of course, we can find what these executed DLL files are from where the system automatically loads.
Now, let me introduce this file. As mentioned above, the function is to call the dynamic linking program library in the command line. There is also a file in the system, which means "execute 16-bit DLL file". Please note it here. Let's take a look at the function prototype used:
Void CALLBACK FunctionName (
HWND hwnd,
HINSTANCE hinst,
LPTSTR lpCmdLine,
Int nCmdShow
);
The usage method under the command line is: DLLname, Functionname [Arguments]
DLLname is the DLL file name that needs to be executed; Functionname is the specific export function of the DLL file that needs to be executed in the previous one; [Arguments] is the specific parameters of the export function.
(2), replace the DLL file in the system
This type of backdoor is more advanced than the above. It makes the code that implements the backdoor function into a DLL file that matches the system and renames the original DLL file. When an application requests the original DLL file, the DLL backdoor enables a forwarding function, passing the "parameters" to the original DLL file; if a special request is encountered (such as the client), the DLL backdoor starts and is started and runs. For this type of backdoor, it is safest to implement all operations in DLL files, but it requires a lot of programming knowledge and is very difficult to write. Therefore, this type of backdoor generally makes the DLL file into a "start" file. In special cases (such as the client's request), a normal EXE backdoor is started; after the client ends the connection, the EXE backdoor is stopped, and the DLL file enters the "rest" state and will not be started until the next time the client connects. But with the introduction of Microsoft's "digital signature" and "file recovery" functions, this backdoor has gradually declined.
hint:
In the WINNT\system32 directory, there is a dllcache folder, which stores many DLL files (including some important EXE files). After the DLL files are illegally modified, the system will restore the modified DLL files from here. If you want to modify a DLL file, you should first delete or rename the DLL file with the same name in the dllcache directory, otherwise the system will automatically restore it.
(3), dynamic embedded
This is the most commonly used method for DLL backdoors. Its meaning is to embed DLL files into running system processes. In Windows system, each process has its own private memory space, but there are still various ways to enter the private memory space of its process to implement dynamic embeddedness. Since the key processes of the system cannot be terminated, this type of backdoor is very hidden and it is very difficult to detect and kill. Common dynamic embedded types include: "hook API", "global hook (HOOK), "remote thread", etc.
Remote threading technology refers to the method of creating a remote thread in a process to enter the memory address space of that process. When the EXE carrier (or) creates a remote thread in the inserted process and commands it to execute a DLL file, our DLL backdoor is hung up and executed. No new processes are generated here. If you want the DLL backdoor to stop, you can only let the process linked to the DLL backdoor terminate. But if you link with key processes on some system, you cannot terminate it. If you terminate the system process, Windows will be terminated immediately!!!
3. Startup features of DLL backdoor
The carrier EXE that starts the DLL backdoor is indispensable and very important. It is called:Loader. If there is no Loader, how can our DLL backdoor be activated? Therefore, a good DLL backdoor will try its best to protect its Loader from being investigated. There are many ways to loader, which can be an EXE file specially written for our DLL backdoor; it can also be built on the system. Even if it is stopped, the main body of the DLL backdoor still exists. 3721 network real name is an example, although it is not a "real" backdoor.
2. Clearance of DLL
This section takes three more famous DLL backdoor examples, namely """""". Explain the manual removal method in detail. I hope that after seeing the removal methods of these three DLL backdoors, you can learn from one example and use it flexibly without fear of DLL backdoors. In fact, it is relatively simple to manually clear the DLL backdoor, it is nothing more than just making a fuss in the registry. For details, please see below.
1，PortLess BackDoor
This is a very powerful DLL backdoor program. In addition to the Shell that can obtain Local System permissions, it also supports a series of functions such as "detection of cloned accounts" and "installation of terminal services" (see program help for details), and is suitable for systems such as Windows 2000/xp/2003. The program is started using it. Usually, the port is not opened, and the reverse connection can be performed (the biggest feature). For hosts with firewalls, this function is very good.
Before introducing the cleaning method, let’s briefly introduce the key services of this system:
Svchost is just the host of the service and does not implement any functions. If you need to use Svchost to start the service, a certain service is implemented in the form of a DLL, and the carrier Loader of the DLL points to svchost. Therefore, when starting the service, svchost calls the DLL of the service to achieve the purpose of startup. The DLL file for starting a service using svchost is determined by the parameters in the registry. There is a Parameters subkey below the service that needs to be started. The ServiceDll indicates which DLL file the service is responsible for. This DLL file must export a ServiceMain() function to provide support for handling service tasks.
Haha! After reading the above theory, are you a little confused (I am almost asleep), don’t worry, let’s take a look at the specific content. First, let's take a look at the Parameters subkey under the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs, and its key value is %SystemRoot%\system32\. This means: when starting the RpcSs service. Svchost calls the WINNT\system32 directory.
Let’s take a look at another example. In the registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost, there are the groups started by Svchost and the various services in the group, among which the netsvcs group has the most services. To start a service using Svchost, the service name will appear under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost. Here are four ways to implement it:
1. Add a new group and add the service name in the group
2. Add a service name to the existing group
3. Directly use a service name in the existing group, but there is no service installed in the machine.
4. Modify the existing services in the existing group and point its ServiceDll to its DLL backdoor
The third method I tested using PortLess BackDoor.
Okay, I think after reading the above principles, you can definitely think of a way to clear PortLess BackDoor. Yes, it is to write an article under the Svchost key of the registry. OK, let's start now.
The backdoor Loader inserts into the Svchost process, so we first open Windows Process Management 2.5 in Windows Optimizer, check the module information in the Svchost process, and you can see that it has been inserted into the Svchost process. According to the prompt "directly use a service name in the existing group, but there is no service installed in the local machine", we can conclude that there will be a new service in the "Management Tools"-"Service". By viewing, we can prove that the service name is: IPRIP, started by Svchost, -k netsvcs means that this service is included in the netsvcs service group.
We stop the service, then open the Registry Editor (Start - Run --regedit), go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPRIP, and check its Parameters subkey. The key value of the Program key is the backdoor Loader; the key value of ServiceDll C:\WINNT\system32\ is the called DLL file, which is the backdoor DLL file. Now we delete the IPRIP subkey (or use SC to delete it), and then under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost, edit the netsvcs service group and delete 49 00 70 00 72 00 69 00 70 00 00 00. The corresponding one here is the service name of IPRIP. Then exit and restart. After restarting, just delete the backdoor file under the WINNT\system32 directory.
2，
This is Rong Ge's work, and it is also a DLL backdoor. It is basically the same as the principle, but here is the fourth method introduced above, namely "modify existing services in the existing group and point its ServiceDll to its own DLL backdoor." In other words, the backdoor modifies an existing service and points the DLL of its original service to itself (that is,), thus achieving the purpose of automatic loading; secondly, the backdoor does not have its own Loader, but uses the system's own loading. We still use Windows Process Management 2.5 to view it, and we can see that it has been inserted into the Svchost process.
OK, now let's take a look at the specific clearing method. Since the backdoor is to modify the existing service, we don't know which service was modified. So, search in the registry and finally searched under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasAuto, check the ServiceDll under the Parameters subkey, and its key value is C:\WINNT\system32\. It turns out that the backdoor replaces the original DLL file of the RasAuto service to achieve automatic loading. It's easy to deal with if you know the reason. Now we change the key value of ServiceDll to the original DLL file of RasAuto service, that is, %SystemRoot%\System32\, exit and restart. Then delete the WINNT\system32 directory.
3，NOIR--QUEEN
NOIR--QUEEN (Guardian) is a DLL backdoor & * program. The server inserts it into the system process in the form of a DLL file. Since it is a key process of the system, it cannot be terminated. Before introducing the cleaning method, I will introduce the process:
This is a local security authorization service, and it will generate a process for authorized users using Winlogon services. If the authorization is successful, Lsass will generate the user's entry token, which uses the initial shell to start. Other processes initialized by the user will inherit this token.
From the above introduction, we can see the importance of Lsass to the system. How to clear it out specifically? Please see below.
After the backdoor is installed successfully, a service named QoSserver will be added to the service, and the backdoor file will be inserted into the Lsass process, so that it can hide the process and start automatically. Now we open the registry, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QoSserver, directly delete the QoSserver key, and then restart. After restarting, when we come to the service list, we will see that the QoSserver service is still there, but it has not started. The category is automatic. We modify it to "disabled"; then look up and you will find a service named AppCPI, whose executable program points to (I will talk about the reason later), as shown in Figure 11. We open the registry again, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppCPI, delete the AppCPI key, restart, delete the QoSserver, and finally delete the backdoor file under the WINNT\system32 directory.
I've "fighted" with this backdoor for more than 3 hours and restarted N times. The reason is that even if the QoSserver service is deleted, the backdoor is still running, and the QoSserver service in the service list is "resurrect". Later I learned the reason: After I deleted the QoSserver service and restarted it, the file inserted into the Lsass process restored the QoSserver service and generated another service, namely AppCPI, so we must delete the AppCPI service in the registry to be considered as clearing the backdoor. From this we can see that the current back door protection measures are really a link to the buckle.
Note: After deleting the QoSserver service and restarting, the startup category of the restored QoSserver must be modified to "Disabled". Otherwise, even if the AppCPI service is deleted, the QoSserver service will run again.
3. DLL protection
After looking at the example above, I think everyone has a certain understanding of how to clear the DLL backdoor, but in reality, the DLL backdoor does not use the default file name, so you cannot be sure whether you have hit the DLL backdoor. For DLL backdoors, system32 is a good place, and most backdoors are the same, so pay great attention here. Let me introduce in detail how to discover the DLL backdoor, hoping it will be helpful to everyone.
1. After installing the system and all applications, back up the EXE and DLL files in the system32 directory: Open CMD, go to the WINNT\system32 directory, and execute ir *.exe> & dir *.dll>, so that all EXE and DLL files will be backed up to the GL file; in the future, if you find an exception, you can use the same command to back up the EXE and DLL files again (we assume that it is Sum here), and use:fc > & fc >, which means using the FC command to compare the EXE files and DLL files twice, and save the comparison results to the file. Through this method, we can discover the extra EXE and DLL files, and use the file size and creation time to determine whether it is a DLL backdoor.
2. Use memory/module tools to view the DLL files called by the process, such as Windows Process Management 2.5 in Windows Optimizer. In this way, you can find out what DLL file the process calls, and combine the results of using FC commands above to further determine whether the DLL backdoor has been hit. If there is no optimization master, you can use TaskList. This widget can also display the DLL file called by the process, and there is also source code for easy modification.
3. Ordinary backdoor connection requires opening a specific port, and DLL backdoor is no exception. No matter how it hides it, the port needs to be opened when connecting. We can use netstat -an to view the connections of all TCP/UDP ports to find illegal connections. Everyone should be aware of the port they open and have some understanding of the state attribute in netstat-an. Of course, you can also use Fport to display the corresponding processes of the port, so that you can see any unknown connections and ports in the system.
4. Regularly check the automatic loading of the system, such as: registry,,,,,,,,,,,,, etc. The second is to manage the services and have some understanding of the system's default services. When you find a problematic service, you can use the SC in the Windows 2000 Server Resource Kit to delete it. All the above places can be used to load the loader of the DLL backdoor. If we delete the DLL backdoor Loader, how can the DLL backdoor still run?!
By using the above method, I think most DLL backdoors can be "precise". If we do more backups in our daily life, it will have twice the result with half the effort in finding the DLL backdoor.
1. The principle of DLL
1. Dynamic linking program library
Dynamic link program library, full name ynamic Link Library, referred to as LL, is to provide extended functions for applications. If an application wants to call a DLL file, it needs to "dynamic link" with it; from a programming perspective, the application needs to know the API functions exported by the DLL file before it can be called. It can be seen that the DLL file itself cannot run and requires application calls. It is precisely because the DLL file must be inserted into the application's memory module when it is running, which means that the LL file cannot be deleted. This is due to the Windows internal mechanism: the running program cannot be closed. So, the DLL backdoor was born from this!
2. Principles and features of DLL backdoor
Write a code that implements the backdoor function into a DLL file, and then insert it into an EXE file to enable it to be executed, so that it does not need to occupy the process, and there is no corresponding PID number, and it can be hidden in the task manager. The DLL file itself is not much different from the EXE file, but it must be called using a program (EXE) to execute the DLL file. The execution of DLL file requires the loading of the EXE file, but if EXE wants to load the DLL file, it needs to know the entry function of the DLL file (which is the export function of the DLL file). Therefore, according to the writing standards of the DLL file: EXE must execute DLLMain() in the DLL file as the loading condition (like EXE's mian()). There are basically two types of DLL backdoors: 1) Implement all functions in the DLL file; 2) Make the DLL into a startup file and start a normal EXE backdoor when needed.
Common writing methods:
(1), only one DLL file
This type of backdoor is very simple. It only makes itself a DLL file and is automatically started using it in the registry Run key value or other places that can be automatically loaded by the system. What is it? As the name implies, "execute 32-bit DLL file". Its function is to execute internal functions in the DLL file, so that in the process, there will be only processes with DLL backdoors, and thus, the process is hidden. If you see multiple in the system, don't panic, it proves how many DLL files are started. Of course, we can find what these executed DLL files are from where the system automatically loads.
Now, let me introduce this file. As mentioned above, the function is to call the dynamic linking program library in the command line. There is also a file in the system, which means "execute 16-bit DLL file". Please note it here. Let's take a look at the function prototype used:
Void CALLBACK FunctionName (
HWND hwnd,
HINSTANCE hinst,
LPTSTR lpCmdLine,
Int nCmdShow
);
The usage method under the command line is: DLLname, Functionname [Arguments]
DLLname is the DLL file name that needs to be executed; Functionname is the specific export function of the DLL file that needs to be executed in the previous one; [Arguments] is the specific parameters of the export function.
(2), replace the DLL file in the system
This type of backdoor is more advanced than the above. It makes the code that implements the backdoor function into a DLL file that matches the system and renames the original DLL file. When an application requests the original DLL file, the DLL backdoor enables a forwarding function, passing the "parameters" to the original DLL file; if a special request is encountered (such as the client), the DLL backdoor starts and is started and runs. For this type of backdoor, it is safest to implement all operations in DLL files, but it requires a lot of programming knowledge and is very difficult to write. Therefore, this type of backdoor generally makes the DLL file into a "start" file. In special cases (such as the client's request), a normal EXE backdoor is started; after the client ends the connection, the EXE backdoor is stopped, and the DLL file enters the "rest" state and will not be started until the next time the client connects. But with the introduction of Microsoft's "digital signature" and "file recovery" functions, this backdoor has gradually declined.
hint:
In the WINNT\system32 directory, there is a dllcache folder, which stores many DLL files (including some important EXE files). After the DLL files are illegally modified, the system will restore the modified DLL files from here. If you want to modify a DLL file, you should first delete or rename the DLL file with the same name in the dllcache directory, otherwise the system will automatically restore it.
(3), dynamic embedded
This is the most commonly used method for DLL backdoors. Its meaning is to embed DLL files into running system processes. In Windows system, each process has its own private memory space, but there are still various ways to enter the private memory space of its process to implement dynamic embeddedness. Since the key processes of the system cannot be terminated, this type of backdoor is very hidden and it is very difficult to detect and kill. Common dynamic embedded types include: "hook API", "global hook (HOOK), "remote thread", etc.
Remote threading technology refers to the method of creating a remote thread in a process to enter the memory address space of that process. When the EXE carrier (or) creates a remote thread in the inserted process and commands it to execute a DLL file, our DLL backdoor is hung up and executed. No new processes are generated here. If you want the DLL backdoor to stop, you can only let the process linked to the DLL backdoor terminate. But if you link with key processes on some system, you cannot terminate it. If you terminate the system process, Windows will be terminated immediately!!!
3. Startup features of DLL backdoor
The carrier EXE that starts the DLL backdoor is indispensable and very important. It is called:Loader. If there is no Loader, how can our DLL backdoor be activated? Therefore, a good DLL backdoor will try its best to protect its Loader from being investigated. There are many ways to loader, which can be an EXE file specially written for our DLL backdoor; it can also be built on the system. Even if it is stopped, the main body of the DLL backdoor still exists. 3721 network real name is an example, although it is not a "real" backdoor.
2. Clearance of DLL
This section takes three more famous DLL backdoor examples, namely """""". Explain the manual removal method in detail. I hope that after seeing the removal methods of these three DLL backdoors, you can learn from one example and use it flexibly without fear of DLL backdoors. In fact, it is relatively simple to manually clear the DLL backdoor, it is nothing more than just making a fuss in the registry. For details, please see below.
1，PortLess BackDoor
This is a very powerful DLL backdoor program. In addition to the Shell that can obtain Local System permissions, it also supports a series of functions such as "detection of cloned accounts" and "installation of terminal services" (see program help for details), and is suitable for systems such as Windows 2000/xp/2003. The program is started using it. Usually, the port is not opened, and the reverse connection can be performed (the biggest feature). For hosts with firewalls, this function is very good.
Before introducing the cleaning method, let’s briefly introduce the key services of this system:
Svchost is just the host of the service and does not implement any functions. If you need to use Svchost to start the service, a certain service is implemented in the form of a DLL, and the carrier Loader of the DLL points to svchost. Therefore, when starting the service, svchost calls the DLL of the service to achieve the purpose of startup. The DLL file for starting a service using svchost is determined by the parameters in the registry. There is a Parameters subkey below the service that needs to be started. The ServiceDll indicates which DLL file the service is responsible for. This DLL file must export a ServiceMain() function to provide support for handling service tasks.
Haha! After reading the above theory, are you a little confused (I am almost asleep), don’t worry, let’s take a look at the specific content. First, let's take a look at the Parameters subkey under the registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs, and its key value is %SystemRoot%\system32\. This means: when starting the RpcSs service. Svchost calls the WINNT\system32 directory.
Let’s take a look at another example. In the registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost, there are the groups started by Svchost and the various services in the group, among which the netsvcs group has the most services. To start a service using Svchost, the service name will appear under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost. Here are four ways to implement it:
1. Add a new group and add the service name in the group
2. Add a service name to the existing group
3. Directly use a service name in the existing group, but there is no service installed in the machine.
4. Modify the existing services in the existing group and point its ServiceDll to its DLL backdoor
The third method I tested using PortLess BackDoor.
Okay, I think after reading the above principles, you can definitely think of a way to clear PortLess BackDoor. Yes, it is to write an article under the Svchost key of the registry. OK, let's start now.
The backdoor Loader inserts into the Svchost process, so we first open Windows Process Management 2.5 in Windows Optimizer, check the module information in the Svchost process, and you can see that it has been inserted into the Svchost process. According to the prompt "directly use a service name in the existing group, but there is no service installed in the local machine", we can conclude that there will be a new service in the "Management Tools"-"Service". By viewing, we can prove that the service name is: IPRIP, started by Svchost, -k netsvcs means that this service is included in the netsvcs service group.
We stop the service, then open the Registry Editor (Start - Run --regedit), go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPRIP, and check its Parameters subkey. The key value of the Program key is the backdoor Loader; the key value of ServiceDll C:\WINNT\system32\ is the called DLL file, which is the backdoor DLL file. Now we delete the IPRIP subkey (or use SC to delete it), and then under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost, edit the netsvcs service group and delete 49 00 70 00 72 00 69 00 70 00 00 00. The corresponding one here is the service name of IPRIP. Then exit and restart. After restarting, just delete the backdoor file under the WINNT\system32 directory.
2，
This is Rong Ge's work, and it is also a DLL backdoor. It is basically the same as the principle, but here is the fourth method introduced above, namely "modify existing services in the existing group and point its ServiceDll to its own DLL backdoor." In other words, the backdoor modifies an existing service and points the DLL of its original service to itself (that is,), thus achieving the purpose of automatic loading; secondly, the backdoor does not have its own Loader, but uses the system's own loading. We still use Windows Process Management 2.5 to view it, and we can see that it has been inserted into the Svchost process.
OK, now let's take a look at the specific clearing method. Since the backdoor is to modify the existing service, we don't know which service was modified. So, search in the registry and finally searched under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasAuto, check the ServiceDll under the Parameters subkey, and its key value is C:\WINNT\system32\. It turns out that the backdoor replaces the original DLL file of the RasAuto service to achieve automatic loading. It's easy to deal with if you know the reason. Now we change the key value of ServiceDll to the original DLL file of RasAuto service, that is, %SystemRoot%\System32\, exit and restart. Then delete the WINNT\system32 directory.
3，NOIR--QUEEN
NOIR--QUEEN (Guardian) is a DLL backdoor & * program. The server inserts it into the system process in the form of a DLL file. Since it is a key process of the system, it cannot be terminated. Before introducing the cleaning method, I will introduce the process:
This is a local security authorization service, and it will generate a process for authorized users using Winlogon services. If the authorization is successful, Lsass will generate the user's entry token, which uses the initial shell to start. Other processes initialized by the user will inherit this token.
From the above introduction, we can see the importance of Lsass to the system. How to clear it out specifically? Please see below.
After the backdoor is installed successfully, a service named QoSserver will be added to the service, and the backdoor file will be inserted into the Lsass process, so that it can hide the process and start automatically. Now we open the registry, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QoSserver, directly delete the QoSserver key, and then restart. After restarting, when we come to the service list, we will see that the QoSserver service is still there, but it has not started. The category is automatic. We modify it to "disabled"; then look up and you will find a service named AppCPI, whose executable program points to (I will talk about the reason later), as shown in Figure 11. We open the registry again, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppCPI, delete the AppCPI key, restart, delete the QoSserver, and finally delete the backdoor file under the WINNT\system32 directory.
I've "fighted" with this backdoor for more than 3 hours and restarted N times. The reason is that even if the QoSserver service is deleted, the backdoor is still running, and the QoSserver service in the service list is "resurrect". Later I learned the reason: After I deleted the QoSserver service and restarted it, the file inserted into the Lsass process restored the QoSserver service and generated another service, namely AppCPI, so we must delete the AppCPI service in the registry to be considered as clearing the backdoor. From this we can see that the current back door protection measures are really a link to the buckle.
Note: After deleting the QoSserver service and restarting, the startup category of the restored QoSserver must be modified to "Disabled". Otherwise, even if the AppCPI service is deleted, the QoSserver service will run again.
3. DLL protection
After looking at the example above, I think everyone has a certain understanding of how to clear the DLL backdoor, but in reality, the DLL backdoor does not use the default file name, so you cannot be sure whether you have hit the DLL backdoor. For DLL backdoors, system32 is a good place, and most backdoors are the same, so pay great attention here. Let me introduce in detail how to discover the DLL backdoor, hoping it will be helpful to everyone.
1. After installing the system and all applications, back up the EXE and DLL files in the system32 directory: Open CMD, go to the WINNT\system32 directory, and execute ir *.exe> & dir *.dll>, so that all EXE and DLL files will be backed up to the GL file; in the future, if you find an exception, you can use the same command to back up the EXE and DLL files again (we assume that it is Sum here), and use:fc > & fc >, which means using the FC command to compare the EXE files and DLL files twice, and save the comparison results to the file. Through this method, we can discover the extra EXE and DLL files, and use the file size and creation time to determine whether it is a DLL backdoor.
2. Use memory/module tools to view the DLL files called by the process, such as Windows Process Management 2.5 in Windows Optimizer. In this way, you can find out what DLL file the process calls, and combine the results of using FC commands above to further determine whether the DLL backdoor has been hit. If there is no optimization master, you can use TaskList. This widget can also display the DLL file called by the process, and there is also source code for easy modification.
3. Ordinary backdoor connection requires opening a specific port, and DLL backdoor is no exception. No matter how it hides it, the port needs to be opened when connecting. We can use netstat -an to view the connections of all TCP/UDP ports to find illegal connections. Everyone should be aware of the port they open and have some understanding of the state attribute in netstat-an. Of course, you can also use Fport to display the corresponding processes of the port, so that you can see any unknown connections and ports in the system.
4. Regularly check the automatic loading of the system, such as: registry,,,,,,,,,,,,, etc. The second is to manage the services and have some understanding of the system's default services. When you find a problematic service, you can use the SC in the Windows 2000 Server Resource Kit to delete it. All the above places can be used to load the loader of the DLL backdoor. If we delete the DLL backdoor Loader, how can the DLL backdoor still run?!
By using the above method, I think most DLL backdoors can be "precise". If we do more backups in our daily life, it will have twice the result with half the effort in finding the DLL backdoor.