Palmetto Cyber Defense Competition - 2014

Last weekend (April 12-13) was the second annual Palmetto Cyber Defense Competition (PCDC). Inspired by the national Collegiate Cyber Defense Competition (http://www.nationalccdc.org/), PCDC is a computer security and business competition open to schools in South Carolina. On Saturday, college teams compete while Sunday is reserved for high schools. Unlike CCDC competitions which usually span a couple of days, PCDC competitors are pressured into one fast and furious day of competition. I was fortunate enough to be a part of the Red team this year. I wanted to make this blog post to supplement the short Red team presentation given to the students at the end of their competition day. Since PCDC competition sessions are only a day long, there is so much to do in that timeframe. As a result, the Red team doesn't really get to talk with the students as much as we would like.

For this year's PCDC, we had a relatively small Red team. At any given time, we were between 7-8 members. As a result, we decided it would be most effective if we each took a team to focus on. If anyone of us would find a way into a system, we'd shout it out and each Red team member would try that method on their target Blue team. We wanted to keep things as even as possible. In addition to all of our technical tools, the Red team was allowed to use social engineering this year. The Red team had access to a VOIP phone which we could use to call the Blue teams. In addition, the Blue teams' competition area was in a large reception style room. This meant that the Red team could walk around the Blue teams to try and pick up what was going on.

From a social engineering perspective, the Red team kept things pretty simple. We stole a couple of Blue team 'mentor' name badges that would have been used to help identify individuals who could provide the Blue teams with some extra technical support. One of the defining differences with PCDC is its goal in encouraging STEM outreach. As a result, Blue team mentors work with the competing high school teams months in advance to help prepare them for the competition. As a result, the Blue teams grow to trust the mentors. Although I personally offered my Linux subject matter expertise to the Blue teams, I was not asked to help. I felt completely under-utilized. This is a positive note to point out. All the Blue teams for both college and high school were extremely cautious with allowing personal access to their space. As a result, very few of the Red team members got information via personal interaction. But we had other plans.

One of the Red team members brought a high quality camera with him. Equipped with nothing more than a collared shirt and good personality, he set out to film the Blue teams as a member of the 'local news station'. He was successful in taking a picture of every single Blue team's password lists for both college and high school days. Only one team reported his actions. As you can see by the following picture, the results were awesome:

Blue Team Passwords

In addition to pictures, we also tried to add our own business inject. Prior to the competition, one of our Red team members made a fake tax calculator program and accompanying inject form. The inject stated that the students were to report the error code given by the tax software as the upgrade from Windows XP to Windows 7 has caused some unanticipated errors. What really happened is the program would crash every single time but open up a reverse shell to our waiting machines. We had some success with this approach including one team that send us over 30 shells back! Other notable events include a team that redialed their phone immediately following a Blue team runner who called the Red team asking to clarify if the weird behavior on the team's system was the Red team or an actual technical issues. The Blue team runner was not a competitor, but one of the helpers there for the Blue teams. Because we are a friendly Red team and we want to help everyone out, we would always pick up our phone pretending to be the Gold team. As a result, this particular Blue team thought we were the Gold team for most of the day.

The Red team's game plan for attacking the Blue teams was simple. Get access, establish persistence, then have fun. This is true with pretty much every Red team for all the CCDC style events. I will say that for both college and high school days, every team was pretty good at keeping us out by changing their default passwords. The only way we got their default passwords was with our photographer. What the Blue teams weren't told was that the default passwords given to them were not all their default passwords. One of the services the Blue teams had to keep up was a Kunagi server. Kunagi is deployed on a Java application server like Tomcat or JBoss. For this event, the Blue teams were running JBoss. What every single one of them failed to notice, however, was that their JBoss admin console was publicly available and still had default admin credentials. This is how we got our initial access for every team.

Through the admin console we were able to upload our own WAR file (the deployable version of the Java applications that run on JBoss) which would start a reverse meterpreter session back to our machines. With this we would establish simple persistence by using meterpreter's run persistence module. From here, I no longer needed my custom deployed WAR, so I deleted is. This would hopefully hide the fact that I had compromised their system. With this initial access, the next step is to try and move laterally through the network. It turns out, these system were all part of a domain. So, our next step was to pull credentials from the machine. We did this with mimikatz. For those of you that don't know what mimikatz is, it is a tool that allows for plaintext recovery of cached Windows credentials. The following is a screenshot of what mimikatz output looks like:

Plaintext credentials with mimikatz

Now, lucky for the Red team (and consequently, unlucky for the Blue teams), these credentials belong to the domain administrator. From here, we were able to use the psexec command to log into the other Windows boxes and consequently establish persistence on all the Windows machines.

In addition to Windows, the Blue teams also had a couple of Linux servers and an ESXi server. As a team, we really didn't have too much luck on getting on the Linux servers except with a default SSH credential and through the ESXi console. But let's talk about how we got to the ESXi servers. For those of you who have used ESXi and connected through a browser, you know that it uses HTTPS. It turns out, ESXi is using OpenSSL. Hmmm. PCDC 2014 was on the weekend of April 12th and 13th. Not even a week before, the security community was thrown on its head with the HeartBleed vulnerability present in most modern versions of OpenSSL. On a hunch, we decided to try HeartBleed on the ESXi servers. We set up a simple script that would constantly ping the Blue team's ESXi servers and look for a HeartBleed response that contained a password field. About an hour later, one of our Red team members jumps up yelling, "it worked!" And there on his terminal, was a username and password field. It turns out that HeartBleed will work on an ESXi server and spit out usernames and passwords after a login attempt. Here is a screenshot of was our output looked like:

HeartBleed works on standard ESXi 5.5

One of the goals of PCDC is to give students a taste of the real world. How much better could be get than launching an attack against a critical service that exploits a vulnerability less than a week old? Needless to say this certainly caught some buzz with the spectators. Unfortunately, we did not discover the effectiveness of HeartBleed until the second day. As a result, the college students missed out on this. With these credentials we could point vSphere ESXi clients at the ESXi servers and help the Blue team's administer their VMs. My favorite is when I open up the console to a Linux machine and just see a # sitting there. For my Blue team, I was a little quicker on the keyboard than they were. I opened the console and saw the root prompt. I quickly changed the root password, turned on SSH, and then quit the user session through the vSphere client. This effectively locks the Blue team out of their root account and allows me to login remotely via SSH. My favorite result of this was having the Gold team call up the Red team with the response, "One of the Blue teams just said they saw their root password change right before their eyes and then lock them out. Was that you?"

At this point, it was time to start having fun with the students. A couple of the Red team member came very prepared for fun. In the year leading up to PCDC 2014, we have been hearing a lot about ransom-ware in the news. Software that gets on your computer, encrypts important files, and then demands a ransom for the decryption key. Inspired by this, one Red team member made some hilarity-ware. This combined the ransom-ware with some amusing side effects. Let me introduce Ponyware:

Ponies demand a ransom

Ponyware would encrypt a lot of the folders found on the computer and then insert a small ransom program in the front of every legitimate program it could find. The goal was to get the Blue teams to call the Red team for the decryption key after they paid a ransom with some of their points they had earned throughout the day. We successfully deployed Ponyware, but no Blue team called us for the decryption key. Instead, most of them either opted to leave it on and have it play its music, leave the desktop background a checkered board of ponies, and enjoy the custom mouse cursor. Others opted to take a large point deduction and request a Gold team re-image. Ironically, the re-image cost more points then the ransom would have.

Our next trick was pretty nasty. Originally, we were planning to deploy this uniformly at 3:30pm, but our plans didn't really work out. The plan was to overwrite all the master boot records (MBRs) on as many Blue team machines as possible. What we wrote the the MBRs was an awesome 512 byte program that displayed an animation on Nyan cat.

Nyan cat animation written to boot sector

Once the MBR was overwritten, we would bounce the boxes and this would be the only thing the Blue teams would see. Nyan cat was a huge hit with just about everyone. Although the Blue teams would have preferred not having their MBRs overwritten, they appreciated the humor. By the end of the day, a couple of computers were just sitting there completely useless counting down till 3:30pm:

Waiting until 3:30pm

From a Red team member's perspective, there are a couple of things I would have suggested to the Blue teams. In general, most teams did a very good job, but no matter how many times we say it, default passwords are going to kill you. As a Blue team member, you need to be aware of every service you have running and if/what those service's default passwords are. You must be aware of service that come out-of-the-box with default credentials. Now, I have only been a Red teamer on 2 CCDC style events, but both times I've bean able to access the ESXi servers with my vSphere client. In the case of PCDC, every Blue team was provided an adaptive security appliance (ASA). This can be used to restrict the IP addresses allowed to access the ESXi servers. Blue team's should also be aware of authentication mechanisms that are required and not required. The Blue team I focused on for day 2 only allowed SSH login via key authentication. This is a great move, except when the Gold team needs to be able to login via SSH to score your service and they don't have an authorized key because Gold team is using a password. Over and over again the Gold team remarked about how the Blue teams did not read their information packets thoroughly. The information packets usually have detailed information about your network and systems. As a result, you should know what is on your network. It shouldn't be towards the end of the day when I see this as I'm watching your session..

What is an ESXi?

At almost 1:30pm, the competition has been going on for about 5 hours. Just now trying to learn what an ESXi server is might mean you're a little behind the game. Another lesson learned (the hard way) by some Blue teams is if you know something bad is going to happen at a specific time (say 3:30pm), do not try and adjust your system clock past that time. Trying this trick quite literally blew up in some teams' faces.

I just want to note that some individuals on the Blue teams felt that we were a little hard on them. It was our intention as the Red team to not be complete jerks. Our goal is to educate the students while having fun with them. As we tried to tell the Blue teams, we do this because we care about education. So, if you're a current or future member of a Blue team, know that we don't do what we do to be mean. We do it to help you. If you're competing and the frustration is building, just remember, Red team loves you!

Red Team <3's you!