tests and has done their due diligence in mitigating any of the vulnerabilities presented to them would I consider recommending a red team engagement. The most important thing to consider when deciding whether an organization is ready for a red team engagement is, can a red team get in using a vulnerability that shows up in a pentest? If so, the organization is not ready for a red team. The organization should already have an internal social engineering program to ensure its users don’t submit credentials to a malicious page the red team hosts. Solid alerting and hardening of infrastructure should be in place, and I damn well better not find an exposed portal that doesn’t have MFA.
How do you explain the value of red teaming to a reluctant or nontechnical client or organization?
Explaining the fact that it is a true test of their defensive capabilities usually is effective for me. I like to describe a pentest to a customer by explaining that I am going to attempt to find as many vulnerabilities as I can but will likely be very noisy. I explain that on red team engagements I may find only a few vulnerabilities but will be much less noisy and those vulnerabilities will likely be much more valuable to them, as they probably allowed me to compromise the network.
What is the least bang-for-your-buck security control that you see implemented?
For the most part, if you are paying for antivirus, it is the least bang-for-your-buck control. I say that because, honestly, the free Windows Defender that comes installed by default on Windows systems is actually pretty good for doing what antivirus is supposed to do.
Have you ever recommended not doing a red team engagement?
Yes, during scoping calls, if I sense that the customer hasn’t done previous pentests or struggles to conceptualize what a red team is, then I might recommend something else. Definitions are huge in this industry. Without the proper definitions being agreed upon, it can be difficult to determine if by red team they actually mean pentest or even vulnerability scan. Laying out these definitions usually results in a customer realizing they meant a pentest instead of a red team.
What’s the most important or easiest-to-implement control that can prevent you from compromising a system or network?
One of the easiest-to-implement controls that makes our lives hard as red teamers is Microsoft’s Local Administrator Password Solution (LAPS). Randomizing local administrator passwords on every system makes it so that the compromise of a single local admin credential doesn’t allow widespread access to every other asset in the network. Network segmentation between hosts, including client isolation so workstations can’t talk to other workstations is another great control to have in place. If I can’t pivot from one workstation to another, it’s going to be hard for me to escalate privileges in the domain.
Even though this question asked for only one control, I would say the following are the most important things to look at locking down to prevent full domain compromise: MFA everywhere you can implement it, VPN requiring MFA and client-side certs, strong password policy (15 characters or more), strong log consolidation and alerting, application whitelisting/behavioral analytics software, strong egress filtering (allow web ports out only through an authenticated proxy with filtering in place), and user awareness to social engineering. If the organization implements those things, I’m going to have a bad day as a red teamer.
Why do you feel it is critical to stay within the rules of engagement?
Staying within the rules of engagement or not is like the difference between landing a shell on your target and landing a shell on the personal device of your target’s significant other. One of these things is a highly illegal thing to do, and you might not be able to unsee what you see there.
If you were ever busted on a penetration test or other engagement, how did you handle it?
Busted? What’s that?
What is the biggest ethical quandary you experienced while on an assigned objective?
One time I was tasked with performing a penetration test for a company and made my way to the CIO’s system, where I found some very questionable things. I had a Meterpreter shell on the guy’s system and noticed some KeePass processes running. I thought, “Cool, I’ll wait for him to leave, log in, and then see if he left KeePass unlocked.” Late at night after he left work for the day, I connected to his system using RDP. Sure enough, he had left KeePass open, so I now had access to a ton of creds, including some personal ones of his.
But I also noticed some other windows open on his system. First, he was using RDP to connect to another company’s server outside of the target network, where he appeared to be doing some sort of “system administration.” To make things stranger, he was also using RDP to connect to a personal system. This personal system had well-known tools on the desktop for performing mass spamming and other tools. At this point in the engagement, it became an ethical quandary, so I stopped the engagement. I ended up hearing from the customer later on that the CIO was let go.
How does the red team work together to get the job done?
Collaborative infrastructure across the entire operation is necessary in my opinion. To be successful during the operation, we need to be able to share shells, data, and so on, easily. On the reporting side, it’s the same thing. We don’t want to be working in separate documents. This creates too much work later when we want to merge them. If we can collaborate on the same document platform, it creates a much smoother reporting process.
What is your approach to debriefing and supporting blue teams after an operation is completed?
After an engagement, I like it when the organization can get all the entities involved in a meeting with me. I want the security team there as well as members of the SOC and maybe even other sysadmin-type employees. This way, those who typically don’t see pentest reports now have an awareness of what can happen on the network. In turn, this helps arm them with the knowledge that they need to be diligent in protecting their own systems. I typically walk through the entire operation, from reconnaissance to initial compromise to escalation and finally data compromise.
If you were to switch to the blue team, what would be your first step to better defend against attacks?
Not switching back to the blue team. But if I did, I would first have a long discussion about budget. Knowing the budget can help you know how to best divvy it up to get the most out of it. You don’t want to go blow your whole budget on the latest blinky light system that likely requires another full-time employee to even manage. There are so many free and open source options out there for securing a network, but many of those require time and effort as well. So perhaps using your budget to hire another co-worker might be the best bet. Some things I would try as soon as possible if they weren’t already there would be to deploy Microsoft’s LAPS, up the password policy, and deploy MFA.
What is some practical advice on writing a good report?
Take lots of notes while you are testing and essentially write the report as you move along. The worst thing you can do is fill up a notes document with screenshots but forget why you actually took them. Trust me, I know it is really hard to stop what you are doing and go write a couple sentences. Especially when you are faced with a new shell, it can be tempting to just start hacking away at it. But if you don’t document, you will be regretting it later.
How do you ensure your program results are valuable to people who need a full narrative and context?
