Dantevios.com

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.