Dantevios.com

So I guess someone has to post the solution for the most newb puzzle in Defcon Quals this year. This is the only puzzle I (of team Bulldogs) was able to get. At least we didn’t get completely stumped this year though and I’m happy about that. No hackers left behind guys! (lulz). The clue for Retro Revisited 100 this year was simply a message that said:

“____ ___ ______!”

If you closely examined the underscores, you’d see that there are 4 underscores, then 3 underscores, then 6 underscores. Using google kung fu, I searched for a long time looking up keywords like “retro phrases”, “retro defcon”, “retro hacker phrases”. I finally looked up “retro hackers”, which lead me to a dialog from the movie “Hackers”. I figured I was onto something because the movie Hackers is pretty old or “retro” and it has to do with hacking. In scanning through some of the phrases for the movie Hackers you will notice that there is one phrase in the dialog that fits the 4, 3, 6 pattern phrase you have to look for perfectly. That phrase is “Hack the Planet!”. I tried typing this in as the answer, but it was not working. I knew that phrase had to be it though, so then I tried typing it in in lower case as “hack the planet” and the board accepted my answer.

http://www.imdb.com/title/tt0113243/quotes

Dade Murphy: Hack the Planet! Hack the Planet!

P.S. If you have never seen the movie Hackers, you should. It’s classic.

Introduction:

This past Saturday and Sunday (March 5th, and 6th 2011), I spent my weekend on the Red Team for the At-large National Collegiate Cyber Defense Competition (CCDC). I served as a Red Team member last year, and you can read my write-up of last years (test bed) competition for this event here. This year (instead of 4 teams like last year) there were eight teams. A couple teams were from Alaska, two from Hawaii, and four from scattered states around the contiguous US. The only three universities that I identified (as participants) from chatting with the white team were University of Manoa (Hawaii), University of Alaska Fairbanks, and the United States Air Force Academy Colorado Springs. The goal of CCDC is to have the white team give the blue team business injects and have the red team attack the blue team while they have to work on setting up a corporate style environment.

Comments about the competition in general:

I was kind of disappointed this year. This year we were supposed to have VPN access to the network (as opposed to using VM Sphere over WAN to get to our machines). During the setup process, administrators had what is known as a disaster in the technical world, and to recover we had to use VM Sphere over WAN again this year. The problem with this setup is the delay on every keystroke was about a second long so it was very hard to use the machines. Needless to say the competition started about three hours late. Last year, the network was setup a day before so we could do our reconnaissance phase early. This year, we started recon at the same time the blue team got their machines. A major problem we experienced with the competition is that the one to one NAT the administrators setup between the outside (red team) and inside (blue team) used state tables to maintain records of open in closed ports. When we tried to use tools like hping, nmap, fping, etc to scan the network, the state table buffer would overflow and give us inconsistent results every single time. Even when we figured out how to translate the private IP addresses of the machines that were up (from our insider in the network which ping swept the local IP range) to public ones we could see, we couldn’t nmap them for open ports because the state table buffer would go haywire. Needless to say, you can’t run exploits against hosts with no operating system finger prints or service versions.

Comments about the machine setups:

Another thing that made the competition tough this year is the software the computers were running. Last year the Windows machines were running Windows XP service pack 2. This made it easy for us to find exploits to root the machines. This year the machines were running Windows XP service pack 3. The linux ubuntu machines were on 9.04. We got this information from the white team on day two. There really is just not a good amount of exploits out there that can be performed for these operating system versions, and the ones that are required significant modification. I mean, we can’t just write 0-day exploits, and if we did we certainly wouldn’t use them for these competitions. We’d be selling them to tipping point or somebody for $10k.

Attacks:

We tried running autopwn (a metasploit module) against machines we identified (through our insider) to be windows machines, but of course it failed because it couldn’t nmap the machines correctly. Thus instead of focusing on rooting the machines, we targeted the web applications we could find. There were five web applications we found: A record maintaining website, a social networking site, an IIS server blank page, some other content management system (CMS), and one other (I think) which I do not recall what it was. On the record maintaining site we noticed in the comments on the main page that there was a login username and password so we used that to get access to a page of usernames and personal information (social security numbers etc). We were able to do this for most teams and only one of them successfully changed the password to it towards the end of the competition. I ran nikto (a web vulnerability scanner) against all the websites we could find and I noticed on the social networking site there was a /upgrade.php file. When I browsed to that web page I broke the social networking site which made it a blank page.  This is pretty much all we were able to do for day one.

At the end of day one, the white team told us that they would help us do client-side attacks (like open things in email attachments) to simulate dumb users on a network. I went home that night and brushed up on my Social Engineering Toolkit skills (a software included in Backtrack 4). I was able to get internet explorer exploits working (like the google aurora attack) on my test VMs at home (running XP SP2), but when I tried them the next morning on the VMs for the competition (that were running XP SP3) I couldn’t get them to work. Instead I used social engineering toolkit to generate a PDF that had a malicious executable inside it. The white team chatted with me over skype on the blue teams target machines, I sent them the malicious file, they opened it and it spawned a reverse meterpreter shell back to our backtrack VMs. The next problem we had was the rootkit we intended to use for this competition (Dark Comet) did not want to communicate back to us. We chose Dark Comet (and tested it) because it is not detected by rootkit scanners like RootkitRevealer or Sophos Anti-Rootkit tool. Somehow last year teams were able to find our Poision Ivy rootkit, so we wanted to surprise them this year. In light of Dark Comet not working, we just went back to using Poision Ivy. The only teams we got connections back from were Team 1 and Team 3. Team 3 went offline so we were not able to install our home brewed malware (The Charlie Sheen Project) on their machines, but we were able to install it on Team 1′s machine. Here is a cool picture of that in action (us #WINNING):

As you can see, we had a little fun in the last hour of the competition spawning notepad on some of the teams machines and talking to them. The particular image you see above is us beating on the Air Force Academy (Team 1). I did manage to kill a spybot process on Team 5′s machine through a meterpreter shell that was still open from the PDF exploit and tried to spawn a notepad on their machine to let them know we were there. The white team said they saw Team 1 trying to drag windows spyware removal tool around the picture of charlie sheen to install it. It brought me much laughter and joy to see my home brewed malware working in action. Other than that, on day two Wesley McGrew wrote a script which downloaded the information on the record management website and deleted all the user records in it. He manged to execute it against a team, and he was thwarted by another team who noticed the network traffic. These were about all the attacks we were able to do on our end due to network/software version issues.

Remarks for the teams:

I can bet the teams were experiencing difficulties with the network just like us. I know a lot of the teams had their internal networks down for long periods of time. In our debrief Wesley said the only thing you can quote him on is that “You all did horrible”. I wanted to elaborate on that. Wesley was being a bit jocular when he said that, but also he was serious in a way. What we as the Red Team were concerned with is that only one team managed to fix the password on their record management site. People get in really big trouble when they leak information like social security numbers onto the web. They can get fined and the incidence response is costly. The fact that all the teams were notified about this on day one, and only one fixed it near the end of day two is terrible. If I was grading this competition I would have failed all teams solely on this and sent no one to nationals. It was a simple tweak to a .htaccess file to fix. It is too bad CCDC is about doing business injects and making pretty reports rather than an actual competition about information security. That is why our Mississippi State University team stopped blue teaming, and why we concentrate on offensive security. I would like to say something positive to the teams, but due to the network connectivity issues I can’t judge how secure machines actual were. You were giving fairly secure operating systems in the first place, which was really lame. The only metric we have to measure you by is your web application security, and by that you all failed. The winner had better put their game face on for nationals, because unlike this competition (where there were network issues and about 5 of us to attack 8 teams) at nationals there are about 40 Red Team members (5 to attack your team alone). And I guarantee you will be given more vulnerable machines.

Concluding Remarks:

I’d say this competition was a disaster. Do not get me wrong, I do appreciate the administrators and all the work they did to set things up. I want to thank all of you as having us as your Red Team. I still enjoyed myself and learned new skills. With that said though, I think next year the admins just need to #planbetter so that we all come out feeling like we are #WINNING . As always, if you have comments please leave them below or feel free to email me.

We are Red Team Sheen. We sometimes forgive. We occasionally forget. Expect us to be #WINNING.

Introduction:

What you see above, is the product of a pack of Newport cigarettes and a six pack of Southern Pecan beer (which I consumed while making this):  The Charlie Sheen Project.  I started writing this custom malware for the At-large Cyber Collegiate Cyber Defense Competition, of which I am a Red Team member. If you’re not familiar with CCDC, google it and check it out. In the picture, you see our logo for the Red Team (made by Wesley McGrew). We sometimes forgive, we occasionally forget, expect us to be #WINNING, @redteamsheen . The caption is a joke. It is a spoof on Anonymous’s slogan (“We do not forgive. We do not forget. Expect us”) blended with Charlie Sheen’s twitter (because Charlie Sheen is awesome): http://www.twitter.com/charliesheen. We even made our own twitter feed for this event at: http://www.twitter.com/redteamsheen.

Purpose:

As far as the purpose of this malware goes, this application was made for annoying the blue team. The dialog box with the picture of charlie sheen (shown above) sits in the middle of the desktop at all times, cannot be exited from by the task bar or by right clicking the window, and (if you notice from the picture) always stays on top of every window. In the picture above you can actually see how I have a folder open, and even though it is the window in focus charlie sheens picture still stays on top. This means (once we root any of the windows machines the blue team is working on) the blue team will have to drag their applications around the window in order to work on their business injects or waste time trying to get rid of our malware. Since there are no digital signatures for our malware for any spyware removal tools on the market, they have to take the time to reverse engineer the malware themselves. The application does not do anything malicious to the users computer. All it serves for is a perfect distraction for us to attack other machines while they’re busy trying to figure out why they have a window stuck in the middle of their desktop displaying charlie sheen.

Software Architecture:

This application is a lot more evil than it appears. There are actually three (windows) processes that execute when the charlie sheen project runs: charliesheen.exe, watchdog1.exe, and watchdog2.exe. Watchdog1.exe uses the Process Status API to get a list of all processes running on the machine. If watchdog1 does not see charliesheen.exe or watchdog2.exe running, it respawns them by using the Windows API function CreateProcessW. Likewise, watchdog2 is a clone of watchdog1, except it makes sure charliesheen.exe and watchdog1.exe continue to executing. Both watchdogs have a simple polling loop they run on that sleep for 30 milliseconds in between checks. The purpose of this is to make sure that users cannot kill the tasks individually. They have to figure out a way to kill both watch dogs at once in order to stop them from executing. Aside from checking to make sure the processes are still running, the watch dogs also make sure the executable files (placed in C:\watchdog1 and C:\watchdog2) stay in the directories. If they find any of their executables (watchdog1.exe, watchdog2.exe, charliesheen.exe) are missing, they will copy the executables from each others directories and replace them. This prevents users from deleting the application then killing the process to stop execution. The last feature of this malware is that all three programs are added to the windows registry on install so that they will start up upon reboot. Sorry windows users, restarting your computer won’t fix this problem. The downfall to this beautiful program is that the installers are Windows Setup and Deployment projects (because they were made in a rush). This means if the user has access to the add and remove programs wizard they can just uninstall the programs. Also, even though I tested silent installs of the .msi files generated by the setup and deployment projects (msiexec /qn /i <program.msi>) some versions of windows still require you to install from a GUI. This is undesirable for malware deployment because most times when you get a shell on a computer you cannot (and do not) want to use the desktop to install programs because the user can see you doing it on their screen. All in all, this simple annoying malware application is not a bad product of 12 hours of coding.

Challenges:

The biggest challenge of writing this piece of malware was writing it for a Win32 environment. We do not know which service packs or what versions of Microsoft Windows administrators will be installing for CCDC competitions, thus the dependencies for an application like this have to be kept to a minimum. It is not safe to assume they will have things like the .NET framework (or even the Microsoft Foundation Classes) installed on their computer, so writing this had to be done in old school C++ in a Win32 environment. Win32 has special data types and a lot of my time was wasted trying to figure out how to convert between unicode and ascii data structures of the Windows API. Otherwise I’d just be writing it in some more sophisticated language like C#, java, or python. The second challenge, which I addressed in the Software Architecture paragraph, is the deployment of said applications. I could not just copy and paste the executables onto the target machines I tested on and run them. This is why I deployed them as Windows Setup and Deployment projects (because windows takes care of packaging the dependencies needed with my project).

Future Plans:

For next year, I have plans to make this application truly diabolical. Here are a list of features I would have loved to implement if I had time:

1. Manipulate operating system data structures to hide all processes from the task manager
2. Provide integrity checks to all executables (like md5 and sha1) to make sure the correct applications get replaced (if they are deleted) and if not, download new executables from a server
3. Provide checks to make sure the registry key entries are not being removed that make the malware respawn upon reboot
4. Make an installer that does not depend on windows setup and deployment projects so that it can be installed from the command line and do not show up in the add and remove programs wizard
5. Randomize executable names periodically

Basically, I want to make it so that if blue team wants to get rid of my malware, they will have to revert their virtual machines or be Windows Sysinternals Gurus. Maybe that is not fair for such a short competition, but hey do you think the makers of Conficker or popular botnets are going to play fair with their malware in the real world?

Concluding Remarks:

I had a lot of fun making this application. It is not something I would like to do every day, but it is cool to get my name out there with it. I guess I would develop (legal) applications like this for money as well for future employers. If you would like a copy of the code, you can download it here (MD5SUM: 97097342dbb654d5e9697b491659f104). It was made in Microsoft Visual Studio 2008. Feel free to comment on my blog or email me with questions about it.

We are Red Team Sheen. We sometimes forgive. We occasionally forget. Expect us to be #WINNING.

Last Saturday, May 8th, I participated in Offensive Security’s How Strong is your FU? hacking tournament. Now I am going to post the results of how I went about hacking the n00b filter.

The first obstacle of actually hacking the n00b filter was actually getting into the game. Many people that signed up for this tournament did not get the emails with their password to enter the tournament until an hour or so later than the competition started. If you had no life and had time to social engineer, instead of waiting you could have joined the #offsec channel on freenode.net and they would have pointed you to the #hsiyf channel for the competitions. There the admins could have manually set you up to enter the tournament.  This is actually how I entered the tournament.

When I finally got the instructions on what servers to attack (there were only two and they were identical), I did what most people do: nmap it and see what operating system it is and what services it has running. The results looked like this:

1/tcp     open   tcpmux?
3/tcp     open   compressnet?
4/tcp     open   unknown
6/tcp     open   tcpwrapped
7/tcp     open   tcpwrapped
9/tcp     open   tcpwrapped
13/tcp    open   tcpwrapped
17/tcp    open   tcpwrapped
19/tcp    open   tcpwrapped
20/tcp    open   tcpwrapped
21/tcp    open   tcpwrapped
22/tcp    open   tcpwrapped
23/tcp    open   tcpwrapped
24/tcp    open   tcpwrapped
25/tcp    open   tcpwrapped
26/tcp    open   tcpwrapped
30/tcp    open   tcpwrapped
32/tcp    open   tcpwrapped
33/tcp    open   tcpwrapped
37/tcp    open   tcpwrapped
42/tcp    open   tcpwrapped
43/tcp    open   tcpwrapped
49/tcp    open   tcpwrapped

…

Etc. etc. of tcpwrapped ports. When I chopped up this output and grepped for open ports I got:

1/tcp     open   tcpmux?
3/tcp     open   compressnet?
4/tcp     open   unknown
80/tcp    open   http?
110/tcp   open   pop3
1723/tcp  open   pptp?
2701/tcp  open   sms-rcinfo?
2702/tcp  open   sms-xfer?
5666/tcp  open   nrpe?
6788/tcp  open   unknown
7921/tcp  open   unknown
7938/tcp  open   lgtomapper?
8021/tcp  open   ftp-proxy?
9100/tcp  open   jetdirect?
9101/tcp  open   jetdirect?
9102/tcp  open   jetdirect?
9103/tcp  open   jetdirect?

They obviously had some kind of tarpit running that was spoofing a whole bunch of fake services, because if I tried to connect to fingerprint any of these with netcat they would not respond and time out.

They also spoofed all the operating system signatures and it looked ugly:

Running (JUST GUESSING) : 3Com embedded (86%), Dell embedded (86%), Samsung embedded (86%), Xerox embedded (86%), Bay Networks embedded (85%)
Aggressive OS guesses: 3Com SuperStack 3 Switch 4300, Dell PowerEdge 2650 remote access controller, Samsung ML-2571N or 6555N printer, or Xerox Phaser 3125N printer (86%), Dell 1815dn printer (86%), Bay Networks BayStack 450 switch (software version 3.1.0.22) (85%), Bay Networks BayStack 450 switch (software version 4.2.0.16) (85%)
No exact OS matches for host (test conditions non-ideal).
Service Info: OS: Windows

The only port that appeared to be open was port 80. When I visited it I arrived at this puzzle:

When I clicked the submit button, I was given this message:

Pretty humorous. When I tried entering in a single quotation to the user field I received the message “HAHAHA!” on a blank white page. There was a few hours where I was wondering around in the dark trying various things like making shell scripts to automatidly fingerprint ports I found on the machine and see if any other ports would respond, using p0f to try to passively fingerprint the operating system to see if I could find a vulnerability, trying XSS injects, and manually fuzzing the variables of the web application to see if I could make it overflow. P0f actually said the OS was Tru64. Apache error messages said the OS was fedora (which I think it was most likely a fedora box). After hitting a bunch of dead ends, I decided to revisit the “HAHAHA!” message and check the source code. I noticed an advertisement in the source for applicure. Turns out applicure makes a product called dotDefender, which was running on the server we had to attack and preventing the SQL injection. I spent a while over-thinking how to hack dotDefender and even debated downloading it, setting it up in a virtual machine, and fuzzing it for buffer overflows. Then a google search revealed the missing piece to the puzzle: the dotDefender exploit.

With this exploit I tried to log into the /dotDefender/index.cgi script. It was on a password protected .htaccess directory so I tried looking through the manuals on applicure’s website and it said the password was the same as the username. The .htaccess script told me the username was admin, so I assumed the password was admin. For a long time there was a lot of confusion because there was talk in the #hsiyf channel that people kept changing the passwords on the .htaccess file somehow. I knew we weren’t supposed to run automated tools, but I had heard of people using hydra, so I just hurled a dictionary attack at the dotDefender password prompt. In social engineering with some of the other contestants who were fed up with the lag problems with the dotDefender application, someone told me the login was admin/password . When I tried to log into the application it would lag like hell. I waited literally 10 minutes for a response from the http server, and at the same time the admins were reverting to snapshots on their VMs constantly. One time I did actually make it through and I was very close to getting to the n00bSecret.txt file that was needed to move on to phase 2. Here is a screen shot of me using the dotDefender exploit:

I was so close to getting to phase 2. All I had to do was sucessfully execute a few commands like find / -name n00bSecret.txt . But every single time I actually got onto the application I received a message like this:

Someone later told me (that went through the pain of waiting for 10 minutes for each http response) that they successfully managed to find n00bSecret.txt in /opt/<some random directory string>/n00bSecret.txt . With that they printed it out to the webapp using “cat /opt/<some random directory string>/n00bSecret.txt” as I suggested to them. I decided not to continue the tournament anymore because of the lag.

I talked with the admin known as muts about the lag on the dotDefender application. He claims (in a private message) that there was an Intrusion Prevention System (IPS), and that I was tripping it (which was causing my lag issues). No other person I talked to that entered phase 2 found a way to not trip this IPS (if there even was one that people were tripping in this way).  They all seemed to use burpsuite to modify the post data for the dotDefender exploit I posted earlier in this blog entry. Afterall, it couldn’t possibly be that 100′s of people trying to log on to a remote management application (that wasn’t intended to be used by multiple users) and executing shell commands on the box could cause the lag I was experiencing right (*sarcasm*)?  We will see what Offensive Security has to say if they ever post the solutions to their vulnerabilites like they said they would:

Dialogue from #hsiyf (May 8th):

07:32 < Abo3abd> @muts, can you please share ths solutions after end the tournament?
07:32 <@ryujin> we will Abo3abd
07:33 < Abo3abd> Thanks a lot

Critique:

I’d like to thank the folks at Offensive Security for hosting this tournament. It was a lot of fun. They did a great job at designing a neat little game for us all to play. The two biggest suggestions that I have been hearing for next time though are (1) please let us start at the same time instead of relying on SMTP to email people their passwords and (2) don’t use vulnerable software that is too laggy for people to exploit.

Introduction:

This past Saturday (April 10th 2010) I participated on a Red Team (along with about 6 other students from Mississippi State University) for a mock Northwest Collegiate Cyber Defense Competition. Needless to say, it was one of the most fun things I have ever done in my entire life. The Blue teams were composed from students of the University of Fairbanks Alaska, University of Anchorage, the University of Hawaii at Mānoa, and another Hawaiian University (sorry I don’t know their name). If you’ve never heard of the Collegiate Cyber Defense competition, the background on it is there are three teams: (1) a Red team (2) a Blue team (3) a White team. The Blue team has to setup and defend a network that would be similar to a regular information technology network. The Blue team works for the White team and are forced into doing business tasks and server administration to get points for the competition. The Red team gets to attack the Blue team’s network while they are trying to perform business tasks, and attempts to bring the Blue teams services down so that they lose points. The Red team is not in a competition against the Blue team, rather the Blue team is divided into sub teams which compete amongst themselves. The Red teams job is to attack all the sub divided Blue teams networks equally, and report to the White team the damage they do to their network. To get a better idea of what I’m talking about, I highly recommend you watch the videos of last years Mid-Atlantic Collegiate Cyber Defense Competition shown below. If you’re watching them for entertainment the Red team starts at Part 3 and you will probably get some good lulz out of watching how walk all over the Blue team who is obviously ignorant to the types of attacks that they are even getting hit by.

1. Part 1 – http://www.youtube.com/watch?v=PDCPrfuf6BY
2. Part 2 – http://www.youtube.com/watch?v=kp6bktaB0A4
3. Part 3 – http://www.youtube.com/watch?v=38Nv3fg54bs
4. Part 4 – http://www.youtube.com/watch?v=7Hr0GykHR9c

Unfortunately for our Red Team, we were set up on virtual machines and had no physical access to the Blue teams network so any physical attacks like rogue USB devices were out of the picture. Because of this restriction, we had a 24 hour grace period to ping the Blue teams network, fingerprint their operating systems and services, and devise a plan of attack. In our reconnaissance, we did DNS zone transfers and figured out the entire structure of their network and what each machine did by looking at its DNS name. For example dns.<blah>.com was obviously a DNS server for the teams. We saw that these were running on windows machines, and that each team had two workstation machines (ws1.<blah>.com, ws2.<blah>.com). These windows machines happened to look like they were running a lot of services that they shouldn’t be, and we noticed the machines were running older versions of Windows XP pre service pack 3.

My Responsibilities:

One of my jobs was to figure out how to maintain access once we exploited the machines. I went root kit shopping and found a lot of junk root kits on http://www.rootkit.com. Many of the tools on this website are not rootkits, but they do have good tools for avoiding virus and rootkit scanners and such. Also the root kits that worked on rootkit.com were services that needed to be connected to from outside the computer they were being hosted on. I prefer root kits that dial out to the owners of the root kits because of the chance that the Blue team may do some interesting firewall rules like blocking all incoming traffic on all ports, but allow all traffic going out. Some of you might be saying, yeah but even if they dial back out to you how are you going to talk back to them if you can’t send traffic in? Well some protocols like SSH are bi-directional protocols, which allow you to evade that requirement so if you’re interested go look into it. Not having much luck at rootkits.com I decided to look at Backtrack and see if it had any good rootkits in it by default. They do have a rootkit called sbd is pretty useful in both Backtrack 3 and Backtrack 4. This rootkit dials out, but the only problem with it is if the server gets restarted the service will die. Thus I also made instructions for how to install this rootkit to the windows registry for the competition to re-run on boot. I also renamed this program to be VMwareGroup.exe, evily making it look like it was installed as part of the VMware tools that were running on the Blue teams machines. They had services like VMwareUser.exe that had to be run in order for their VMs to function properly. A second rootkit that we used extensively throughout the competition was  Poision Ivy (http://www.poisonivy-rat.com/). This is the same rootkit that was used in the Mid-Atlantic videos linked to above. It dials back to a number of IP addresses on different ports, installs itself to automagically run when windows starts, installs a VNC-like backdoor (allowing you to control the victims keyboard and mouse), allows you to spawn a windows shell at any time, and many more features! When testing these rootkits in virtual machines, I noticed poision ivy was detected by AVG antivirus. I do not know if this is the case for the professional version, but it is for the free version. Sbd.exe was not detected by AVG antivirus, so I figured these were about the two best root kits I could get for the competition. One that was really loud so that if the Blue team was smart enough they could detect it, and another quieter rootkit so that if the Blue team started to eliminate our poision ivy backdoors, we could still maintain access.

Results:

The goal of the competition for the Blue team was to host a website hosting company. They were given thirty minutes to secure their networks without us launching any attacks against them. In the six hour competition, we took their website hosting business down for all teams within the first 15 minutes of attacking them. They did not fix their business for the rest of the competition. This means their website downtime was 5 hours and 15 minutes.

Taking down their websites was easy. We used metasploit’s feature autopwn to automatidly own their windows DNS servers (which they did not have time to patch, or didn’t want to suffer the downtime to patch them in after their 30 minutes of safety time from the Red team was up). After getting on their DNS servers, we installed poision ivy and maintained access for almost the entire competition with it. We also owned some teams workstations and installed poision ivy on their workstations too. While some of us on Red team were doing this, some other of our members were hacking their linux machines and intercepting the emails the Blue team was supposed to receive from the White team to do business tasks. We replied to the White team as the Blue team telling them “You can take this job and shove it. We quit”. There was a point in the competition where I don’t think the White team believed that we had successfully penetrated the machines the Blue team was using, so they told us to start making some noise. We fired up the poision ivy shells and started changing their desktop backgrounds to lawlcat pictures, fighting for control of their keyboard and mouse, and talking to some of the teams over notepad. They asked us over notepad “how did you get in?”, well I hope they read my blog lol. On the linux machines, there was also a VNC service running with no password so we were also annoying them on their linux boxes in a similar fashion.

Only one team managed to actually figure out the reason their website was broken was because we changed their DNS. We identified this team later on to be UH Mānoa Hawaii. They did do a decent job at keeping us out of their boxes. They were the only sub team of the Blue team to erase our root kits (toward the end of the competition). They were surprised after erasing our root kits off their workstations that we still had poision ivy dialing out to us on their DNS server. If we wanted to, we could have installed sbd so they would not have found us, but seeing as there was only an hour left in the competition we figured we tortured them enough and let them close us out of their network. They get a very small kudos for this, but I retract that in a few paragraphs and you will see why.

Now, I’m not sure if it was the White team’s true intention to score this competition or not. We were told at the begninning of the competition that the competition would be scored and that this was being conducted just like a Collegiate Cyber Defense Competition. The White team decided at the end they were not going to score the competition. With the Blue teams website business task being down for 5 hours and 15 minutes and all of them getting bombarded by the Red team through multiple security vulnerabilities the Blue teams did not patch, it is fair to say they would have low scores if this were a real competition. All the Blue teams have a lot of practice to do if they want to be in a real Northwest Collegiate Cyber Defense Competition. Nevertheless the 6 of us that were on the Red Team from Mississippi State University respect them for trying to better themselves at defending against hackers (by doing this competition) and we welcomed them to challenge us whenever they would like to do another event like this.

False Victory:

This blog post showed up a few days later from UH Mānoa:

I’m just going to leave it up to you (the reader) to decide what you think about that one. This is why I say I retract my kudos to UH Mānoa. Wesley Mcgrew (http://www.mcgrewsecurity.com), who headed up our Red Team found this post by them and told us about it so I saved it for my records.  Since Wesley notified the point of contact for UH Mānoa’s blog post, they have changed their tune: http://www.hawaii.edu/news/article.php?aId=3560 .

Incident Reports:

The White team was supposed to mail Wesley some incident reports. Incident Reports are what the Blue team had to file everytime the Red Team successfully penetrated their machine. They do this to get points back. I have not heard from him to see if he got them. If I ever do I will post them here.