The client's first concern was the potential correlation between the posting of messages/content to a site that housed illegal images and the distribution of large files from its FTP Server. Was an employee using their FTP server to distribute pornography?
We advised the client that if it intended to prosecute, it would need to work within the legal framework of forensic investigations. Most notably, it would be critical for the forensic data to be authenticated as genuine.
Many of the actions an individual might take, including rebooting the machine, copying files from the server, and reviewing security logs, can alter the drive data. The client's management was adamant about conducting the investigation in a manner that would provide the opportunity to prosecute if necessary. The client's lawyer also believed that by demonstrating due diligence, it would minimise the risk of a third party taking legal action against the organisation as a result of the hack.
A particularly important legal case in the US, "Gates Rubber Co. vs. Bando Chemical Indus, Ltd," helped define the mandatory legal duty of a forensic investigator with regard to creating a mirror image copy of the hard drive in a manner that maintains chain of evidence and custody. In that case, the investigator's decision to perform logical "file-by-file" copying to preserve the evidence precluded legal use of the data because the copying might have resulted in lost information and the creation of new temporary files on the media.
Assessing the hack
We used Encase software, which is used extensively by law enforcement professionals, to gather a mirrored image of the drive. We then mounted it in a Windows 2000 machine but were unable to navigate/view the directory structure of the illicit FTP Server. There are a number of ways that hackers (and Windows itself) can hide directories and files. A simple way to make folders invisible (dependent upon Explorer settings) is to set a folder's property to +s[ystem] within Windows Explorer or via DOS. For example, although users may clear their Internet History, the data is still maintained in hidden files that can be accessed by an investigator.
Other methods include using device driver names such as "prn," "con," and "com1" or a special combination of characters such as "..--1" (dot dot dash dash 1).
To access the hidden directories and determine the content being distributed, we added the drive to a Windows 2000 Server and mounted it read-only from a Red Hat 9 Linux machine.
Assessing the facts before looking at the drive, we knew the following:
- A Serv-U daemon (a rogue FTP Server) had been installed by the hacker.
- This installation would have required administrator access.
- Microsoft Telnet server was running on TCP 2184 without NTLM authentication, enabling a malicious user to gain access to the system.
- An unknown service was running on TCP 3437.
- The penetration test manager advised that they had found directories within their FTP root they could not delete.
We first viewed the FTP root of the Serv-U daemon. Three files immediately caught our attention:
- 1kbtest.ptf
- 1mbtest.ptf
- space.asp
The first two files were used by the hacker to measure the available bandwidth of the server and gauge the efficacy of using this machine to conduct other attacks. The Space.asp Active Server Page was used to enumerate drives and their free space on the server. These files illustrate the dangers of anonymous uploads.
Next, we looked at the Serv-U daemon. Normally, Serv-U is run through the information contained in an ini configuration file. We searched the drive for .ini files and examined the output. This resulted in the discovery of r_bot.ini in the system directory (E:\winnt\system32). An examination of this file revealed that the attacker was using e:\winnt\system32\inf as his base of operations on the host. It also showed that the attacker was using IRC to remotely control the machine.
Further examination of the system32 directory showed the appearance of several suspicious files, all of which appeared on Feb. 17, 2003:
- info.exe—An enumeration tool to detail information about the local server to the hacker
- hlp32.exe—A renamed version of Bouncer v1.0.RC6, which is a Proxy utility
- jrun.exe—A renamed version of "Netcat," the TCP/IP Swiss Army knife of hackers
- kill.exe—A utility to allow the hacker to terminate processes that he did not want running on the box
- pslist—A utility that provides Proccess IDs for running processes (UNIX-like), which was likely used in concert with kill.exe
- wshell.exe—A Windows shell application (Winshell) that provided the hacker with a remote graphical user interface (on TCP port 3437), which was password-protected (we cracked the password)
- reg.exe—A utility to make it possible to edit the machine registry from a command line (DOS)
- service.exe—An IRC bot used to control the machine; notify that it's online
More anomalies present in the directory were IIS log file directories for February 15 through 18. An examination of the abbreviated logfiles showed the upload of the speed test files and space.asp page on the 15th. We could also observe the creation of a directory and upload of a copy of
Examining the winnt\system32\inf directory, we found the home directory of the Serv-U service. We saw that the attacker had created directories for applications, movies, and games. Files in these directories included an ISO image of Windows Server 2003 and movies, including an Indiana Jones movie and the documentary Bowling for Columbine.
Another directory found in \system32 provided further detail of the intruder's activity. This directory included the following attack utilities:
- sfind.exe—A command-line vulnerability scanner
- X-Scan—A command-line and GUI scanner
- IpcScan—A command-line and GUI Windows account cracker
We also discovered that the attacker had removed most of the log files generated by these tools. (They had been stored in E:\!!!!\SQLEXECl.) An examination of the slack space in the drive showed that the files had been overwritten. However, the entire Class B network belonging to a significant U.S. governmental agency had been scanned for vulnerabilities.
Turning the tables
In light of the potential liability associated with the distribution of copyrighted materials and the attack on government agencies, the client authorised us to attempt to identify the source of the hack. Most notably, we recognised that the attacker was very comfortable using IRC. We examined the communications of the installed IRC bot and determined the IP Address it was connecting to.
Using the information in r_bot.ini, coupled with these potential passwords, we attempted to access the attacker's password-protected chat room. Unfortunately, our attempts to guess the password were unsuccessful. Returning to the drive, we cracked a password by using an internally developed cracker that can identify potential passwords via regular expression searching. We returned to the chat room and conducted a whois to obtain information regarding the owner/moderator of the chat room
At this point, we knew which host the attacker was connecting from. Provided the host legally belonged to the attacker, we could obtain his identity from his ISP. From the IRC site, we identified nine additional servers that had been compromised in the same manner, including two universities and a large regional bank. (We notified the ISP and the owners of the IPs of our findings.)
We began with an attempt to verify whether this connection was being proxied. We discovered that the server at xxx.xxxxxx.xx wouldn't allow IRC connections from unsecured proxy servers. (Note: We've replaced all IP addresses with Xs.) We then probed the attacker's machine to view the available services.
We used nMap to identify the services running on the hacker's system and found that the attacker was using a Windows XP Professional machine, located in Belgium (determinable by an IP address belonging to a Belgium ISP). He was running a private Serv-U FTP Daemon on TCP 1412, as well as a publicly available Serv-U FTP service (port 21).
We could see that he employed a common tactic: By having a publicly available FTP site, loaded with his hacking tools, he could compromise a machine and download the tools and files he needed. Note the absence of any banner advising that the machine was private and that public connections were not allowed—so we were not actually "hacking" the hacker.
We then proceeded to download the contents of the FTP server. Examining the files, we could piece together his attack methodology and actions:
- He scanned for machines with vulnerabilities in Microsoft SQL Server, IIS, or NetBIOS.
- Once a victim was located, he downloaded and executed a batch file, which performed numerous actions before deleting itself.
- He created an account called Admin, set the password, and added the account to the Administrator's group.
- He FTPed necessary tools to the machine, creating directories within winnt\system32 to store them.
- He configured the Microsoft Telnet Service to run on port 2184, disabling NTLM authentication.
- He installed a WinShell Service on port 3437.
- He installed the Serv-U daemon and configured directories.
- He installed an unsecured SOCKS proxy.
He then patched the machine to prevent other attackers from using the same exploits:
- He disabled WebDav on IIS HTTP.
- He set RestrictAnonymous=1 in an attempt to prevent Null Session Enumeration. (This value should be set to 2 to be effective.)
- He deleted administrative file shares.
Based upon what we found, we were able to create specific Web queries to determine the attacker's real identity. Our final report to the client included this information about the hacker:
- Full name
- Date of birth
- Town in Belgium where he lived
- E-mail address
- Photograph
1%
1%
