Is Malware Even There?
One of the first questions to ask when you notice malware-type activity is this: Does malware even exist on the system? It’s not uncommon for employees who are caught browsing Web sites outside of corporate policy to blame it on malware. Sometimes employees will actually use malware to cover up their hacking activities. If you have something to correlate and show that the malware exists, you have a starting place for where to look. If you don’t, then just as with any other forensic investigation, you will want to start from the beginning, triage the data, and drill-down on things that look suspicious.
Finding Malware
Depending on the sophistication of the malware, the prospect of finding it can be fairly straightforward or somewhat difficult. We have identified a few places to start that can be very helpful in tracking down where the malware resides.
Registry Keys and Startup Files Copious numbers of registry keys are on a Windows 2000 and later computer that can be used to initiate software when the computer is booted up or a user is logged on. These keys are a good first place to look for suspicious software. Several of these keys live in the individual user’s registry hive, so if you find malware in one of these keys, you can then start to narrow down how the malware made its way onto the computer.
It’s important that you perform this analysis using a forensic registry viewer. If you use a tool such as regedit, it may not show registry keys that have null entries, and this is a common way that malware will attempt to hide itself from investigators.
Here are the locations to look for auto-running malware:
• Software registry files
• MicrosoftWindowsCurrentVersionRunServicesOnce
• MicrosoftWindowsCurrentVersionRunServices
• MicrosoftWindowsCurrentVersionRunOnce
• MicrosoftWindowsCurrentVersionRunOnceEx
• MicrosoftWindowsCurrentVersionPoliciesExplorerRun
• MicrosoftWindows NTCurrentVersionWinlogonUserinit
• MicrosoftWindows NTCurrentVersionWinlogonNotify
• MicrosoftWindowsCurrentVersionShellServiceObjectDelayLoad
• MicrosoftWindowsCurrentVersionExplorerSharedTaskScheduler
• NTUSER.DAT registry files
• SoftwareMicrosoftWindowsCurrentVersionRunServicesOnce
• SoftwareMicrosoftWindowsCurrentVersionRunServices
• SoftwareMicrosoftWindowsCurrentVersionRun
• SoftwareMicrosoftWindowsCurrentVersionRunOnce
• SoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerRun
• SoftwareMicrosoftWindows NTCurrentVersionWindowsload
In addition to the registry keys, you should check several batch and startup files to see if any suspicious programs are started:
• c:autoexec.bat
• c:config.sys
• c:windowswininit.ini
• c:windowswinstart.bat
• c:windowswin.ini
• c:windowssystem.ini
• c:windowssystemautoexec.nt
• c:windowssystemconfig.nt
Virus Scanner Logs Many of the modern-day malware tools can change or modify the system’s virus scanner in an effort to hide detection. Take a look at the logs and look for evidence of things such as malware that was detected that is no longer being detected (this can indicate the signature was removed from the scanner’s database), out-of-cycle signature updates that don’t look like they were initiated by the software company, and large gaps in the scanning process. If you note that the virus scanner logs a daily scan of the system and it mysteriously stopped for a two-week period, that can be an indication that malware has done something to stop it.
Hostname Lookup Files Malware can attempt to disable the update capabilities of the virus scanners and other anti-malware tools by routing away the traffic of the computer from the scanner updates site to some other malicious update server. This is commonly accomplished by modifying the HOSTS or LMHOSTS file in the Windows system directory. Take a look at these two files: By default, there should be an active entry for the loopback and not much else. If you notice several errant entries, make a note of the last created and modified times of the file, as that can help to determine when the malware was placed on the computer.
Hash Analysis If none of the above has worked, your next task is to look to see if any operating system files have been modified. The best way to do this is to use the National Software Reference Library (NSRL) hash set for the operating system in question. If you compare the reference hashes provided by the NSRL to the system files on the computer, you will be able to tell if any of the vital files have been modified or changed, an indication that they have been taken over by malware. Tools such as EnCase and SMART allow you to apply this NSRL set to the image to find out which files are out of sorts.
The NSRL can be found online at www.nsrl.nist.gov. All the NSRL hash sets can be found on this site and downloaded for your use.
What to Do After You’ve Found It Once you find the entries and files that you believe are malware, it’s time to start figuring out when it was placed on the system and how it got there.
When Was It Placed on the System?
Generally, your next question after “Is there malware on the system” is “How long has it been there?” You can make use of some traditional computer forensic techniques to determine this. Just as with any other kind of malicious activity, you want to create a timeline to show when the events happened and what exactly occurred. Several tools in your forensics examiner’s toolbox can help with this process.
Determining When the Malware Was Placed on the System
Once you know how the malware is being started, you can quickly gather a few datapoints. For one, you know the name of the file that contains the malware and you can find it on the file system. Second, if the startup is occurring through a registry key, you can go to that key and look at the created and last-written times. Look at the created time on the file and the registry keys. This should indicate when the malware was actually placed on the machine. Once you know this time, look for other events that occurred around the same time. Check the virus scanner logs for that day and see if anything anomalous happened. Look for other files that have the same created or modified times as the malware, as that can indicate whether additional files have been infected or what the malware may have been targeting.
Where Did It Come From?
Next, you can begin to identify where the malware may have come from. Malware generally initiates from Internet downloads, infected software, or some type of third-party device plugged into the machine. Using the same type of forensic techniques used to look at the Internet history, software installations, and external device history can be very beneficial in these investigations.
Determining the Entry Vector of the Spyware
With the multitude of ways that malware can get on the machine, it is prudent to take a look at multiple data points to narrow down the potential entry vectors for the malware. Let’s take a look at several different areas that you can look at.
Internet History By far the most common entry vector we see is by some kind of Internet download. In addition, reviewing the Internet Explorer history has the added benefit that normally e-mail attachments and other file system activities can be captured by these logs as well. Your first task when presented with malware after finding the date and time it was placed on the system is to look at the Internet history for that timeframe. If you see that a suspicious Web site was being accessed at the same time the malware was placed on the machine, you should investigate the site and see if the malware did in fact come from that site. It is also common for the history to show the location of the malware as it existed in the Internet cache, even if the virus scanner has already removed it. As another added bonus, oftentimes malware will beacon back home using the Internet Explorer API. This means that any calls home or files it downloads m
ay be logged in the Internet history as well.
The main caveat with performing this Internet history analysis is to make sure that you carve the history and cache out of unallocated space before beginning. You may miss something if you deal with only active files, as the history may have aged out or, as a hiding mechanism, the malware may have cleared the Internet history and cache.
Installed Software In Chapter 18, we discussed how to identify what software was installed and when it was installed. This can be helpful in malware analysis, as the malware may have come from what the user thought was legitimate software. One example of this would be an application that assists a user in placing many different types of emoticons and smileys in e-mail. The user downloads it for free, thinking the people who wrote it are the greatest for giving it away for free, but the software actually installed a backdoor on the user’s system.
External Devices I can fondly remember back in 1992, when a friend brought the latest video game to my house on floppy disk. We put the disk into my computer, and 10 minutes later, the entire computer’s hard drive had been erased, having fallen victim to a virus. Before the prevalence of e-mail and the Internet, such disks were the main transmission method for malware. Although it isn’t nearly as prevalent as it once was, malware that uses USB and flash drives as the infection mechanism still exists. Take a look at the USBSTOR areas and see if any devices were attached around the time that the malware found its way onto the machine.
E-mail Messages In the late 1990s-early 2000s, e-mail was the transmission method of choice. E-mails would come into your Outlook inbox, promising nude photos of Britney Spears. You would click to open the e-mail and it would then send itself to everyone in your address book. The various e-mail clients have been armored quite a bit to help prevent such widespread transmission, but you still see it used from time to time, especially when the malware is targeted toward a particular group or company. Look for suspicious e-mails in the inbox that may have been opened around the same time as the malware hit the system.
What Does the Malware Do?
Now that you know what the malware is, how long it has been on the computer, and where it came from, you can start to look at what it was actually doing. Is it remote-control software that allows a hacker to take over a computer? Does it act as merely a processing center to crack passwords or send e-mails? Is it capturing information and sending that data to other servers on the Internet? Determining what the malware touched and the interactions of the software can be vital in the investigative process.
Determining Malware Capabilities
Determining what malware was doing and which areas of the computer it touched can be a very complex process. Entire books have been written on how to sandbox the malware and watch how it interacts with the system. While this is definitely an effective methodology, in some situations, this may not be possible. For instance, if you can’t find the malware itself, only evidence that it was on the computer, you will have nothing to sandbox. Also, some of the more advanced malware can detect when it is being monitored and “self destructs” to protect its intentions. Let’s look at some of the things you can look for without having to run the malware that may help in identifying the malware’s purpose.
Prefetch Files If you know the filename of the malware and it is a standalone .exe file, look for the .pf file in the PREFETCH folder (discussed earlier in the book). Note the created and last written times, as those can indicate when the malware was first and last run. Also of note is the content inside the prefetch files. As you know, the prefetch exists to assist with the caching of support files for the executable. This means that the .pf file will contain the actual names of files that the executable uses. In some cases, this can point you toward networking, user, and disk subsystems. Also, look for the filenames of temporary-looking files. These can be the data stores that the malware uses to store keystrokes and other user information before transmitting them to a central server.
Temporary Files Look for files that were created or modified either the first time or the last time the malware was run. This may require recovering what you can in the way of deleted files. It is not uncommon for malware to “bundle up” a day’s worth of keystrokes or logs and then encrypt them and upload them to a predetermined server. However, it is also common for this data to live unencrypted in the page file and temporary files. If you believe you know a particular key phrase or a document that was taken, run the phrase or sets of terms from the document as a keyword search across the hard drive. This can help in locating these files and can tell you what else may have been taken.
Operating System Changes Look for operating system files or registry keys that were created or modified during the created time or last modified time of the malware. This can help identify whether the malware has taken over any kernel-level subsystems or has otherwise left itself a backdoor in case something happened to the malware proper. In addition to looking for things that were created or modified in concert with the execution, you should also look to the NSRL hash set to see if anything on the computer has been modified from the known good installation.
Internet History and Network Logs In addition to determining when the malware was downloaded to the computer, checking the network logs and Internet history can also be valuable in determining what the software was doing. Look for evidence of the malware calling home or downloading updates. In addition, if you have a web proxy, you can actually use the proxy logs to determine the volume of data that may have been uploaded out of the company. These logs can also be key in determining the external IPs where the data was sent, which will be important if and when the investigation is taken to the next stage and authorities are involved.
Traditional Hacks
With all the talk of malware and bot attacks these days, it is easy to forget that sometimes you are dealing with a good-old-fashioned “hacker sitting behind a keyboard” attack. For these types of hacks, your understanding of how to re-create user activity can be a huge boost in the investigation of what the hacker was able to do on the system. Let’s take a look at some of the various audit trails we use in traditional forensics and see how they apply to determining the actions of a hacker.
Tracking Hacker Activity
Much as with malware, the first question you will hear when you notify someone that a hacker broke into their system is “What did they do to my computer/network?” Just as with IP theft or any other type of fraud, you can use the forensic artifacts on the system to determine what exactly the hacker did.
Reconstructing the Hack
You want to look in several places to determine what happened in a hack. Some of the places that we start with are the same ones we have discussed in the book, but with a slightly different twist.
Event Logs Depending on the level of auditing turned on in the policy, event logs can either be a real boon or completely worthless. If full auditing of the user accounts is turned on, you can tell whether a brute-force attack on the password was employed, what username the hacker was using to gain access to the computer, and what other accounts may have been compromised. Also, as applications may have been changed or modified by the hacker, these changes may be logged in the application and system logs.
Prefetch Files The PREFETCH folder can be invaluable in determining what tools the hacker employed. Generally, a hacker will download a toolkit in short order after gaining access to a system, which can include tools to download company files and crack passwords. If you find prefetch files for these tools, be sure to review the contents of the .pf file as well. The file will contain the directory from which the tool was run, and this can be extremely helpful in determining where the hacker stored his toolkit. In addition, if the hacker used a utility such as RAR to package up data before sending it off the computer, the prefetch file for RAR can actually contain the names of the files that were placed in the archive.
User Assist Logs Just as if a user is logged into the computer, when a hacker runs software on the
computer it is logged in the user assist logs. These can also be extremely helpful in determining not only what the hacker did on the computer, but also what username and privilege level he used to do his deeds. In matters for which the hacker actually took control of a user account, I have found these logs to be invaluable in the investigation process.
File System Analysis As discussed in Chapter 9, you can look for evidence of wiping and information hiding in many ways. These methodologies can be extremely helpful in the investigation of a hack. Look for mass deletions or evidence of shredding utilities being used. Frequently, when a hacker is alerted that he may be detected or has finished what he came to do, he will then undertake efforts to destroy the evidence and cover his tracks. And just as with any user who is trying to cover his tracks, evidence will be left over and you may actually be able to determine what was affected.
Internet History As stated previously, one of the first things a hacker does when he takes control of a computer is to download his toolkit onto the system. Sometimes, if he took control using a remote desktop type of application, he may literally open Internet Explorer and download the toolkit via the Web. This activity will show up in the Internet history, just like any other kind of network activity. In addition, any files that he opened on the system may be contained in this history as well. If you know the user account that he took control of, take a look at the Internet history for that user and see if anything was accessed.
Hacking Exposed Page 47