For the final lab the teams will be taking all that they have learned this semester and applying it to an attack against a target system. Each team will be given a target system from another team’s lab environment. It will be the responsibility of each team to harden the systems, give the information to the adversary, and for each team to try and exploit the target system. If successful the team will place a text file indicating a successful exploit within the C: drive or root folder. After the file is placed, the team will use anti-forensic methods to cover their tracks. The combined knowledge and planning will be important in having a successful attack against the targeted system. Upon completion of the week each team will describe what was done to exploit the target system, if they were successful, and additional findings from the lab. From the findings each team will be able to conclude with the experience and thoughts from attacking a targeted system.
Lab seven deals with the one of the last steps in a penetration test as far as the attacker is concerned, covering their tracks. With increased public attention on security breaches on government and corporate computer systems, the field of digital forensics has been making headway into the important step of attribution and prosecution of the acts. While there is, undoubtedly, much work still to be done in the field of digital forensics, researchers and vendors have developed tools to aid the process.
One new field that is a logical branch from the original is anti-forensics. The goal of anti-forensics is to cover the attacker’s steps making it either difficult or impossible to trace the attack back to its source. There are many ways anti-forensics can be employed ranging from simple log file deletion to sophisticated kernel root kits that obfuscate system calls or even return bogus data in response to probes from investigators (Casey, 2006, p. 49). In addition to gathering the log files from a compromised host, Casey brings up the difficult task of locating the source of the attack. If the intrusion is a simple one-time break in to gather data, an attacker may simply use traffic anonymizing services such as Tor as well as using open proxies that may be hosted in other countries. If the attacker plants a root kit or malware on the system for later use or continuous data gathering, a command and control (C&C) network will have to be employed to allow communication between the software and whoever is controlling it. C&C networks can be a source of information to investigators but attackers are all too aware of this. By obfuscating the traffic using time delays and encryption, they can evade detection (p. 50). In addition to obfuscating network traffic, (Bailey, Coleman, & Davidson, 2008) shows how to obfuscate programs during execution. By writing the code in such a way that it changes enough for pattern recognizers to miss it yet still executes the same function, students in the “Defense Against the Dark Arts” class learned how viruses and anti-virus software work (pp. 316-317).
“Defense Against the Dark Arts” echoed a paper we previously read in lab five, “Viruses 101” (Aycock & Barker, 2005). One item that appeared to be missing from (Bailey et al., 2008) that was a major focus of “Viruses 101” was any mention of objections from the teaching institutions where the class was taught because of ethics issues. While they did show that ethics was part of the first week of materials (p. 316), no other mention was made of the topic. Though this is likely due to differing audiences for the topics, it’s surprising that “Defense Against the Dark Arts” was taught in two different institutions with no mention of objections by the administration. (Holland-Minkley, 2006) was another paper that mentioned the ethical issues surrounding a “cyber attack” class though the focus of that paper was the outcomes of general user awareness of computer security topics.
As we’ve seen with previous lab activities, the best way to attack a system is to study and understand the methods that are defending it. By taking a similar approach to forensics, an attacker can analyze current methods of forensic studies and the tools used to obtain forensic data and formulate a specific plan for covering their tracks. (Casey, 2006) shows advanced methods and tools used to investigate security breaches. The paper mentions the use of network traffic captures that could be used to replay the attack as it happened (p. 51). If an attacker were aware of this type of system being used at the target, they would likely alter their strategy for interaction with the network and use either source obfuscation or encryption to hide their actions. Forensic data can be gathered from running memory as well as virtual memory (pp. 51-52). A sophisticated attacker looking to hide their tracks would need to not only erase their tracks in log files stored on the hard drive but by erasing traces of their activities from RAM and the page file on the hard drive. Because of the physical properties of hard drives, an attacker would need to not only delete or wipe the page file from the system, but attempt to overwrite the space on the disk enough times to successfully hide their attack.
The important aspect of this operation is the human knowledge associated with identifying the target’s defensive measures. This is a major weakness that is missing from (Upton, Johnson, & McDonald, 2004). In the paper, the authors discuss methods for executing automated red teaming exercises (pp. 1-2). While this brute-force, “try, try again” concept appears regularly in the field of penetration testing, it leaves traces of activity on the system. Since the goal is, most often, the successful exploitation of the system, little concern is given to the aftermath of the actions or the legal or political implications of the attack.
This lab consisted of three main parts. First we set up the target system and provided its IP address to the adversary team. Next we executed our exploit plan against team one, our target team’s, system. Finally we performed an analysis of our target system to determine if team four had been successful in exploiting our system. For setting up and securing our target system, we chose to utilize a system that we had difficulty exploiting in lab six, Windows XP SP3. Following the lab guidelines, we referenced (Souppaya, Kent, & Johnson, 2005), the NIST guide for securing Windows XP. In order to expedite the process, we utilized the security template files provided with the document, specifically the Specialized-Security Limited Functionality (SSLF) template. Per the guide (pp. 60-61) we changed the password of the Administrator account to a 12-character complex password including upper and lower case letters, numbers, and symbols. We also changed the username of the administrator account to “user2” to obfuscate its presence (p. 64). To protect our system at the network level we implemented Windows Firewall with only two ports allowed through, port 3389 and port 5828. Port 3389 is the default port for Remote Desktop, required by the lab for access for the instructor. Instead of keeping remote desktop on the standard port we moved it to port 5828 and left 3389 open to throw the attacking team off. Finally we performed a Windows Update on the machine to ensure it was fully patched. Once we had completed all of these steps, we sent the IP address of our system to the adversary team and the professor through e-mail.
The second part of the lab was to attempt an exploit of team one’s system. Once we’d received the IP address of the system from the team we waited two days before performing any attacks. We coordinated an attack with team two to attempt to obfuscate the source of the attack traffic. Both teams started out with a full intensity , full TCP port scan using Nmap version 5 to generate excessive amounts of network traffic from differing IP addresses. Next, we both performed a Nessus scan against the host to determine if any of the open ports our Nessus scan had turned up contained any vulnerabilities. The scan reported multiple vulnerabilities, of particular interest were MS04-007 and MS04-011. Team five and team two chose to exploit separate vulnerabilities to minimize the chances of our payloads conflicting with each other. We both used the “windows/shell_bind_tcp” payload utilizing different ports to bind them to, again to avoid stepping on each other. Once we’d successfully established our shell sessions we placed files on the root of the C: drive of the machine with our team name and system time for exploitation. In order to obfuscate our efforts after the file was placed, we attempted to stop the event logging service to delete the event log files but both of our shell sessions hung and we were not able to reconnect to the machine.
The final step of the lab was to analyze our target machine created in step one for any evidence of attack. Throughout the lab exercises we had another machine running a packet capture of all traffic in and out of our target machine. By doing this we were able to secure the captured traffic from deletion by the adversary team in the event that the target machine was compromised. We witnessed numerous port scans and a few intrusion attempts utilizing Metasploit, indicated by the attempts at connecting to port 4444 after the attempted exploit. Metasploit utilizes port 4444 as the default port for binding the payload shell to. Though we noted numerous attempts, we did not see any successful exploits in the packet capture logs nor was the required file present on the C: drive of the target machine.
This lab put our exploit skills and, most importantly our defensive skills to the test. In our considerations of securing the target system, we looked over previous lab exercises and noted the successful and unsuccessful methods we’d used to exploit other target machines and devised countermeasures for them. We also took in to consideration the anti-forensic methods that could be employed by the adversary team. By thinking like the adversary, we devised the method of performing our traffic captures on another machine. By doing this we hide the fact that we are, indeed, capturing the traffic. By securing the second machine with a different set of security protocols and passwords we eliminate the chance of the adversary team utilizing the same method to exploit the target machine.
Attacking team one’s machine seemed too easy based on conversations with members of that group, the exploits used were five years old. Once we had established our shell session on the target machine we looked around for a few minutes to make sure that we had logged on to a real Windows machine and not a carefully obfuscated Linux host with an open Telnet server. As we later found out, another machine, likely an XP SP0 machine, had assumed the IP address team one had delivered to us.
Based on the absence of the file indicating a successful exploit on our target machine, we believe that the defensive measures utilized provided a good defense against network-sourced intrusion attempts. While the security measures may be a bit too stringent for standard use, they did allow use of standard applications and web browsing. We had experimented with utilizing IPSEC for securing any inbound or outbound traffic but the policies proved difficult to manage, severely impacted usability, and violated the lab requirements of providing the instructor with a method of connecting in to the machine.
As mentioned in the findings, team one had an issue with another machine taking the IP address they had provided to us. Since the subnet utilized DHCP, this would have been highly unlikely unless the machine they had provided us had received an IP address form the DHCP pool and then had been set to use that IP address manually.
While we did not get the chance to perform a forensic analysis of our system or fully exploit a target machine and employ anti-forensic tactics to hide our tracks, we feel we still learned a lot from this lab. Thinking the process over of how we’d proceed with an analysis of our machine if it were compromised gave us ideas for use when we were attacking our target machine. This keeps with a common idea of this entire class, “the defense is the offense,” especially seen in the labs where we research exploits in vulnerability databases, used vendor configuration documentation to find exploits, and used the OSI model for categorizing our exploit tools.
Aycock, J., & Barker, K. (2005). Viruses 101. Paper presented at the Proceedings of the 36th SIGCSE Technical Symposium on Computer Science Education.
Bailey, M. W., Coleman, C. L., & Davidson, J. W. (2008). Defense against the Dark Arts.
Casey, E. (2006). Investigating sophisticated security breaches. Communications of the ACM, 49(2), 48-55.
Holland-Minkley, A. M. (2006). Cyberattacks: A Lab-based Introduction to Computer Security.
Souppaya, M., Kent, K., & Johnson, P. (2005). Guidance for Securing Microsoft Windows XP Systems for IT Professionals: A NIST Security Configuration Checklist.
Upton, S. C., Johnson, S. K., & McDonald, M. J. (2004). Breaking Blue: Automated Red Teaming Using Evolvable Simulations. Paper presented at the Genetic and Evolutionary Computation Conference 2004, Seattle, Washington.