Project - Hacking Recovery

Upon my arrival to work I was alerted of low disk space on the Microsoft Small Business Server. The server was available, but I needed to free up disk space immediately.

Goals:

• Ensure server uptime and that employees can save their files as needed
• Determine who hacked into the server
• Recover the server and improve security

Using a third-party security tool to explore disk usage I noticed that the FTP Incoming folder had large files in it. In following security advisories, I found a new article advising that a user could effectively become the FTP service, and perform FTP uploads / downloads while bypassing standard security. The Microsoft Small Business Server was known to have certain security issues as it had a number of conflicting services running on it. As the FTP service needed to remain functional, I shut down the FTP port on the Internet firewall. The firewall logs indicated that the attack was spawned after a port scan and was limited to just that one server. The server logs confirmed that only the FTP service had been breached. Using a third-party security application that identifies which files and folders a selected user or service has access to and the last time they were accessed, I validated that the breach was limited to the FTP folders.

The logs indicated that somebody uploaded a few files that were then downloaded by multiple people over the night. In reviewing the files, I noticed that they were Medical Books. I worked to remove the files, but the attacker was using a Unix system, so there were characters unfamiliar to Windows in the file names which could not be removed. Remembering that the Windows NT 4 File System is based on POSIX, I downloaded a utility that gave me direct access to the file system completely outside of the operating system, and used it to rename the files and folders, later using the windows interface to delete those files and folders. I also used the POSIX tools to ensure that there was no hidden information on the disk. The operating system required the FTP service to remain running, so we left the port down on the Internet Firewall to thwart future attacks - we were not concerned with internal attacks at the time.

As the vulnerability did not disclose any passwords or require any user names to be provided to function, no passwords were revealed or discovered during the attack. The FTP Service had no interaction with any other services running. Therefore no passwords needed to be changed. The server remained up and functional during the incident and did not need to be rebooted. To help validate my findings, I ran a security analyzer program to ensure that the files, folders, users, and services on the server remained as expected by Microsoft. Of course, I kept Executive Management abreast of all progress at appropriate times.