This weekend I was invited to be a member of a red team for a local CCDC team. I’ve been interested in checking out how CCDC works, and this was my first opportunity to be part of it.

For the 20 minutes before the red team was allowed to go, we began mapping out different strategies and attack paths that each member would carry out. Off the break, I was in charge of exploiting systems, and attempting to get shells. We had two other members who were in charge of mapping services active on hosts, one member in charge of scanning hosts for vulnerabilities, and one for post-exploitation work and establishing persistance once the team received a shell. We decided to centralize our work and I setup a team server for use with Armitage. In the end, this was a great decision. We were very easily able to share sessions opened up with targets, and allow everyone to access all information as we obtained it from hosts (such as hashes that were dumped, keystrokes logged, etc.). Any CCDC or team CTF event should absolutely use this awesome capability.

Immediately after we started, 08_067 was sent to the entire blue team IP range, and followed quickly by 09_050. Within 5 seconds we were in one of their boxes as system and we immediately began post-exploitation by dumping hashes, creating accounts, and creating services that call back to us. While on the box, we were watching the blue team attempt to install patches to prevent us from re-exploiting and regaining access. However, a red team member killed the update process, which caused the machine to endlessly reboot.

The blue team decided to revert the entire machine, take the machine offline, and then patch the entire machine. After talking with others on the rules, we found out that this is definitely an illegal action (taking the machine off the network) and would cost the blue team points. However, it appeared to be an incomplete patch performed against the machine because once the machine went back online, we were able to re-exploit it with 08_067. Getting onto the machine when we did let us gain control of their domain controller.

Immediately when we jumped back on the machine, we took a screenshot and saw that the blue team was in the process of trying to join the computer to their domain. We immediately activated a key logger, and obtained 3+ different passwords that must have been used throughout their network (it appears the blue team forgot which password was the password for their domain admin account, so they were trying them all). After about 20 minutes of keylog dumping, we obtained the domain admin account credentials and were able to psexec onto the domain controller. We immediately dumped hashes and obtained credentials.

Both machines we were on were a constant battle as the blue team loaded on a significant number of tools to monitor processes and outgoing connections from their machines. This led to constant battles as processes were constantly being killed due to the very active defense of the blue team.

Overall, these were the only two machines we were able to control (out of 10 total). Probably the biggest reason for this was because at least half of the IP range were computers that weren’t actually brought online. Another reason, the blue team had (accidentally) uninstalled required services on the few machines that were online. This significantly reduced the attack surface on nearly all their active machines.

Some of the overall notes that we provided to the blue team in our wrap up was:

• The blue team needed to work immediately on patching their machines, but to prioritize the patches by starting with any patch eliminating remote code execution. Additionally, they need to ensure the patches were applied to the machine and are active. The blue team had thought that they patched certain exploits, only to have the red team break back in with the same exploit they thought was patched.
• The blue team needs to assume once the red team breaks in, that everything related to that machine is compromised, such as account credentials. We suggested that the blue team should rotate passwords regularly (if possible), but definitely after a compromise of the machine.
• Ensure that all default credentials for services or web applications are changed.

What the blue team did well:

• Active defense. The blue team very actively monitored processes running and monitoring connections from their boxes. This led to multiple battles where the blue team was killing our connection while we began re-establishing them. This was definitely their strong point. They seemed to know exactly what was running on their boxes and were good at determining what we were running.

What the red team can do:

• In my opinion, the best thing we could do for the next practice session is automate a large portion of our post-exploitation activities. By all means we performed post-exploitation effectively, but I think it would be great to create a couple cortana scripts that are triggered upon certain events. For example, on a meterpreter session, we immediately dump hashes, create user accounts, create persistent services, and attempt to pass obtained hashes to other windows machines within the target range. Automating these tasks will free up the red team to perform other activities and automate the manual work.