CHAPTER 15
Keyloggers and Malware
We’ll Cover
 
image   Defining keyloggers and malware
image   How to detect keyloggers and malware
image   Determining how the infection occurred
image   Identifying what data was captured
image   Finding information about the attacker
 
This chapter will cover the basics on how to discover the presence of keyloggers and malware on a forensic image. You’ll learn where to look for artifacts that can help provide the necessary evidence and information to push an investigation forward.
As a computer forensic examiner, you will eventually work cases that involve the use of keyloggers and malware. This may involve someone such as a past or present employee who has installed these programs in order to spy and steal confidential data from a victim over a period of time. It happens more often than you think, especially when it involves money and theft of intellectual property.
Defining Keyloggers and Malware
A keylogger is a malware tool that records a user’s keystrokes on a keyboard. Its purpose is to steal password and account information without the user’s knowledge. There are several types of keyloggers, but the two most common are hardware- and software-based keyloggers.
A hardware keylogger is a peripheral device that is physically attached between the keyboard and computer so that it can intercept and record all keystrokes. The following illustration shows two types of hardware keyloggers, one for a PS2 (top)—PS2 is an older keyboard/mouse connector not the game console—and the other for a USB keyboard.
image
image Note
A keylogger may be employed within an organization as a tool for purposes that do not involve malicious intent, such as for compliance, security, systems monitoring, and so on. However, this is rare and not the norm. To be clear, keyloggers are malware and should be considered as such.
 
Software keylogger programs are designed to work on the target computer’s operating system. These can be augmented with an array of other features as well. Not only can these tools record keystrokes, but they can record just about every other user activity, such as opening files and folders, opening programs, taking screen shots, capturing web-form text input, and so on, and then upload all this information to a remote location or create backdoors for remote access.
Software-based keyloggers come in a few flavors:
 
image   API-based Relies on a hooking mechanism to capture keystrokes
image   Kernel-based Intercepts keystrokes via a modified system driver for the keyboard
image   Form grabbing Intercepts or reads web-form data before it is submitted over the Internet
LINGO
Hooking mechanism refers to the ability to use functionality exposed by the operating system for legitimate programs for malicious deeds, in this case, if you attached to the keyboard filter to capture keystrokes instead of providing spell checking.
image Note
For more in-depth information on the different types of keyloggers, refer to the following wiki on keystroke logging: http://en.wikipedia.org/wiki/Keystroke_logging.
 
Finally, malware, short for malicious software, is typically used as a catch-all term to refer to any software designed to cause damage to a single computer, server, or computer network, whether it’s a virus, spyware, or other type of malicious program.
How to Detect Keyloggers and Malware
Keyloggers and malware are becoming more and more difficult to spot as their designers come up with more elaborate ways to install them and to keep their use hidden from their intended victim and avoid detection. In general, we know that malware can work its way into system startup, running processes, services, install/modify drivers, system files, and more.
Let’s begin looking for artifacts in the more common areas of the operating system for their existence, starting with registry files.
Registry Files
We’re interested in several registry files (hives). We’ll start by looking at the following:
 
image   HKEY_USERS   Documents and SettingsUser ProfileNTUSER.DAT
image   HKEY_USERS   UsersUser ProfileNTUSER.DAT (Vista/Win7)
image   HKEY_LOCAL_MACHINE/SOFTWARE   Windowssystem32configsoftware
image   HKEY_LOCAL_MACHINE/SYSTEM   Windowssystem32configsystem
After you navigate to the registry file of interest using your forensic tool of choice, right-click the filename and open it using your forensic software’s built-in registry viewer (with Forensic Toolkit [FTK]). In EnCase, you’ll right-click and select View File Structure; then navigate the registry hive within the tree view in the left panel. If your forensics software does not have a built-in viewer, you can use free registry viewers such as RegRipper, or you can download Registry Viewer from AccessData and run it in demo mode.
image Tip
With EnCase and SIFT tools, your time will be better served exporting the registry hives out of the system and using tools such as Registry Viewer or RegRipper to analyze them. You’ll find Registry Viewer at http://accessdata.com/support/adownloads and RegRipper at http://regripper.wordpress.com/program-files.
IMHO
I like to start an investigation examining the registry hives, because of the amount of information I can quickly glean as well as the chance of locating an artifact relevant to the case right off the bat. This information can be very handy to have on hand if I’m asked to provide a quick status update.
Registry: User Profiles
Who else has been accessing this computer? This question gets asked all the time, no matter what type of case you are working on. Using Registry Viewer, let’s start by examining the ProfileList registry key at HKLMMicrosoftWindows NTCurrentVersion ProfileList. The ProfileList provides a list of accounts that have accessed this system. We are looking for any accounts that we do not recognize and were active during the timeframe in question. We can determine the last time a user was logged in by looking at the Last Written Time.
An easy way to determine when an account was first created is to navigate to the user’s NTUSER.DAT file, as pointed to in the ProfileImagePath shown next, and look at the creation date.
image
Registry: Run Keys
To begin looking for a malware infection, examine the registry Run keys. The following list contains the latest Windows registry Run keys, where you can look for any rogue startup programs:
 
image   HKLMSoftwareMicrosoftWindowsCurrentVersionRun
image   HKCUSoftwareMicrosoftWindowsCurrentVersionRun
image   HKLMSoftwareMicrosoftWindowsCurrentVersionRunOnce
image   HKCUSoftwareMicrosoftWindowsCurrentVersionRunOnce
image   HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerRun
image   HKCUSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorerRun
Typically, these registry keys will enumerate any programs that are executed at startup and provide the paths to their locations. If you see any programs that you do not recognize, make note; then navigate to the file’s location and examine its properties and creation date. Lastly, search online for the filename and see what you can learn. If the file is part of a malware infection, it should become obvious.
The following illustrations show a nasty malware infection; the first shows an infection from the HKLM registry Run key, and the second shows an entry for a keylogger in the …PoliciesExplorer Run key.
image
Here are some other registry keys to examine that can kick off programs at startup:
 
image   HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogonShell
image   HKLMSoftwareMicrosoftWindows NTCurrentVersionWinlogonUserinit
image   HKLMSoftwareMicrosoftWindowsCurrentVersionShellServiceObjectDelayLoad
image   HKLMSystemCurrentControlSetControlSession ManagerBootExecute
image Note
For more information and to learn about other things to look for in startup programs, refer to the following Microsoft TechNet link: http://technet.microsoft.com/en-us/magazine/ee851671.aspx.
Registry: System Services
It is not uncommon for a malware infection to have services associated with it. We can look to see what services were active at the time at the following registry key: HKLM SystemCurrentControlSetServices.
image Note
Be thorough in your analysis, because it is easy to overlook items and perhaps miss an important clue. Remember that it is getting more difficult to detect rogue services because their creators do not want them to be discovered.
 
Services will typically point to some sort of driver, *.sys, file located in the Window/ System32/drivers directory or an executable file located elsewhere. If you see something that looks suspicious, you will likely have to look up the filename online to see if you can find information such as location, version, size and/or hash values to compare against.
Registry: UserAssist Key
Another place of interest is the UserAssist registry key within the user’s NTUSER.DAT. It is possible to find an entry of interest here, which is why it is worth a look. Once you have the User’s NTUSER.DAT files open, navigate to HKUSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist.
UserAssist entries are encrypted using ROT13 when viewed through Regedit in Windows, as shown in the next illustration. Lucky for us, AccessData’s Registry Viewer decrypts these for us automatically. Otherwise, if you are using EnCase, you will need to hunt down an enScript program to do it. Here is an example of what a ROT13 entry looks like before it’s deciphered:
HRZR_EHACNGU:P:QBPHzragf naq FrggvatfHfreNQrfxgbcsha.rkr
image
Using RegRipper, you can run rr.exe and select ntuser for the plug-in, as shown here:
image
Then do a quick search in the report file for the word “userassist” and you’ll locate the entries shown here:
image
Prefetch Files
The prefetch is another area you will want to examine at the beginning of your investigation to detect a malware infection. Windows prefetch (.pf) files contain trace log information for files such as executables (.exe) and dynamic link libraries (DLLs) that an application depends on when it is executed. You can find prefetch files within the following directory: WindowsPrefetch.
When first examining prefetch files, it’s helpful to sort them by their creation date to assist you in going through them. You’ll notice that the prefetch files contain the filename and extension for applications being executed as part of the filename. When you come across an application filename that looks suspicious, examine the file’s contents. Fortunately, prefetch files capture filenames and locations for not only the application being run, but also for the files it depends on, as shown in the following example (ZIP.EXE-61C23F93.pf):
image
Prefetch files contain a wealth of forensic information. With this information, you may be able to reconstruct a timeline of events as they happened on the system. When you’re examining the prefetch, look for the following information: the time of initial infection, how the infection spread, and, possibly, additional pieces of malware. Some malware will download other malware to the system shortly after the initial infection.
Keyword Searches
One of the most powerful tools at our disposal is the keyword search. It is especially helpful in finding commercial keyloggers. If you suspect that a forensic image contains a keylogger, begin with a search for the word “keylogger” and see how many hits you get. Commercial keyloggers market themselves as being stealthy and undetectable, right?
image Tip
You can create a keyword list that contains names of popular keyloggers and other words that you think will generate hits and import them into your search directly if your forensic tool supports it.
 
Another great thing about keyword searching is that as you go through the search results, you will find other words to search for. It will take a bit of time to go through the results, but you will eventually hit paydirt. Even the expensive, highly rated commercial keyloggers such as WebWatcher leave plenty of artifacts.
It didn’t take too long to find this little Micro Keylogger gem—just one of many:
image
image Tip
Once you know the name of the keylogger, do some research to see if you can locate and download it. Then you can set up a virtual machine and install the keylogger on it to study its behavior. You can use a tool like the open source RegShot to perform before-and-after file/registry comparisons. This can really aid you in an investigation; it is sort of like having your very own cheat sheet to use as a reference. You can find RegShot at http://sourceforge.net/projects/regshot.
Handling Suspicious Files
So what are your options if you should come across files that look suspicious? I would recommend exporting any suspicious files found in the registry keys or other places to a directory and then uploading the files via the Web to jotti.org (http://virusscan.jotti.org/en), ThreatExpert (threatexpert.com), or a similar automatic analysis site.
Jotti.org will run multiple antivirus packages against submitted binaries and report how they are identified. This can greatly help in your research, since some vendors use a generic name for certain malware, while others will give each variant a specific name. Some vendors do a better job of explaining how a piece of malware works and what files/ directories it touches, including MD5 signatures of associated files.
Determining How an Infection Occurred
After you have detected the presence of malware and/or a keylogger on the user’s system, you can begin figuring out whether this is just an unfortunate random infection or whether something a bit more sinister has occurred.
Start by asking the following questions:
 
image   What was the user doing at the time of infection?
image   Was the user at work, checking e-mail, surfing the Web?
image   Was the user away, perhaps home asleep during this time?
Once you know some of the files that are associated with the malware/keylogger, you can use their creation dates to identify the period of time the infection likely took place. This is where timestamps come into play. Sorting actual files based on creation, modified, and last accessed dates will help you determine what kind of activity was taking place around the time of infection. You will also want to check the application, system, and security event logs located in the Windows/System32/Config directory to see if you can find additional info. Make sure to look for remote logins! (Sometimes, event logs are not recoverable or logging was disabled. It is truly amazing how many company laptops and workstations have security logging disabled by default.)
image Note
You will need to export the event logs out to view them within Windows Event Viewer. If the logs appear to be corrupted, try viewing them within Event Viewer on the same operating system as the user’s. Other third-party tools are also available, such as FixEvt by Rich Murphey (www.murphey.org/fixevt.html).
 
In the earlier example involving Run keys, one of the filenames of interest that was discovered from the HKLM registry Run key was lj1ioi6l.exe. Keyword searching that filename yields interesting results. Figures 15-1 to 15-4 show search results in EnCase and FTK.
image
Figure 15-1   EnCase keyword search
image
Figure 15-2   EnCase search results
image
Figure 15-3   FTK indexed search
image
Figure 15-4   FTK search results
Viewing the contents of the deleted file, 2491_appcompat.txt, shows us a XML table. This file was located in the user’s Local SettingsTemp directory. Figure 15-5 shows a snippet of the contents of the infected file.
image
Figure 15-5   A portion of the infected file’s contents
After you’ve spent some time keyword searching the filenames in conjunction with doing a bit of research online, it won’t take you too long to realize that the infection is associated with a fake virus scan malware software. The big clue was the file yyxxyyouaffm.exe. Searching the filename within the image turned up an interesting bit of text with timestamps within the index.dat file, as shown in the following illustrations:
image
What We Know About This Infection
From the artifacts that we have collected, we can start piecing together what took place. This is what we know:
 
image   We have a XML table containing names of malware files.
image   We have entries in index.dat for the virus scan pop-up: yyxxyyouaffm.exe /alrt.htm.
image   The user was infected on 12/13/2010 at 12:13 P.M.
image   Research on the Internet shows yyxxyyouaffm.exe to be some variant of affm.exe, which is a known virus scan malware.
What We Know About the Keylogger
Let’s continue with our analysis of the keylogger. We need to know how the keylogger made it onto the machine. We know that after analyzing keyword search results and also looking at our …PoliciesExplorer Run key entry, we were able to locate a directory created during the keylogger installation called syslogger. Using the directory’s creation date, we sorted all actual files around the timestamp. This yielded more artifacts that were associated with the keylogger installation. However, we have yet to explain how the keylogger made it on to the computer—that is, until we noticed a couple of LNK files.
The first illustration shows the LNK file properties, and the second shows the LNK file contents:
image
Let’s take this a bit further, now that we have some new information. Searching for the keyword “myprog” yields an entry in a Windows Defender log file, shown here:
image
It seems that the install program for this keylogger could very well have been notepad.exe. Fascinating. Perhaps someone was trying to be clever and hide his tracks by renaming the keylogger as an install file. Take a close look at the following log file entry:
[root] ProgramDataMicrosoftWindows DefenderSupportMPLog-07132009-221054.log
It turns out that this Windows Defender log provides a wealth of information. This file included many other entries for infected keylogger files being scanned.
Next, let’s look at the USBSTOR registry key to look for information on the removable disk mentioned within the LNK file. The USBSTOR registry key is located at HKLMSystemControlSet001Enum. Examining the registry key, we find an entry that matches the time on the LNK file. If the custodian of the machine in question is unaware of this removable disk, then it appears that someone else had access to the machine and attached the following thumb drive:
image
Notice that the Last Write Time is shown in UTC; in this case, it is +5 hours. UTC, or Universal Time, which is also known as GMT or Greenwich Mean Time, is a way to normalize time so it can be adjusted with offsets to reflect whatever time zone the user is in. We can see more detail about the device in question here; we’ve seen this registry key before in Chapter 14:
image
In an investigation, it is possible for you to verify that you have acquired the USB device that is believed to be the actual device in question. The serial number from the USB device will match the unique ID found in the USBSTOR. To retrieve the serial number from a USB device, you can do the following:
 
image   Use a USB write blocker that will display the information on its display screen.
image   Try using forensic imaging software to pull the serial number.
image   Use a registry hack, as detailed in Chapter 8, that will disable USB writes on a test box; then attach the USB device, and then compare USBSTOR entries to see if you have a match.
We have collected a lot of artifacts. So what can we accurately say now about the keylogger?
 
image   We know its name: Micro Keylogger
image   We know the creation date of the install syslogger directory: 5/12/2011 at 8:11 P.M.
image   We know that notepad.exe was executed off a removable disk: 5/12/2011 8:11 (possible install program?)
image   We know that a LNK file was created for a removable disk: 5/12/2011 at 8:10 P.M.
image   We know that a Centon DataStick Pro USB was attached, with a last write on 5/12/2011 at 8:10 P.M.
Identifying What Data Was Captured
So how can we tell what data was captured off the user’s machine? This question will be asked, so you might as well be prepared to answer it. We know that from an earlier artifact, where we learned the name of the keylogger, that reports are being generated. Perhaps it is taking screenshots, too? Fortunately, we were able to locate the Micro Keylogger web site (http://www.microkeylogger.com/), which advertises that its product performs the following:
 
image   Records passwords typed in browsers and applications
image   Records Facebook, Google, Yahoo!, and web site passwords
image   Records Skype, AIM, MSN, and game passwords
image   Records all keystrokes typed by the computer users
image   Records all web sites visited, applications used, and files downloaded
image   Monitors stealthily and undetectably
image   Monitors multiple user accounts in the system
image   Captures desktop screenshots by interval
Using this information, our next step would be to locate the files used to generate reports. Through timeline analysis, we should be able find the files/directories that we are looking for, based on last modified, last accessed, and file creation times. We’ll sync up these file MAC times against system events and MAC times for malware files already discovered. Filtering files for “actual files” and file types such as documents, graphics, and so on, would make the task easier.
The next illustration shows how lucky we are in identifying the data that was captured:
image
image Note
Be sure to document your findings and export the files out for review.
In Actual Practice
There will be times when you’ll have much less information to go on. Even more challenging is if the malware is taking extra steps to avoid detection—perhaps utilizing packed binaries—and uses encryption, data wiping, obfuscation, or other methods to hide its tracks. This will make forensic analysis more difficult. A possible next step would be to re-create a safe test environment and boot a copy of the forensic image inside a virtual machine to perform live analysis. This would involve the use of system monitoring and network scanning tools, taking before-and-after snapshots of the system, and performing other types of analysis to study the malware’s behavior as it reacts to user interactions on the live system. Performing this kind of analysis is difficult, and your findings may not answer the question of exactly what data was taken. Hopefully, your efforts will be rewarded at least in part by your gaining an understanding of how the malware behaves and what it was designed to do.
Performing a live analysis requires serious time and research, and there is no guarantee that you’ll get decent results. Make sure that this information is communicated to the client and let them decide if you should proceed or not before taking on such a large task.
Finding Information About the Attacker
During the forensic analysis, in this case with a keylogger, we know that data is being captured—but where is it being sent to? Another artifact that our “stealthy and undetectable” keylogger left behind was a help.html file. And, yes, it truly was a help file. It has examples and directions on how to connect to various webmail accounts and upload to an FTP server.
Once again, we rely on our wonderful keyword search to see what we can find. Let’s see if we can identify any webmail accounts. Having a keyword list for various webmail accounts such as Yahoo!, Gmail, Verizon, Hotmail, and so on, will speed things along.
In this case, our search located a Gmail account as well as a couple of Yahoo! accounts and a Verizon account. It was the Gmail account that panned out. Keyword searching on the Gmail account name located a bit of XML text located within the slack space. Not only were we able to retrieve the e-mail address login, but we also found the password for the account. (By the way, I changed the actual login/password in the following illustration.)
image
Suppose the attacker was uploading data to an FTP server or was logging in remotely to download the captured data. What should you examine in those cases? Should you expand your investigation to include Active Directory servers and have a look at the firewall logs? You will probably want to include a look at proxy/web content filtering logs, VPN logs, DHCP server logs, and so on. Sometimes, the smoking gun comes from evidence outside the forensic image you are analyzing.
What We Know About the Attacker
It looks like we got lucky with that webmail address. Here’s what we know about the attacker:
 
image   We know that his keylogger data is being transmitted to a Gmail account.
image   We know his login to the Gmail account.
image   We know his password for the Gmail account.
In Actual Practice
If you find login information, refrain from logging into a webmail account. Accessing a webmail account—or any other type of account for that matter—without expressed authorization is a legal pitfall you will want to avoid. Remember, you are not technically authorized to proceed. You are better off reporting your findings and letting counsel decide what the next step should be.
Where to Find More About the Attacker
Using the timestamps from the artifacts that you will collect during an investigation as reference, what else would you want to examine to see if you can uncover any more information? The answer depends on the type of attack that has occurred, but here are some other areas of focus that you will want to think about:
 
image   Software/hardware firewall logs
image   Virtual private network (VPN) logs
image   FTP uploads
image   Internet Relay Chat (IRC) logins
image   Active Directory logs
We’ve Covered
This chapter covered the basics of how to discover the presence of keyloggers and malware in a forensic image. You learned where and how to look for artifacts that can provide the necessary evidence and information to push an investigation forward. I’ve given you a good primer here to start your malware analysis career, but you can go much deeper. Start here, and when these techniques can’t uncover the answer, it’s time to turn to the blogs and resources listed in Chapter 2 to go further.
Defining keyloggers and malware
 
image   Malware is a catch-all term to refer to any software designed to cause damage to a single computer, server, or computer network.
image   A keylogger is a malware tool.
How to detect keyloggers and malware
 
image   Know where to look to find malware.
image   Find all the places malware can locate itself to run.
image   Work with the system services in which malware can hide.
Determining how an infection occurred
 
image   Work with prefetch files.
image   Perform a keyword search for malware fragments.
image   Identify malware sample using online scanning sites
Identifying what data was captured
 
image   Profile your malware.
image   Research your malware to determine capabilities.
image   Find logs and files related to your malware.
Finding information about the attacker
 
image   Define what you know about the attacker.
image   Determine how to profile the attacker.
image   Find command and control or where the data is being sent.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.139.105.114