Content

ICE2 Games: Lessons Learned From Capture The Flag

As I mentioned earlier, Larry and I each led teams in the ICE2 games last week hosted by White Wolf in collaboration with SANS. This was a three night hacking game/challenge/simulation. As you can tell, I’m having a tough time putting an appropriate label on it, as it was a unique, fun, and educational exercise. There were three networks to attack, two of those networks were defended by Larry and various SANS students. The third network was defended by Fortinet, who did great, and put up with some of my typical vendor harassment and taunting. In all honesty, when you have two networks with no IPS, and one with, the attackers are going to go after the ones without IPS. However, don’t become complacent with your IPS, if an attacker has your passwords, spent time with evasion techniques, or can look like legitimate traffic, its game over. I had a blast at this event, and learned a lot about penetration testing strategy and techniques.

Night 1 – Organizing Hackers Is Like Herding Cats

On the first night I was pumped. For the first hour of the exercise, we’re given access to the networks completely exposed, HerdingCats.jpg no firewall and the defenders are only allowed to use operating system tools. This was so exciting! I had about 15 hackers the first night, including Justin and Alex from Immunitysec and Anthony from Core Security. I started organizing all 15 people, getting them networked, assigning tasks, having them Nmap, vulnerability scan, exploit, etc… That plan quickly fell apart and I realized I needed to add a layer of “middle management” and assign a leader to each table, then work through that leader. Things went smoother, however most people wanted to just come in and use remote exploits to pop boxes and do their victory dance. While this is fun, its only the tip of the iceberg. Once you compromised a machine, you had to have it update the scoring engine by running a python script. Many missed this step the first night, party due to logistics, and partly due to shells dropping before you had the chance to upload and run the script. I learned a lot on the first night about how not to organize a large team of attacks, the importance of keeping access, and proper testing of tools and automation.

Night 2 – Wireless FTW

The second night we were a bit more organized, I ran the recon efforts and put up the vulnerable hosts and open ports on the projector for the entire team to see. The defenders had access to the logs, so I ran an Nmap command to run interference and keep the Fortinet guys busy:

nmap -n --badsum -PN -T5 -f -D `cat 1128ips.csv` -sSU --packet-trace [ip or subnet]

The above command tells Nmap to send fragmented traffic (-f), with bad checksums (–badsum), really fast (-T5), and spoof 128 decoy IP addresses (-D), do this for both UDP and TCP (-sSU), and show me the packet trace while the scan is running (–packet-trace) . This worked fairly well as a >mole_3a.jpgdistraction, however I believe Ftester would have been a much better option. The firewalls went in place in the second round and the defenders really locked things down, and managed to change the passwords to several systems. Unfortunately for them, they left the default password to the web cam, which also had a mic for us to listen to all their conversations. Turns out the joke was on us, as the defenders sent over a mole on our team, which turned only slowed us down a bit (all is fair in love and hacking). We spent some time analyzing the web apps and found several vulnerabilities, such as XSS and SQL injection. We were then given access to a wireless client on the defender network, and thought great we can use XSS and make some progress (Grab cookies, gain credentials, etc…). However, we were given physical access to the client, so we deployed an Immunitysec payload to the target system, and had it call back to us. We then used that machine to pivot and compromise machines on the defender network. While that was fun (we did the victory dance), I was still disappointed and wanted to cause mass destruction and pwnage…

Night 3 – Hiding In Plain Site

I spent some time scripting some interesting things for night 3. The first thing I had to do was select the best tool to compromise poster_ninjas.jpg the most machines, and do it the fast. I also wanted to score big (TWSS) on night 3 (most of my other nights were spent helping students, which was also great fun). The first thing I did was take the scoring engine script and convert it to a Core IMPACT module. I selected this tool because I didn’t want to spend time converting it to Ruby, and I did not have CANVAS. Also, Core IMPACT has a “mini-shell” which allows me to interact with the command shell on the host and not end up in the process list on the compromise system (metsrv.dll shows up in a process listing). The “mini-shell” is a python program which interprets commands from the user and runs them directly via syscalls on the target system. Those paying close attention are probably saying that my sessions still show up in a “netstat” command output. Yes, its hard to hide on a system without a “rootkit” (Immunity has one, which worked well and is something I need to evaluate more). In any case, I wanted to make it hard for the defenders to find me. I had a way to compromise systems and score easily, however I needed to keep my access and continue scoring once the firewalls got in place. I wrote some scripts to kill common processes and applications that would lead to my detection:

:loop
process -k "cmd.exe"
process -k "taskmgr.exe"
taskkill /F /IN taskmgr
taskkill /F /IN cmd
goto loop

A couple of things about this script. When I wrote it, I said to myself, “Wow, I would never run this on a customer’s system”. However, and evil bad guy would most certainly run this on a target system. So, the defense gets some real world experience, which I think is really neat. Just to clarify, I don’t actually kill my own shell because I never run “cmd.exe” on a target system, the “mini-shell” lets me list files, upload files, download files, and execute programs. Once I have access to a system I use this shell to start executing commands. I change the administrator password, expose services like RDP, and various other nasty things to lock them out of the system. Then, things started falling apart. “cmd.exe” no longer existed, neither did sc.exe, the net command, or netsh. What happened? I took a quick walk around the divider to see fellow SANS instructor John Strand helping the defense (I am shaking my fist yelling, “Bastard!” as I type this). It was all in good fun and it turns out we were using similar techniques to both attack and defend. Wait, did I just say that? Yes, the defenders were killing processing, using scripts to look for new connections. So, they locked us out and hardened their systems and implemented a firewall. Game over? No way, this is an excerise that sets out to mimic the real world. Wireless enters the equation again, and we gain access to our wireless router which is plugged into the defender’s internal network. Its using a hidden SSID and running WPA2-PSK. We associate to the network and manage to find one box to compromise with Metasploit and deploy a meterpreter payload. I’m able to use this payload to score in one of the later rounds, and grab password hashes, then use john to crack the administrator password. A fitting end to the evening for the attackers was to hand them their administrator password on piece of paper, to which they asked, “Which system is this for?”, and I responded, “I dunno, you guys should be able to figure it out”. An even more fitting end was when Tim from White Wolf Security, responsible for managing game play, called the defenders on their VoIP phones and told them about the access point. The red team gathered around to watch and cheer when they found it. Game over….

Lessons Learned

  • Organizing people is hard, smaller teams and appointing team leaders is helpful
  • Assign tasks explicitly in your penetration testing team (one person responsible for password cracking, one for recon, exploitation, etc…)
  • Remote exploits are just one small part of the test, password attacks, web application, default passwords are all vital to your success
  • Set yourself up to do password cracking for a variety of platforms. Have john configured and ready to go on a fast system, as well as ophcrack
  • Keeping access is so key to your success, test and use your payloads in our lab in different environments, figure out which ones work best in each case, and document them
  • Hiding on systems is difficult without a rootkit, just be certain to define your rules of engagement so you know whats in play, and whats hands off
  • Deploy, or develop, your own tools to deploy to compromised systems (if in rules of engagement)
  • Defender tip: Renaming or removing tools (such as netsh.exe, net.exe, cmd.exe, and sc.exe for starters) will slow down the attackers and force them to either find the tools on the filesystem, or upload their own utilities

Thanks to Tim, Dwight, Joe, Justin, Alex, Anthony and all those who played in the games. Looking forward to next time!

Paul Asadoorian

Paul Asadoorian is currently the Principal Security Evangelist for Eclypsium, focused on firmware and supply chain security awareness. Paul’s passion for firmware security extends back many years to the WRT54G hacking days and reverse engineering firmware on IoT devices for fun. Paul and his long-time podcast co-host Larry Pesce co-authored the book “WRTG54G Ultimate Hacking” in 2007, which fueled the firmware hacking fire even more. Paul has worked in technology and information security for over 20 years, holding various security and engineering roles in a lottery company, university, ISP, independent penetration tester, and security product companies such as Tenable. In 2005 Paul founded Security Weekly, a weekly podcast dedicated to hacking and information security. In 2020 Security Weekly was acquired by the Cyberrisk Alliance. Paul is still the host of one of the longest-running security podcasts, Paul’s Security Weekly, he enjoys coding in Python & telling everyone he uses Linux.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.