Abstract
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.
Literature Review
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.
Methodologies
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.
Findings
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.
Issues
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.
Conclusions
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.
Works Cited
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.
This group’s abstract is lacking. The abstract mostly is a summary of what is involved in this lab. The beginning of the abstract does mention that this lab takes all the other labs and applies them to an attack against a target opponent. This could have been expanded on and less could have been said about what was involved in this lab. The team could have explained more on anti-forensics, since this was the topic of the lab, and tied anti-forensics to the rest of the course. They could have also explained the importance of anti-forensics. The beginning of the literature review would have made a better abstract. The team’s literature reviews do a very good job of tying each article into another of the articles given in this lab. The literature reviews also do a good job of explaining anti-forensics. The literature reviews do not do a good job of tying the articles into this lab though. Some of the articles are very briefly skimmed over while others are discussed in detail. The team does show some errors and omissions to the articles, but they do not discuss the research or methodology of the articles. In the methodology the team starts off by explaining how they hardened a Windows XP SP3 operating system. They explain that they changed the passwords and usernames of the system. They also opened up two ports, 5828 and 3389. The port 5828 was opened to allow an opening for the professor to remotely connect to their system. The other port, port 3389, was opened to throw the opposing team off. They also updated the operating system to the most current patches. The team then explains the way they attempted to penetrate team 1’s computer. They joined forces with team 2 to hide their attacks. They started off by scanning the target system using Nmap and Nessus to discover any vulnerabilities. They state that they did discover a couple of vulnerabilities on the target system. The team did not know though that the target machine they were exploiting was team 4’s Windows XP SP0 machine, which was not a target machine. The group then explained how they analyzed their machine to watch for any attacks on their system. They explain that they did detect multiple scans and multiple attempts to connect to the system, but none of them were successful. Some of the methodology talking about the analysis of the team’s hardened computer could have been discussed in the findings section. In the findings the team starts off by explaining how they used previous lab results to devise a plan to harden their target computer. They explain that thinking like an adversary allowed them to come up with a method of performing packet capturing on a separate computer to monitor team 4’s activities against their system. In the next part of the results the team confesses to finding out that the computer that they had attacked seemed way too easy to penetrate and that later they found out that machine was one that had gained the same address as the actual system they were trying to penetrate. Last in the results the team fined that they were not compromised and that their means of securing their system utilizing the NIST documents a success. They also make the point that securing a system this well lowers the usability of the system and does not allow for more than normal activities. In the issues the team explains that the IP address given to them was taken by another computer because of a problem with the DHCP pool. They did not consider the fact that there was a lot of ARP poisoning going on in the network. In the teams conclusion the team explains that they learned that a good defense is a good offence.
I do not agree with the first sentence, stating that all that we have learned so far is basically how to attack a system. We have done more than that. We also learned how to protect a system from attack as well, indicated by last week’s lab experiment. I believe the purpose of the final lab is to teach people how to properly protect their systems. An attack was the only good way to prove whether a team learned this or not. If an attack was successful, this means that the team did not learn what they should have. In the abstract when talking about the anti-forensics, the team states that after the file is placed, it will be used. They never talk about what it means if the file is NOT placed in the root folder. The abstract was so much an overview of what the team did, but rather an overview of what every team will be doing. One could place this abstract into other team’s lab reports and would not have seemed out of place. Write the abstract and make it your own. It seems like that this literature review was written before the attack was done. Without a file getting placed on your machine, you are not able to perform the anti-forensics part of the lab.
Once again, team 5 has a literature review that is LESS than the required amount of 100 words. About 110 words less to be exact. The literature review does have a good introduction into the first article. I would like to have seen the team go into more detail about forensics, this would have made their literature review long enough. Whenever the team discusses “Defense against the Dark Arts” I can’t help but think about Harry Potter. Why? I have no idea. In learning how to defend yourself against the “Dark Arts”, are you not learning how to use them as well? What is stopping people from taking this knowledge and using it for ‘evil’? How well did the team study the system they were attacking before the actual attack? Was any research done before the attack began? The methods section should be written so the lab experiment could be replicated. For people that do not know how to perform what team 5 did; a more detailed methods section is needed, as well as screenshots to show success or failure. What was it like to think like the adversary? For team 5 it might have been more difficult than it was for my team. I know how my adversary would think. Sorry for any issues that team 1 may have given you when attacking our machine. Thanks for sharing our IP address with other teams.
Team five continues to have the same issues as team one even with the completion of their final lab in their abstract. That abstract is only one paragraph long. According to the syllabus, any abstract that is less than two paragraphs will be judged as poor scholarship. With the completion if lab seven, and in essence the course, I am then forced to question the scholarship of team five. My math may be wrong, but one is just slightly less than two. I fail to see the problem in providing the required number of paragraphs explaining what the lab will be about. But in that regard team five does do a good job of explaining the purpose and tasks of the lab. The literature review presented by team five is also lacking. Team five does have a very good level of cohesion among the articles presented for review, as they always do. However, the literature review is only 824 words long if you include the introduction paragraph, and 741 words long without that paragraph. The syllabus for course clearly states that each literature review needs to be 1000 to 2000 words long. The size of the literature review presented by team five is lacking. Again, while it does show a high level of cohesion among the articles, I must question the scholarship of the review as not meeting the requirements for a graduate level course. However with the completion of the final lab in the course, I think this once we can let that slide. The methods section presented by team five is also very good in explaining the step they took to complete the lab. I do question some of the methods as possibly actually belonging in the finding section. I also see no discussion of the who and when and the why of their methods. The How and the what of the methods are discussed in detail, but a good academic methods section should include the who, what, where, when why, and how of what is going to be happening in their findings or results section. As such this does not make for a scholarly or academic methods section. I do agree with their methods though as team two was involved in portions of the steps that team five completed. Team two does clearly remember hacking a system using the IP address provided by team one to team five, but team one claims otherwise. Including that information in slightly more detail would have been very good. The methods and the findings presented by team five are much like the methods and findings presented by team two and show that because steps and results are much the same, accurate and reputable processes and procedures were followed. The findings themselves are in line with their methods. The conclusions presented by team five are consistent with the outcome of their lab, and based on them I find that their lab and the work they did in the course were completed in an ethical and professional manner.
In the abstract section, team five gave an overview of what was to be accomplished in this final laboratory exercise of the semester.
In the literature review section, team five was able to relate the articles to each other. However, some of the summaries seemed to brief and the articles did not always relate back to the course and laboratory assignment.
In the methodology section, team five stated that they used Windows XP service pack 3 and used NIST documentation and templates to help harden their system. The team enabled Windows Firewall with only two ports allowed through, port 3389 and port 5828. Team five teamed up with team two to attack team one. The teams ran Nessus against the target system and the scan revealed multiple vulnerabilities, of particular interest were MS04-007 and MS04-011. The teams used “windows/shell_bind_tcp” on different ports and were able to get a shell on the target system and place the text file on the C: drive. The groups tried to stop event logging, but this action ended their shell session.
In the findings section, team five came to the realization that the system that they attacked was far too easy and as it turned out was not the target system after all. Where the Windows Service pack 0 machine with the same IP address as team five’s target came from no one will ever know. Team five had also stated that their machine was never compromised, for the text file that would indicate such an event was not found on their drive.
In the issue section, team five listed the IP address conflict with team one’s system and the random Windows XP machine that was using the same IP address.
In the conclusion section, team five stated “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.” I have to agree for to analyze what is present or absent in the security settings will determine what type of attacks could be conducted.
Team 5’s abstract was well written and really set the stage for what they were going do in lab 7. They explained in detail how lab 7 will work and what is required of all the teams involved. Once again team 5 did a nice job with their introduction and in writing a cohesive literature review in that they tied their lit review back to previous labs. This was good because it shows an understanding that this course has been set up for each lab to build upon the previous lab.
Team 5 had one of the most detailed methods sections of all the teams. Their findings section was very detailed. I liked how they talked about thinking like the adversary as this is something I need to improve upon as I delve deeper into internet security. I think their conclusion was well written and I agree with their common idea of this class being “the defense is the offense”. Seems like other teams thought this course was designed to teach us penetration testing. Overall this is a good lab, well written and cohesive.
I found team fives write-up for this exercise relatively straight forward both in methodology and results. The literature review, while somewhat brief, did appear to address important points from the articles. In an interesting move, team five compared a current article with one from a previous week: nicely done. I also found team five contemplation of IPSec for use during the exercise interesting.
Despite the numerous positive aspect of team five’s report, a few deficiencies exist. As far as application of the article to the exercise or the course in general, no more than a trivial reference was made. While I have no problem with the description of this team’s defense plan, I believe in the offensive end this team actually showed that very little ‘planning’ was done. The description of offensive based activities unfolds more as “what happened” rather than “how we proposed to accomplish the goal.” In fact, the offensive plan appeared to: be “do nothing for two days, then hit a target of opportunity with team two.” I realize that this may indeed not be all that was done, however as no mention of reconnaissance or research was made preceding this attack, one is left to wonder. I ask: would it not have made sense to actively scan the target at the very beginning of the exercise, so that this information could be used to prepare an effective attack? Even if the target detected this scan, and reacted by going off line for an hour, the consequences were quite negligible when measured against the valuable information which would be gained.
Further, I admit to being somewhat unsure what was being said in regards to the “second machine” used for traffic capturing in the results section. Did this mean that such tools as Ettercap were used to intercept the traffic to your own “defended” VM? If so, how would securing this machine insure that “same method to exploit” your machine could not be used by the other team? Couldn’t the opposing offensive team capture traffic in the same manner as you described? Did you mean to imply that you secured your second machine from being “turned against” you in offensive way? I believe this section to be very sparse on details: a more precise wording or more information would have made this section easier to understand.
Finally, while I see that team five expressed some suspicions with regard to the strange circumstances involving the attack on team one; I feel they likely should have devoted much more discussion to this issue. Evidently, the machine attacked was a VMware based host, as team five did not indicate that this was found to be otherwise. If this is the case, team five failed to ask the crucial question: why would this machine be in use on the network during this exercise? What team would think of putting such a vulnerable machine on the network for any purpose at such a time as this, other than for use as a dedicated target? Furthermore, even if the confusion originated from DHCP problems, this is certainly the fault of team one for not maintaining a reachable address. The original assertion made on Sunday; that insuring correct addressing “is the responsibility of the team who reported the IP address to us” is absolutely correct: you should not have backed down from this statement. From all appearances, team five has been the victim of underhanded dealings: but if they will not stand up for themselves, who else will? Certainly, this incident presents an opportune time to apply a bit of the forensic concepts associated with the laboratory goals.
The team’s abstract is well written. The literature does a good job of tying the various articles together and tries to relate them to the class. I would have liked to see more detailed discussions of each article. Your review really doesn’t say much about them other than the piece by Casey. Also, one of the required readings was skipped completely. Is anti-forensics its own field, or is it a subset of forensics? What was different about what Holland-Minkley did? Are there flaws in Bailey et al that go beyond the dissent of institutions? What was it that Upton et al were really doing?
The methods section is well written and repeatable. Why leave a port open? I understand it was supposed to be a diversion, but why take the risk? The extra machine capturing traffic was a nice touch. But was it a specified step for security in the NIST document?
The findings were adequate for the report. Do you feel that a less clean environment would have changed your results? Did you consider that someone may have ARP poisoned the network and redirected your attack to their own attacking machine when you were able to easily exploit team one? Isn’t watching network traffic a form of forensics?
The conclusion is a bit unclear. It wraps up the class, but not really the experiment. What did you learn here? What would you have done differently?
Team 5 begins their abstract by describing the red teaming exercise that will be conducted during lab 7. Each team will have their own system to defend, and another team’s system to attack. Each team will use anti-forensics to hide their own attack, and forensics to investigate the attack on their own system.
Team 5 continues the discussion of forensics and anti-forensics in their literature review. They discuss using kernel root kits for anti-forensics and refer to the article by Casey on how root kits can be used to hide an intrusion. He also includes several other ways that an attacker can hide that were included in the Casey article. He also refers to the article by Bailey, Coleman, & Davidson on how programs can be obfuscated during execution by changing so that pattern recognizers cannot detect them. They also discussed the article “Defense Against the Dark Arts”, which describes a course in computer viruses. They mention that the article does not include any objections from the academic community.
Team 5 again discusses the Casey article and how it discusses advanced methods and tools that can be used to investigate security breaches. Examples of advanced techniques include capturing data from RAM and virtual memory. Team 5 makes a good point that it isn’t enough for an attacker to cover their tracks by deleting a file, but would need to overwrite the space on the disk that the file occupies.
Team 5 began their methodology section with the three main parts of lab 7. The three parts included set up a target system to be attacked, attempt to attack another team’s system, and finally perform an analysis of their own system to examine the nature of the breach if any had occurred. They described the system that they set up to be attacked as a Windows XP SP3 and secured it using the NIST guidelines for securing it. They used the security template file SSLF to expedite securing the machine.
Next, Team 5 describes their attack against Team 1’s target system. They state that they were able to find two vulnerabilities which they were able to exploit. After placing the file in the root system they attempted to stop the event logging so that they could delete the event log files. At that time their shell sessions hung and they were unable to reconnect.
In the final step, their analysis of their target machine showed several port scans and attempts to compromise the system using Metasploit. They did not, however, find the required file in the root directory of their target machine.
In their findings section, Team 5 discusses the exploit of Team 1’s target system. They determined that they had not, in fact breached the security of Team 1’s target, but had compromised a system that had spoofed the IP address of Team 1’s target. Team 5 also determined that their own target machine had not been compromised because the required file had not been placed into the root directory.
Team 5 concluded by discussing the amount of knowledge gained in this lab. Although their target system was not breached, they determined a plan for conducting the forensic investigation in the event that it had. They also learned to think like an attacker when hardening their system.
I think that group 5’s write-up for lab 7 was fair. The abstract for this lab was good and provided a good overview of the lab. The literary review was very good, in terms of summarizing the readings. Group 5 chose to write the literature review as one big comprehensive review, which is good; however most of the required questions were not answered. It seemed as if the literary review was nothing more than a summary of the required readings and did not include any speculation about the research methodology or any errors or omissions, though they did they indicate how it relates to the laboratory. All of the citing for the literary review was done well and all of the pages were included. For this lab, the group answered all of the required questions and provided a good amount of detail about the steps they performed to attack the target systems. The team accurately covered the methods and findings of the lab. However, the team should have done the forensic analysis of their system, being as the point of the lab is anti-forensics not attacking. Overall, most of the required questions were answered and answered well. Finally, the conclusion was adequate and summarizes what was covered.
This team also did Windows XP SP3 as there machine to harden for attacks from another group. Like team four, they used a document from NIST to secure there machine. The team also changed the password to the administrator account to 12-character password with a mixture of upper and lower case letters, numbers and symbols which adds complexity to the password and is more difficult for password guesses. The team also renamed the and give it more of a general user name to mask the administrative privileges. Windows firewall, which seems to be a constant with Windows XP teams, was enabled and configured for only two ports. Finally the team ran Windows update to ensure that the machine is fully patched.
The team used a popular tool among the teams, Nmap. They discovered two vulnerabilities that the team found interesting. They used the windows/shell_bind_tcp payload which allowed them to successfully established a shell session and placed files on the root of the machine there were exploiting. However when the team attempted to stop the logging service to delete the event that took place, there shell connection was not responsive. This team seem to have had a partial success.
@mvanbode @nbakker – I have a hard time believing your criticism of “poor scholarship” of the lit review and/or abstract when you’re reduced to counting words and paragraphs.
@gdekkerj – The second machine was simply another VM we brought up with the ability to log network traffic using Wireshark. The purpose for this machine was to capture all network traffic related to our target machine for use in the event it was compromised so it wasn’t as much for defensive purposes as for forensics. While we were suspicious of the ease with which we compromised the machine, we weren’t certain what to make of it. We thought maybe they had made it intentionally easy to compromise to make it more like a honeypot.
@mborton – The port was left open to facilitate easy access to the instructor if needed. We knew that few vulnerabilities exist in terminal services that could lead to remote execution of arbitrary code and our accounts were secured enough against brute-force or password guessing. The capture machine wasn’t specified by NIST, we interpreted the requrement of securing by the NIST (or vendor) guide only to apply to the target machine, not the entire system. ARP poisoning was considered but we thought it was likely just a misconfiguration. One thing I still question is why was (what we now know was team 4’s xp sp0 machine) the system still on?
@prennick – a review of your peer review…of sorts. I was hoping to see more from you on our asserted (yet incorrect) compromise of your team’s machine. How was the networking configured on your team’s target machine? Did your team notice any unusual network traffic that would have indicated ARP poisoning?
Thanks all!