Deep anti-virus guide: quick and effective response to malware events [1]

This chapter describes a set of detailed considerations used to identify malware infections or bursts, prevent it from spreading, and then eliminate the adverse effects it may have on infected systems in the environment. The need to adopt consistent and simple methods for Event Response and Recovery should not be underestimated; malicious software events usually have a certain degree of closeness, which is not conducive to the establishment of a long-term effective and successful well-designed process.

Another important question is worth mentioning. Due to the use of a variety of different loads, the complexity of malware attacks is constantly increasing, so any single process used to delete malware from the system is no longer widely used. Each different malware attack may require separate remedial measures. However, this does not mean that defining a process for identifying attacks, controlling attack propagation, and recovering from attacks (should be consistent) is not important.

From an advanced perspective, the steps for the emergency recovery process of malware include:

1. Confirm Infection
2. Event Response
3. malware Analysis
4. System Recovery
5. Steps after recovery
 
Step 1: confirm the infection

It is critical to quickly determine if the system is infected to minimize the impact of infection on the tissue. By quickly identifying an infection and identifying its suspicious characteristics, the spread of the infection can be reduced and its adverse effects on users can be reduced.

There are many different types of computer faults that may be mistaken for virus behavior. When a user says "I think my system is infected with a virus" by phone or email, the support staff must first determine whether this behavior may be caused by some type of malicious code. The following lists examples of typical symptoms that users may report as "virus-like" behavior:

• "I opened an email attachment without exception, but my computer is still abnormal. "
 
• "I received an email from my contacts asking me why I sent them .exe0000.zip or other attachments, but I have never actually sent similar files. "
 
• "My anti-virus software has stopped working and the computer is always automatically shut down! "
 
• "My programs are working abnormally and their speed is very slow! "
 
• "My Documents; a folder contains a large number of files that have never been seen before. "
 
• "Some of my files cannot be opened or disappear! "

User observation and feedback are critical because they may be the first to notice abnormal activities. As malicious software bursts increase, the duration between initial infection and effective defense availability becomes increasingly important. Since most infections will occur at this stage, it is critical for organizations to quickly identify and confirm the impact of an infection to minimize the scope of sudden transmission and the damage it may cause.

The following sections provide an overview of a series of steps that allow you to quickly confirm whether an abnormal behavior is a malicious software attack or an emergency.

If a new type of malware is infected with the system, the system user will be the first to notice abnormal behavior. There is usually a delay between the release time of the new malware and the time when the anti-virus scan application is updated to detect and respond to the malware. The best way to provide early warning systems is to let users know how to identify possible malware attack signals and provide them with fast communication links to report such malware attacks as soon as possible.

Infection report
After receiving a call from a user or generating an alert about a possible new malware attack, defining a process that is used to determine as soon as possible whether the warning is related to the new attack is usually very beneficial to technical support. The following flowchart shows the main steps in the process:

Figure 4.1 malware infection reporting process

Abnormal activity report
The following issues are used to determine whether the abnormal activities that cause alarms may be new malware attacks. This Guide assumes that these issues should be raised by IT technical support members in the organization to non-technical users.

Collect basic information
The initial question should be answered to help determine the alert nature as soon as possible and whether it may be a new malware attack. You can use the following example as the starting point of the process to modify the process to meet the needs of the Organization. :

• Report date and time?
 
• What are the abnormal activities that cause reporting?
 
• What activities did happen before the exception?

• Have you ever visited any other Web site other than "normal" routine access?
 
• Is the system located outside the organizational network (for example, at an airport, home network, Wi-Fi hotspot, or hotel) recently )?
 
• Have you seen any abnormal pop-up windows or advertisements on the screen?
 
• What exceptions or unexpected processes are currently running?
 
• Is the computer a workstation or a server? Which operating system does it use? What security updates does it apply?
 
• Does the computer or any device it connects to contain key task data?
 
• Do users use accounts with administrator privileges to log on?
 
• Do users use strong passwords or passwords?
 
• Have the system ever been attacked by malware?

The last problem is very important because previous attacks usually generate vulnerabilities, whether or not these vulnerabilities have been fixed or not, may lead to subsequent attacks. If you answer "yes" to this question, consider the following additional questions:

• When was the last attack?
 
• Who handles the attack and what is the attack number (if possible )?
 
• Can I provide information on the measures taken at that time?

Evaluate the data
After the answers to these questions are collected, the technical support staff should evaluate the collected data against the following problem groups to help determine whether malware attacks may be the cause of the report:

• Can a report be the result of a legitimate new feature or feature update of the system?
 
• Can it be explained by activities of authorized users rather than hackers/intruders?
 
• Can it be explained by known system activities?
 
• Can it be explained by the change in authorization to the program or system?

Finally, check the external anti-virus source (identified in "active internal communication" section of "Deep virus protection" in Chapter 3rd of this Guide ), to determine whether the report meets certain existing virus or worm alarms.

Collect detailed information
In this case, you can determine whether the new malware attack is a possible cause of the problem. If not, more advanced technical information may be required, and technical support personnel may need to physically access (if possible, remotely control) suspicious systems. You can use the following example to collect more detailed information and determine whether the system has been attacked by hackers or malicious code:

• Is the Firewall Enabled on or before the device itself? If enabled, which ports are open to the Internet?
 
• If an application fails, immediately contact the application supplier to determine the root cause (for example, the current Microsoft application provides an error reporting tool that can be used to send a fault report ).
 
• Does the system have security updates that have been released but not yet installed?
 
• What type of password policy does the system have? What is the minimum password length? What are the requirements for Password Complexity?
 
• Are there any of the following new or suspicious situations:

• Are there any new or suspicious accounts on the local computer?
 
• Are there new or suspicious accounts in the Administrator group?

• Are new or suspicious services listed in the service management console?
 
• Are new or suspicious events in the event log?
 
• Is there a network connection reported by the Netstat utility to an external IP address or a suspicious IP address?

Abnormal activity response
Once initial information is collected and used to determine the nature of the alert, the support staff should be able to determine whether false alerts, pranks, or real malware attacks are occurring.

Creating false malware reports is much easier than developing viruses or worms, which ensures that many false malware alarms are created. These pranks and the calls and warnings they generate will waste a lot of time and money. Pranks can also cause problems to users, and usually make them question the role of reporting possible attacks. Note the following to ensure that alarms are correctly handled.

• False alarm. Call information should be recorded if a false alarm is reported. Regular checks on this information may help determine whether additional user training is required.
 
• Prank. It is important to track and record false malware alerts and real malware activities because they are still attacking instances-but they do not use malicious code. Reporting information on false malware alerts and real malware threats to users should be part of the Organization's regular anti-virus communication. This information helps users identify pranks in advance to reduce productivity.
 
• Known infections. If the system is infected, the support staff should take measures to determine whether the infection can use existing anti-virus