Backdoor Shell Game Face-Off
Backdoor Shell Game Face-Off
Backdoor Shell Game Face Off
By Ed Skoudis
Michael Roesoft worked on the Computer Incident Response Team for a software development company. On a Sunday evening, while watching the thrilling John Travolta / Nicholas Cage DVD, Face/Off, Mike received an urgent page from his network-based Intrusion Detection System (IDS) on the DeMilitarized Zone (DMZ). The IDS had detected various backdoor commands being sent to one of the company's web servers. Due to the nature of the commands being sent to the web server, Mike nearly wet his pants when he got the page. Clearly, Travolta and Cage would have to wait while Mike solved this case.
The web server in question was a Windows 2000 machine, running Microsoft's IIS product. IIS has had more than its fair share of vulnerabilities in the past, so Mike quickly assumed that the web server was taken over by the attacker who had installed a backdoor. The web server sat on the same DMZ as a Windows NT DNS server, a Linux-based FTP server, and a Windows XP Mail server. The DMZ was constructed using a simple layer-2 switch connecting all of these machines, as well as a firewall, together on a single LAN.
According to the particular alert from the IDS, the attacker had viewed the /etc/passwd and /etc/shadow files on the web server machine. Additionally, the attacker had altered the /etc/hosts.equiv file on the machine to extend its trust relationships. Mike carefully reviewed some sniffer logs from the DMZ, and observed that commands to view and edit these files were going to and from the IP address of the Windows-based web server.
Mike conducted a port scan of the web server, and found no ports open, other than the expected TCP ports 80 and 443 for HTTP and HTTPS. He also scanned the rest of the DMZ, and found no suspicious port usage on any of the boxes.
Mike also ran Tripwire, the file integrity checking tool, on the Windows web server, and found no alterations of any system files. The web server looked clean. Curiously, though, when Mike viewed the ARP cache on the firewall connecting the DMZ to the rest of the world, he noticed that the IP address-to-MAC address mapping for the web server was messed up. The web server's IP address was mapped to the MAC address of another machine on the DMZ.
Where should Mike look for the real backdoor?
What kind of backdoor tool was the attacker using and how did the backdoor receive its commands?
What mistakes had the attacker made?
What types of tools should Mike use to look for the back door?