Finding Known Evil With Nessus – Part 2

This post is a continuation of my earlier post about finding a known-bad process with Nessus vulnerability scans. In this post, I will share my experience after I finished running my first scan using this new scan policy.

Unlike the regular vulnerability scans, the duration of this scan was much less. The reason for this was because the scan policy consisted of only selected plugins. However, even with only selected plugins, the scan results were very comprehensive.

First, the scan result shows the MD5 hash of the suspicious process. Now you can take this MD5 hash and search sites like VirusTotal but on the scan results page, you will find a direct link to a Tenable website that will provide additional information about the suspicious process. This information is similar to what you would find on VirusTotal but with little less information. In my case, I still searched VirusTotal for more detailed information.

Second, the scan result shows the path of where the suspicious process is located on the target system. Obviously, this is great because now you don’t have to search the system and locate the executable in question. But what’s even better is that the scan results even show all the instances of that suspicious process that the scan found. For example, in my test scan, the same suspicious process was located under numerous user profiles.

With the above information in hand, you can quickly develop you indicators of compromise (IOCs) and begin your investigation. My initial step was to review all the processes on my target machine and identify the process ID (PID) of the executable that the scanner identified. From here you can look at all the network connections related to this process, the system handles, any additional sub-processes, etc.

Overall, I am satisfied with what I have seen so far. I think that it is great that Tenable has incorporated these checks because in my option it makes perfect sense to check for known bad stuff during the time that you have already allocated for vulnerability scans. However, I would recommend that you separate your suspicious process and vulnerability data because do you not want to alarm the system owners without properly doing your own investigation. The easiest way to do this is by creating two different repositories and then drafting different reports/dashboards from each of those repositories.

My final comment is that if you have Nessus (I used SecurityCenter); please try to run this scan with the new scan policy. You can find the link to download this scan policy in my first post. Let me know what you guys think!

Tagged , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Advertisements
%d bloggers like this: