Case Study: Snoop the User Desktop

Once on an internal penetration engagement, our team was given a conference room with a live network jack. The goal of the engagement was to assess the security of the client's back-end database servers from unauthorized access by company employees. We did not know much about the layout of the network, except that the target servers were behind a firewall and on a separate segment. We did know that the segment onto which we were allowed was populated by employee machines.

The company was running DHCP, so when we plugged in, we received a valid network address. The first thing to do was to discover the network. We ran the net view command (as shown below) to obtain a list of domains and user workstations within each identified domain that we could see from our current location.

C:\>net view /domain

And based on the results, we ran:

C:\>net view /domain: domain_name

Next, we tried a null connection to each machine.

C:\>net use \\machine_name\ipc$ "" /user:""

Once we had a connection, we attempted to determine whether there were any shares on these machines with the following command:

C:\>net view \\machine_name

Some shares on a few machines were identified. We then attempted to connect to those shares with the net use command and by trying some default user names and passwords. We successfully connected to several shares with the user name/password pair, administrator/<blank password>.

C:\>net use \\machine_name\c$ ""/user:administrator

Unfortunately for the company the local administrator account had a blank password.

Once connected, we were able to copy over, install, and run the remote control program VNC, allowing us to control that machine from our laptop.

One note: We had cracked the local administrator account on a desktop machine. This is not the same as the domain administrator account that has admin access to all machines. This local administrator had admin access only to this machine and its SAM file; it did not offer user IDs and passwords that could be used on other hosts.

At this point, we were ready to go forward and attempt to access the back-end servers with the information we had gathered thus far. Before doing so, however, we took a moment to look around this machine's file system and found a local copy of a Microsoft Access database. Since databases often contain interesting information, we copied this back to our laptop to examine. Once we did, we found that it contained sensitive client information. This was at least a partial copy of a database stored behind that second firewall layer.

While there were additional vulnerabilities that allowed us to get at this information (for example, allowed null connections, blank admin password), the Achilles' heel here is that an employee had kept a local copy of a sensitive database.

Lessons Learned

While securing all corporate information by keeping it on secure servers behind a second set of firewalls, monitoring with intrusion detection systems, logging any access, and using a change management tool are good ideas, the human factor cannot be ignored. You need to ensure employees do not keep local, unauthorized copies of any corporate information in less secure places (such as on their desktops). Ensuring that they don't will likely necessitate security awareness training and periodic checks either by searching file systems (raising a privacy issue) or by doing these kinds of penetration tests. Also, do not forget to secure the local administrator accounts on workstations. They can contain sensitive information as well.