SUMMARY OF THE PFE ATTACK

Up to this point in the book, we have discussed a rather simple attack against a developer workstation at PFE. After finishing your investigation you determined that the breach was caused by the john user having a weak password. It seems that in early March 2015 an attacker realized that the subject system had a john user with administrative access and was connected to the Internet while exposing SSH and FTP servers.

It is difficult to say exactly how the attacker came to have this knowledge. He or she might have done some research on the company and made some reasonable guesses about Mr. Smith’s username and likely level of access on his workstation. The attacker doesn’t appear to have sniffed John’s username directly from the FTP server, as there would have been no need to crack the password if this were the case, since the login information is sent unencrypted.

You can tell that the username was known, but the password was not, because the attacker used Hydra, or a similar online password cracker, to repeatedly attempt to login as the john user until he or she was successful. The fact that success came quickly for the attacker was primarily the result of Mr. Smith choosing a password in the top 50 worst passwords. The logs reveal that no other usernames were used in the attack.

Once logged in as John, the attacker used his administrative privileges to setup the bogus johnn account, modify a couple of system accounts to permit them to log in, overwrite /bin/false with /bin/bash, and install the Xing Yi Quan rootkit. We have seen that attacker struggle and resort to consulting man pages, and other documentation, along the way. Had Mr. Smith been forced to select a more secure password, this breach may never have occurred, given the attacker’s apparently low skill level. What does incident response look like when the attacker has to work a little harder? That is the subject of this chapter.