Case Study of Removing Malicious Code

What do malicious code and instruction set mean? Do they mean binary executable instructions, scripting languages, word-processing macro languages, or others? Take common malicious code as an example: The malicious code on a server depends on which kind of operating system it runs. Generally, for a Windows system, the malicious code refers to viruses, worms, and trojan, but rootkits for a Linux system.

Well, how do you rapidly determine whether malicious code exists in your web server, whether the malicious code penetrates into the intranet due to issues on the web side, whether your web server is already embedded with malicious code to act as a springboard or zombie? How can you remove malicious code manually or with a tool in a quick manner and enhance the system to prevent the next intrusion?

At the invitation of NSFOCUS Blog, a security engineer from the security service team demonstrates a case to explain how to manually eliminate malicious code. In this case, a server functions abnormally and we need to troubleshoot problems on the server.

Viewing System Logs

The prerequisite is that both the logging policy and auditing policy should be enabled.

1

1

2

2

By checking logs, we can see that the attacker made many login attempts from the Terminal Services end (remote desktop), for which a great number of logs with the same status were generated. We infer that a remote brute-force guessing attack took place. However, because of the limit of failed login attempts, it took the attacker a longer time to guess the real password.

How Malicious Programs Were Executed

Checking the system’s Task Scheduler, we find that the attacker executed trojan programs in a hackneyed way by creating scheduled tasks.

We can check the attributes of a scheduled task to locate the trojan file.

3

3

4

4

5

5

Made to look like svchost.exe, the trojan file name, svchsot.exe, is very confusing and hidden in a conventional way. Through query, we finally confirm that svchsot.exe is a program of the Troj/GWGhost-O trojan, that is, a major component of this trojan.

Following up Traces of the Attacker

Following the track of the attacker, we find his other malicious moves, besides svchsot.exe, a trojan program mentioned above.

6

6

We find the xiaoma file and zombie capture tools under the prefetch directory where the files pre-read by the system are stored. Checking the creation time of the xiaoma file, we realize that this server has become a zombie several days ago or even earlier.

7

7

In addition, .pf files also exist in the prefetch directory. As the system, upon startup, does an inverse search for the name of .pf files when pre-reading them, the attacker will lure the server into further malicious behaviors, hoping to make the system a zombie once it starts to run.

8

8

In the system directory, there is a folder that contains files to which .pf files link. Obviously, the system, upon startup, will be made to load such files so that it can be reduced to an attack tool. What a cunning trick!

Carrying Out Other Checks

Check processes running on the server to locate problems.

9

9

To sum up, we need to check system information in various ways to determine where malicious code resides and how it is triggered, and then remove malicious code executables. After that, check if products (such as executables, services, and links) associated with malicious code affect system startup items and system files, and remove these products. Of course, the best way to eradicate malicious code is to reinstall the operating system.

As for troubleshooting, we need to check processes, services, startup items, network connections, and hooks, with a focus on logs and system information changes made when security events occurred. Also, it is a good idea to conduct correlation analysis based on key time to ascertain the attacker’s intrusion thought and specific intrusion steps. Here, we recommend several common mini tools which can help obtain various system information and look for traces that intrusion behaviors left.

Trace 1: Processes

It is recommended that the Process Explorer tool be used to check suspicious processes and their child processes, with a focus on the following items:

  • Processes without signature authentication information
  • Processes without descriptions
  • Process owner
  • Validity of process paths
  • Processes that occupy too many CPU/memory resources for long

Trace 2: Files

It is recommended that recent changes to sensitive system directories and files be checked.

Trace 3: Startup Items

The Autoruns tool is recommended.

11

11

This tool can check system startup items, describe most of them, display their paths in the registry, as well as detect common trojan operation modes, BHO items, scheduled tasks, and mirror hijackings. Its criteria of judgement include whether the startup items have descriptions, whether they are common suspicious components, and whether they are added by the administrator.

Trace 4: Comprehensive Analysis

The IceSword tool is recommended.

12

12

IceSword is a powerful tool as it can detect hidden processes and mark them in red, as well as check ports, services, registry entries, files, and threads. For items that lack descriptions or have peculiar names, we should manually check them one by one.

Summary

The malicious code detection process is very interesting. During the process, we need to inverse the attacker’s logic, like reproducing the crime scene, and make in-depth analysis with attention on every detail. If you are a fan of detective stories, you are bound to be absorbed by the malicious code detection process.

Chinese version: http://blog.nsfocus.net/malicious-code-clear/

发表评论