The Basics of Manual Malware Identification and Removal

An Introduction to Malware Identification and Removal


When talking about fighting malware, the focus is usually on how well security software protects computers against malware. Malware protection (commonly anti-virus and anti-malware software) is without a doubt one of the most important defenses computers need, but what do you do if your machine gets infected before you’re able to install security programs?

Particularly when working in a computer repair or maintenance environment, you may encounter computers that are already infected. In such cases installing and running a security program may not be enough to remove all malware. While prevention advice is invaluable, it really doesn’t help much if you have a computer that’s already infected. The first step would be to download and run a malware scanner (such as our free Emsisoft Emergency Kit). Ideally, such a scanner would take care of all malware, though that may not be so in some cases because of the following:

Manual Malware Removal

At this point, having a computer that’s still infected, the next step is manual malware removal. This can be a daunting task, especially when you’re not familiar with identifying malware, let alone removing it. Where should you start looking, and more importantly, how can you know if a file, folder or registry object is malicious or not? You can try to perform a web search of file names, but for every legitimate Windows file, there are multiple search results claiming they are bad.

Fortunately there are various tools that can be used to get an overview of what’s happening on a computer. We’ve opted to demonstrate how malware removal can be done using Autoruns, one of the more popular tools available for the task. Autoruns is developed by Microsoft SysInternals and freely available for anyone to use.

So what is the difference between an automated scanner like Emsisoft Emergency Kit and a logging application like Autoruns? An automated scanner will check the file system and registry to see if any object matches any of its malware definitions. A logging application on the other hand will show which files are configured to start with Windows launch and at which point they are supposed to start. Some will also show which processes were running when the scan was performed. Autoruns is designed for the former. It’s up to the one running the application to determine whether or not the objects shown are legitimate or not (Note: Most logging applications do have a whitelist which will exclude known good entries that cannot be used for malicious purposes).

Malware Identification

This brings us to the most important step in manual malware removal: Identification. There’s no magical “fix” button to somehow make all suspicious entries go away (at least not yet!). You will first need to determine what needs to go. This doesn’t mean you have to perform complicated malware analysis; in most cases, basic knowledge of Windows combined with common logic go a long way. (Note: Familiarization with Windows Registry is highly recommended at this point. If you’re not familiar with Windows Registry, it’s recommended to start reading up on it. Start here.)

When malware arrives on a system, it’ll want to ensure that it’s run each time the computer is started. This means that when looking for malware, the first thing of interest is the so-called load point. If you find that, you usually also get an idea of where in the file system the malware is located. Autoruns (as the name suggests) conveniently provides us with an overview of most load points that can be used in Windows.

Now it may sound easier said than done, but to identify a malicious entry, there’s another skill you need to master as well: Identification of legitimate objects. For that reason, before looking into a simple malware infection, let’s have a look at a sample entry that’s present on a clean Windows 10 installation. Below is an image of an Autoruns scan (Figure 1). Let’s start at the top.

Autoruns scan clean windows 10

Figure 1: Autoruns Scan – AlternateShell / cmd.exe

The first file we see is cmd.exe, which is listed under a registry key named AlternateShell. To determine whether or not this is legitimate, two things are of interest:

  1. Is the file legitimate — is this the real Windows cmd.exe or is it something that calls itself cmd.exe in order to fool us?
  2. Is the load point normal for this file?

We can also search for “cmd.exe” online (by right clicking the entry and selecting Search Online). On the first page of search results you’ll find explanations of what the legitimate cmd.exe file is, but also examples of how malware can use this file name, so that is not really conclusive. To be sure this is a legitimate Windows file, we can check its location instead (default is the system32 folder) and scan it on VirusTotal (right click and select Submit to VirusTotal). In this case, the file is legitimate.

Searching for “AlternateShell” also proves useful. A search result from Microsoft Technet summarizes the purpose of AlternateShell as “Lists the name of the alternative environment used when the Safe mode with Command Prompt option is selected.”

We also see that cmd.exe is the default value, which means that the cmd.exe / Alternateshell line entry in our Autoruns report is legitimate and can be ignored, at least when it comes to malware removal. (Note: This is true in most cases. There is an outside case though, in which an otherwise legitimate entry with a legitimate filename has had its actual file replaced with a malicious copy — a topic for another day!).

Moving on, let’s look at a simple malware infection next. The trojan sample used can be found here. With this malware installed on the system, Autoruns looks as follows:

Autoruns scan trojan sample

Figure 2: Autoruns Scan – Trojan Sample

At first glance this might look like a whole lot of very confusing data, but fortunately Autoruns does sort the collected data by load point. It will also show the location of any load point which can be for example in the registry or the file system. When we start to analyze the data in the report (see Figure 2), two lines jump out: both of them contain a string of letters and numbers while all other objects have a humanly readable name of some sort. According to Autoruns the objects are located in:

You can see that the first questionable entry is a registry key and the second, a folder. These two locations are among the most commonly used load points by both malware and legitimate applications. If you want to ensure that your application runs when Windows is started, you can use either of these locations.

Let’s start with the easiest load point: the Startup folder. According to Autoruns, a file named “edf6e17148b3b3408342ac7be2e79536.exe” is located in that folder. Before looking any further, this raises two red flags already:

  1. You usually expect to see shortcuts (.lnk) in the Startup folder that will run an application on startup, not the actual executable (.exe) file.
  2. The file name is just a random-looking string, with no indication of what it might load. You would expect a name that indicates what application is loaded, in combination with that application actually being present in the computer.

To confirm our suspicion here, we can right click the object in Autoruns and select the “Check VirusTotal” option. This will provide a link to the VirusTotal scan results, which confirms the file is indeed malicious and should be removed.

Now let’s move on to the other load point, the run value. If we open this entry in Regedit by right clicking and selecting “Jump to Entry”, this is what we see (see Figure 3):

Regedit Snapshot

Figure 3: Regedit Snapshot

Again, without even checking the details of the file, there are already a few alarm bells ringing because:

  1. The value name is a random-looking string without any indication of what program is being run.
  2. The value data points to a file named svhost.exe in the Temp folder, not to be confused with svchost.exe which can be a legitimate Windows file that usually resides in \Windows\system32.

Moving on, we see that Autoruns provides additional information and has extracted some metadata from the file. We can verify this by opening the file Properties (right click the file and select Properties). (See Figure 4):

svhost metadata

Figure 4: Metadata – svchost.exe

Apparently the file’s product name is “Windows Serivce” (sounds pretty legitimate, even though there’s no real Windows file that has this product name and there’s a typo in the word “serivce”). The Original Filename is “game.exe” which isn’t something normally associated to either svchost.exe or any Windows service. A VirusTotal scan confirms that this file is malicious as well.

To confirm if both objects identified belong to the same infection or not, you can compare both VirusTotal reports. You can determine this by going to the Details tab in the VirusTotal results, and you’ll see that the file hashes are identical.

Malware Removal

Now that we’ve identified two files and one registry object that need to go, we’re finally ready for the actual removal. Autoruns does have a “delete” option, but the malware sample we’re studying may be actively running (and is running in this case). As mentioned before, malware may simply re-add itself if removed, or even stop the removal attempt. Autoruns isn’t able to remove it in that case. We could use Windows Task Manager to attempt to stop the malware, but it’s a fairly limited option. A better alternative, especially in malware removal, is Process Explorer. Process explorer is a particularly good option because it provides a lot more information about listed processes compared to Task Manager as you can see here.

So now that we’ve already identified the malware, the last thing on our list is to find the offending process.

process explorer

Figure 5: Process Explorer

As you can see in Figure 5, only one matches all details of the bad entry: Our svhost.exe name, “Windows Serivce” description, and Temp folder location (you can see this by hovering the mouse pointer over the line). It’s important to verify an exact match, especially since “svchost.exe” is an otherwise legitimate Windows file name.

Once this process is killed (right click > Kill Process), all identified entries in Autoruns can be deleted without any problems. Please note that if Autoruns removes a registry load point, the associated file may still need to be removed manually.

An alternative solution would be to reboot the computer in Safe Mode which will load neither Run values nor Startup folder files. This method would have avoided the additional download of Process Explorer.

We hope you enjoyed this introduction to malware removal! We’ll be back soon with more specific examples of how to tackle specific infections (ransomware, PUPs, and more!). In the meantime, please remember, prevention is better than cure–start with a solid antivirus and anti-malware program and avoid the headache altogether.

WEBINAR ALERT: Watch out for our next webinar coming June 2018!

On-Demand: Manual Malware Removal

If you have any questions that you’d like Elise to address during the webinar, please comment them below or you can ask them during the webinar as well. Click here to learn more and to register for the webinar. Seats are limited. See you there!

Disclaimer: This article and the upcoming webinar are for demonstration purposes only. There are multitudes of malware variants and many need a different approach for removal compared to the method presented here. We’re aware there are exceptions to every rule and that methods aren’t always this straightforward especially when multiple infections may be present. However, covering all of those exceptions would not serve the purpose of this blog post. If you need assistance in removing malware from your computer, feel free to download our Emsisoft Emergency Kit and reach out directly to our Malware Analysts.

Emsisoft Enterprise Security + EDR

Robust and proven endpoint security solution for organizations of all sizes. Start free trial

Have a great (malware-free) day!

Elise

Elise

Malware analyst. I've always been interested in computers, especially anything (anti-)malware related and am usually the go-to computer person for everyone who knows me. The first virus I encountered was on DOS when I was 12 years old. The fact that our AV back then could "magically" make it go away sparked my interest.

What to read next