"Your social engineering attempt worked, and your malware has executed on the target and beaconed back successfully. You now have a remote shell on the victim system. After some initial recon, you note that you have local administrator privileges on the box and that the system is joined to the corporate domain, though your user does not have elevated domain privileges. Your foothold is on an HR laptop in a 60,000 person corporation. Your target is the CEO's email, and you cannot be detected or you fail.
What do you do next?"
We often use scenario-based questions when interviewing candidates for a role on Mandiant’s Red Team, particularly if the candidate has been through previous interviews and appears to have the technical intellect and aptitude it takes to be successful here. I enjoy scenario-based questions for many reasons, including the following:
- Scenarios give candidates with prior experience a chance to demonstrate their understanding of the field and share effective techniques and war stories from prior engagements in as much detail as they prefer.
- For those candidates without red team experience, the scenario gives me a chance to observe how the candidate adapts to a problem they have never faced before. Do they ask meaningful questions? Do they get overwhelmed or frustrated? How well do they focus?
- Because there is no single “right answer” to a scenario-based question, candidates with diverse backgrounds can leverage their knowledge and experience as they see fit. Sysadmins and network engineers might talk to enterprise architecture and common weaknesses in large corporations. Incident responders might explain of analysis of memory and file system artifacts to locate credentials and other valuable data on the system. Former capture the flag (CTF) participants might draw from past experience in those competitions. The same applies to developers, reverse engineers, DBAs, etc.
- It gives me a sense of the candidate's understanding of the gravity of operating within a "hostile" environment. Are they reckless? Do they appreciate the value of that initial foothold in the environment? Do they truly understand what it means to be stealthy vs. having never been caught before? Do they plan for contingencies? Do they think like a real attacker who can’t afford to get caught?
A red team for SOC operation is a great way to assess your effectiveness to prevent, detect, respond and contain malicious activity and it’s the closest way to emulate a rogue attacker trying to compromise your network. This video explains why.
Which companies should use a Red Team approach? This video explains more about who will best benefit from Red Teaming.
This scenario that I’m presenting to our hypothetical candidate is realistic. At Mandiant, one of our specialties is Red Team Assessments that closely emulate advanced attackers. In fact, we leverage the intel garnered from the incidents we respond to in order to ensure we’re emulating the most advanced attackers we see. We even built network communication protocols in our remote access tools (RATs) that perfectly emulate various attack groups (such as APT19 or FIN5) to see how well our clients can detect actual protocols used by attackers.
Often, the client security team has no knowledge of the Red Team Assessment being performed. From their perspective, if they detect us at all, it looks like a legitimate threat actor targeting their enterprise with intent to do real damage. These engagements are usually performed at the behest of an executive who wants to see how their security program stacks up against a motivated human aggressor with meaningful attack objectives. Can they detect us? Can they stop us from stealing, damaging, or destroying the “crown jewels?” Can their CIRT respond effectively to contain the attack or provide an accurate post-mortem? How does the organization handle the chaos of an ongoing breach?
As you can imagine, planning and executing these Red Team Assessments requires a “particular set of skills” (read that in your best Liam Neeson voice). However, they aren’t necessarily the skills you might expect.
The next series of blog posts are titled “Attacking like a Professional.” The premise is that there are core competencies for red team operators that are just as important as the ability to write code, exploit vulnerabilities, pop systems, release tools, publish papers, speak at conferences, and get invited to after parties. As a community, I believe that we have the technical side of cybersecurity well in hand. Instead, these blog posts will focus on concepts that have very little to do with technology, but are just as important when operating against a target.
The terms “operate” and “operator” both have a strong association to military activities, particularly with regard to Special Forces. As such, I’m reluctant to use these terms flippantly. It seems silly and even disrespectful to compare a couple of hacker dudes sitting behind laptops at a Starbucks to the exceptional men and women who execute the most secretive and dangerous missions in the nasty parts of the world. I’m certainly not trying to borrow that persona or compare what we do to what they do. This is not an attempt to be “tactical.”
What drives me to use these terms is similarities that I have observed among offensive security professionals and elite warriors, especially those whose job it is to attack things. Although I didn’t serve in the military, I’ve had the privilege of interacting with a wide variety of military, Intelligence Community, and Special Forces personnel, both professionally and personally. I’ve also worked with some of the most respected and capable cybersecurity professionals in the Defense, Intelligence, and Commercial InfoSec community. While there are noticeable differences (e.g., there just aren’t many hackers who can do 20 dead hang pullups), there are strong similarities in mindset, approach, training, and even personality that I believe we need to discuss. These similarities span topics that aren’t often associated with excellence in cybersecurity and typically ignored by the technical community, particularly the “ethical hacking” scene.
This leads me back to the interview scenario: outside of technical acumen, what am I looking for when I interview a potential “operator” to join our team? My vision for the upcoming series of articles is to share what I have observed in hope that the information security industry will produce more skilled attackers that are both effective and efficient. Internally, we call this looking for aptitude, intellect, and professionalism. I also hope to encourage more folks to enter the offensive security field. Finally, I want to raise the bar by educating leaders and decision makers about what to expect from firms offering offensive security assessments.
Focus on the objective
I find myself regularly asking during both interviews and engagements a variation of the question: “Why are you doing that?” This often occurs with new penetration testers who have never operated in a target environment before. Maybe they are excited to try out a sexy new tool or technique. Maybe they are lost or overwhelmed and looking for a quick “win” to prove to themselves and to the team that they belong. If they can demonstrate a successful exploit, mastery of a particular technology, or cool new attack that no one has used before, then they think their rapport with the team will increase. Cred is everything, right? (We will cover that later).
Everything we do should align with the objective. Each command typed, tool executed, system compromised, directory browsed, and document accessed should have a demonstrable link to our purpose for being in that environment. While this might sound like common sense, any experienced penetration tester can tell you stories of inexperienced and/or irresponsible n00bs taking down a network, crashing a system, burning a foothold, creating a legal issue, getting the team caught by the CSIRT or wasting hours of billable time on tasks that had no bearing on the objective.
Ultimately, the responsibility lies with the team leader. If the objective is not clearly defined, the team is wasting time. This waste of time does not make our clients any more secure and reduces their ROI, while increasing the operational risk (let’s be honest: technical security testing comes with operational risk). It is imperative for the team lead to work with the client to clearly scope the engagement objectives. Why are we here? How can we help you? What do you need out of this test? What story can we tell that will help you make your security program more robust? These are all key to defining clear objectives.
The engagement lead must also communicate to the team members and ensure that their activities align with the established objectives. Are we going after corporate email? How does popping the surveillance camera system support that objective? Do you need to be browsing the Legal directory?
A good example is Domain Admin: almost every red team on the planet wants to get domain admin access. It sends a strong message (“Look, we won!”), and everyone from your CIO to the Helpdesk understands the severity of losing control of Active Directory. So many things have to go wrong in the security program to reach the point of compromised AD, yet it happens all the time. For red teams, sending a stolen NTDS.dit back to the office to be cracked is like taking home a war trophy to show your friends – it just feels good and strokes the ego.
An important side note: getting domain admin, particularly when starting from inside the corporate network, is rarely a challenge. As any experienced offensive security professional can attest, the time from gaining the internal foothold to owning Active Directory is rarely more than a few hours. Reducing cached credentials in memory, implementing a robust password vault, hardening Active Directory in accordance with Microsoft’s guidance, and monitoring privileged account usage can drastically slow us down and provide the good guys a chance to detect our presence before any real damage can be done.
That said, I have been involved in investigating breaches of massive enterprises where the bad guys made no attempt to get domain admin access. Simply put, they didn’t need it. Targeting Active Directory would only have increased the likelihood of their getting caught. Their objective was clearly defined and did not require compromise of Active Directory. Instead, the focus was on executing the mission efficiently and quietly. To me, that is professionalism.
I’m certainly not advocating removing domain admin from the list of potential objectives for a red team. As I pointed out earlier, it sends a definite message that is often meaningful to our clients and even required to meet the team’s objective. Instead, I would like to see more offensive security teams realistically emulate actual threats by having a variety of well-defined objectives that guide the mission. This will increase efficiency and reduce operational risk, while ensuring that our attack path emulates that of a real-world adversary, thereby giving our clients something they can use to produce meaningful change.
For aspiring or junior red team “operators,” I encourage you to consider the following:
- Study how the real bad guys operate. How do they define attacks paths that effectively and efficiently accomplish the mission? Research what they do when they are operating in a hostile environment, and even more importantly, observe what they don’t do. For example: When was the last time you heard of APT running Nessus across an internal /24 or nmap’ing an entire intranet for all live services?
- Ensure that everything you do aligns with the objective. Have a plan for execution, and continually evaluate your activity in context of the mission. Resist the temptation to exploit those obviously vulnerable systems that provide zero value. Don’t browse into the “Payroll” folder if you don’t need that data.
- Demand accountability from your team leader. You should never be operating in an environment if you don’t clearly understand your objectives and attack path. When in doubt, stop and ask.
For organizations that are considering bringing in an outside team to conduct a Red Team Assessment, I encourage you to consider the following:
- Define your goals and objectives before you engage the security firm. What do you need out of the engagement to make meaningful change to your organization? How can the red team help you tell that story?
- Be sure to include objectives other than just domain admin access. Avoid telling the red team what you want them to do. Rather, let business leaders define what is critical to the business, and then let the attackers create realistic attack scenarios that exercise each layer of your security program that protects those critical resources.Ask the red team to explain their plan for accomplishing the defined objectives before they get hands on keyboard. Have them explain how their proposed attack path aligns with real-world threats. Ask for specific examples, not conjecture.
- Hold the red team accountable. Ask them what they are doing and why they are doing it. Don’t be afraid to interrupt the engagement and be very suspicious of any red team that cannot clearly and concisely explain how their actions will help accomplish the objective.
In Part Two, we will cover the following topics:
- Targeting – who, when, why, and how?
- Practical recon (aka put your scanners away).
- Think like a user (not a tester).