How to…Respond to Attacks
Either computer criminals have become increasingly intelligent over the past several years, or breaking into systems has become much easier. Each day, there are more attacks on companies’ systems. Tracking these incidents and prosecuting cyber-criminals has become a vital part of security in today’s computer-driven world. It’s no longer enough to simply know how to lock down systems—now we have to know how to track the intruders after they successfully compromise a system.
What is required of a successful forensic technician? For starters, time is of the essence. If you catch an intruder six weeks after the fact, it will be difficult to effectively preserve evidence, and to properly identify and prosecute the perpetrator. Second, you should make an immediate decision: Which is more important—catching the crook or recovering your system? Unfortunately, they are both important, but given the circumstances and resources, you need to establish a priority. Often, the most important option will depend on the circumstances of the attack. If the attack takes place on Friday night, then the services might not be needed until the following Monday’s business day. You can place catching the intruder on top of your list. However, if the attack takes place on a Monday after a three-day weekend, you might have be more concerned with getting systems and services back online—and worry about the criminal later.
Another major player in this decision-making process is the available resources, such as backup systems and cash. If you can afford to bring up an alternate system and keep the compromised system in pristine condition, this is the best-case scenario. Your final consideration is how best to respond to the attack: Do you have the resources (and desire) to go after an attacker? Many companies are able to perform moderate incident response and gather plenty of information on any given attack, but lack sufficient resources to follow through with prosecution.
The weapons needed to perform fast and accurate incident response—often called the forensic toolkit—should be chosen carefully. If you modify the evidence, the possibility of prosecution is slim.
One important thing to consider when selecting forensic tools is how each tool will affect existing evidence. The best tools provide the most verbose output and barely touch the compromised system. This means they must run primarily from RAM. If you plan to use tools that must be installed, it is important to make a bit-for-bit copy of the drive, to preserve as much information as possible. The main problem is that some tools require a shutdown of the computer to perform the copy, and as you probably know, shutting down the computer loses all data in RAM.
The order in which you perform these tasks can mean the difference between a successful prosecution and a total waste of your time and resources. My current forensic toolkit includes the following:
- Netcat (www.vulnwatch.org/netcat/): Allows remote connection, download of data and code execution.
- PrcView (www.foundstone.com): View and manipulate running processes on a system (pv.exe).
- ForensicToolkit20 (www.foundstone.com): All of the following are downloadable as a kit: Afind (searches NTFS volumes for files that have been changed, given certain times and dates), FileStat (displays statistics on files, such as last date or time modified and accessed), HFind (locates hidden files and displays latest file-access date or time), Hunt (user enumeration) and SFind (locates files that could be used to hide or encrypt other files).
- Helix (www.e-fense.com/helix/): A Knoppix Distribution of Linux built specifically for incident response.
- F.I.R.E. (biatchux.dmzs.com): Forensic Incident Response Environment.
There are more tools available out there, and some are free, but there also are companies that specialize in producing forensic software that often require a purchase.
Now, let’s look at the steps to take after a compromise has occurred. First, you must define the type of system that has been hacked. The purpose and method of attack will depend greatly on the service(s) running on the compromised system. For example, Web servers are commonly hacked using buffer overflows or Unicode strings. By identifying the purpose of the server, you can look for fingerprints that indicate the method of attack.
For example, on a Microsoft Windows 2000 Server running SP2 and ISS 5.0, you can review the Web logs for fingerprints. You might see entries similar to the following if you have been a victim of a Unicode attack:
2004-11-12 13:00:37 – 80 GET
/scripts/..%5c../..%5c../..%5cwinnt/system32/cmd.exe /c+dir 200 1849 321
31 HTTP/1.1 x.x.x.x
Mozilla/4.0+(compatible;+MSIE+5.01;+Windows+NT+5.0) – -
This reveals that the contents of the C-drive were requested. So using your knowledge of systems and the common attacks used for those systems, you can fingerprint the attack and discover how it took place.
You should have a pretty good idea of what type of attack took place and must answer the all-important question: What reason do they have to attack the system? The answer to this question can give you a pretty good idea of what damage has been done. They have gained unauthorized access. Now, discover what they did with it.
The result of this access often can be obvious. The consequence of their actions may have been the tip-off, or how the security breach was discovered in the first place. If the Web server has been defaced, then you know they were simply after the glorification of being a “l337 hacker” (1337 is “elite” in hacker language). The better hackers will not leave obvious traces, but they might use your server as a base for a larger plan. In this case, break out your forensic toolkit and discover as much about the compromised systems as possible.
Start out with RAM—the better hackers will load their tools into RAM so it leaves no hard trace of their actions. Using Helix will give you the contents of physical RAM in a user-friendly form. Helix also will provide MD5 hashes for all the information gathered, which will prove to be important for legal reasons. If you’re planning to prosecute the attacker, it is necessary to prove the information is in perfect condition, and has not been tampered with. Although it might be tempting to use the operating system’s built-in process viewer (TASKMGR.EXE for Windows), you should never rely on a compromised system’s tools for forensics. They are often replaced with versions that serve to hide the hacker’s activities.
Suppose the following was found in the file “pslist.htm” from Helix output:
nmapserv 384 8 2 35 596 0:00:00.062 72:45:43.156
Nmap is often used by network administrators to perform vulnerability testing. You obviously wouldn’t be testing network security from a Web server in the DMZ of your network. But an attacker can gain valuable information using Nmap from inside the network. You also can see that the service has been running for 72 hours, providing a timeframe of when the attack was under way. Based on this information, you might look to see if the attacker has compromised other systems in the network. You also might check the running services to see if the attack created a back door. The following is output from the “psinfo.htm” file from Helix:
DISPLAY_NAME: Wireless Zero Configuration
Provides automatic configuration for the 802.11 adapters