INITIAL LIVE RESPONSE
Upon arriving at PAS, you plug your forensics workstation into the network and start your netcat listeners as shown in Figure 9.1. Then you plug your response flash drive into the subject machine, load known-good binaries, and execute the initial-scan.sh script as shown in Figure 9.2.
FIGURE 9.1
Starting a case on forensics workstation.
FIGURE 9.2
Loading known-good binaries and performing the initial scan on the subject.
Upon examining the log file generated by initial-scan.sh, it quickly becomes apparent that something is amiss. One of the first things you notice is that a shell is listening on port 44965, as shown in Figure 9.3. Using netcat, you perform a quick banner grab on this port and find that it reports itself as SSH-2.0-WinSSHD, as shown in Figure 9.4. After doing some research, you discover that this is a dropbear SSH backdoor. You attempt to SSH to this machine which confirms your suspicions (this is also shown in Figure 9.4).
FIGURE 9.3
Part of the initial-scan log file. Highlighted portion shows a shell that is listening on port 44965.
FIGURE 9.4
Banner grab and SSH login attempt that confirm the existence of a dropbear SSH backdoor on port 44965.
So far we know that something has happened, because a backdoor has been installed. Examination of failed login attempts reveals a long list of failed attempts for the john user via SSH on May 3 at 23:07. This is shown in Figure 9.5. It is not yet clear if these attempts occurred before or after the backdoor was installed.
FIGURE 9.5
A large number of failed login attempts within the same minute.
Further analysis of the initial-scan.sh log reveals a new user, mysqll, with a home directory of /usr/local/mysql has been created. Furthermore, the user ID has been set to zero, which gives this new user root access. The relevant part of the log is shown in Figure 9.6.
FIGURE 9.6
Evidence of a bogus user with root access.
You give Dr. Potslar the bad news, that his webserver has in fact been compromised. When he hears of the backdoor, he makes the decision to replace the webserver with a new machine (it was time for an upgrade anyway). A new machine is purchased from a local store, and a friend of yours helps PAS install a fresh version of Ubuntu on the machine, install and configure Snort, set up a webserver with fresh code from the webmaster’s code repository, replicate the MySQL database from the webserver, and switch it out for the existing server. Your friend works closely with the webmaster so that he can perform this process unassisted should the new server become re-infected.
Your work is far from over. At this point you know that the machine was compromised but not how and why. Once the new server is in place and verified to be working properly, you use LiME to extract a memory image and then shut down the subject machine by pulling the plug. According to your initial-scan.sh log, the machine is running Ubuntu 14.04 with a 3.16.0-30 kernel. As you already have a LiME module for this exact configuration, dumping the RAM was as simple as running sudo insmod lime3.16-0-30-generic.ko “path=tcp:8888 format=lime” on the subject system, and then running nc 192.168.56.101 8888 > ram.lime on the forensics workstation.
You pull the hard drive from the subject computer and place it into your USB 3.0 drive dock. Using the udev rules-based write blocking, as described in Chapter 4, and dcfldd, you create a forensic image of the hard drive which you store on a portable 6 TB USB 3.0 drive with all of the other data related to this case. Even though the chances of finding a remote attacker are slight, you still need to figure out what happened to prevent a recurrence. Also, we have not yet performed enough analysis to rule out an insider who could be prosecuted or subject to a civil lawsuit. It never hurts to be able to prove the integrity of your evidence.