How to Create an Internal/Corporate Red Team
Congratulations! Your organization has approved the creation of an internal Red Team program and tasked you to do it! Here are some quick easy tips to get this program off the ground as simply as possible, based on Q&A I have done with a number of old/mature corporate Red Teams, brand new corporate Red Teams, and lessons I’ve personally learned (some of which were the learned the hard way). I am publishing this here as a reference for others who reach out and request help getting their programs started. This is just one way you could do it — take it for what you paid for it.
Step 1 — Build Relationships with Blue
Before you plan an “op,” scan a perimeter, stand up that C2 server, or send that phish, just go meet with the members of your organization’s Blue Team — the nice people who own the DETECT and RESPONSE pillars of InfoSec. Ask them what they’d like to see (or not see) in the Red Team program. If possible, do this in person, over food and drinks, with the entirety of the team — including all the individual contributor roles.
Also, repeat this periodically. At least annually, if not more often.
Step 2 — Unit Test Your Detections
[Note: This step isn’t “red teaming” yet, but this will get more instant value back to your organization while you learn the team culture and plan for how you will begin full blown Red Team campaigns. Since it’s not “red teaming” yet, I recommend making it quite clear to all parties (red, blue, management) that this is a temporary first step action and may or may not be staffed by the red team going forward, but your organization will probably want someone to continue doing this.]
You can check your detection coverage for FREE with Atomic Red Team, and if your organization likes it, you can scale up to a number of commercial products that can automate this for you. Run a test for a specific set of TTPs from the MITRE ATT&CK Matrix on various hosts with different vantage points on the network and check to see if they result in alerts to your SOC. If not, dig in with your SEIM and EDR/AV analysts and find out why not. The output of this should be a pretty good map for where your organization has good detection coverage and where it doesn’t. This is VERY PURPLE.
Bonus Points: dig into the specific test cases themselves and mutate a few details about them, to determine how brittle the detection is. For example, maybe your AV only detects the presence of Mimikatz by the nice French words that Benjamin Delpy put into its menu system, so modify those away, or compile modified source code and try again. Or maybe your EDR only detects live off the land binaries when they are executed from the path where they are installed by default, so copying them to a temporary directory or renaming them may break the detection. Use your imagination.
Step 3 — Draft Your Rules of Engagement
Create a Rules of Engagement (ROEs) document that says how the Red Team exercises will start, stop, pause, what’s allowed or not allowed, who the approvers are, what the escalation paths are, what the final deliverables are, etc. Try to keep it simple; think more “Bill of Rights” and less “IRS Tax Code.” This could be as little as about 5 pages long, give or take. If you did Step 1 correctly, you will have an excellent rapport with your Blue Team, upon which you can modify the ROEs after each exercise when something is less than ideal.
I strongly recommend you identify a “trusted agent” who will be a member of the Blue Team who is not in a direct response role for the exercise but can observe both sides’ activity transparently to ensure the rollercoaster stays on the rails. This person (or people) should also be responsible for grabbing copies of logs on systems that roll off quickly so better data is available during debrief, which could be several weeks later.
If you’re going to do physical (going onsite without authorization) attempts at initial access, now is also a good time to figure out who from the physical security side will be your backstop for escalations and approvals. I recommend approaching this person with the attitude of “we are going to use physical means to access cyber resources” which clearly respects the ownership of physical security with the leadership that is likely outside of the Information Security department. You are not trying to take their job; you are showing the blend of the two disciplines has a legitimate impact to the “cyber” aspects of your organization.
Step 4 — Baby’s First Red Team Exercise
With Steps 1–3 complete, it’s time to do a first Red Team exercise. If you are new to this discipline and left to your own devices, you will probably do a pentest++ style first exercise. That’s okay, provided you understand it’s a starting point.
I recommend the following:
- Pick a specific access objective (but keep it simple, like access to an Accounting system, or privileged access to an IT system); “king of the hill” could be a reasonable first objective, but probably shouldn’t be the goal of a mature red team program.
- Setup an internally hosted VM to run your single and only C2 server (for the first one, skip all of the drama of procuring external VMs for redirectors, DNS domains, categorization, etc.), but note that this completely avoids a very important set of telemetry with your egress stack. The tradeoff is welcome in exchange for a simple first exercise.
- Use an “assume breach” methodology: ask your trusted agent to provide access to an internal target system (e.g. workstation), and prepare a payload to execute on a target system or use credentials provided to you to live off the land. Going full outside-to-inside is difficult (as it should be!) and you will gain more benefit to your organization by getting more repetitions in with the post-exploitation part of the attack chain, than the initial access phase. (You’ll add this in later.)
Because of Step 2, your Red Team will know where your organization’s detections are strong and where they are weak (or non-existent). Use these strategically. For example, perhaps you can identify a chain of TTPs that do not have solid detections that can be used to reach your objective. Once the objective is reached, you can choose to use some of the TTPs that do have solid detections to effectively raise the alarm bell and create an opportunity to test the organization’s ability to respond to the alert and contain the threat. Or, sprinkle in a mix of known detected and known undetected TTPs to create an event to which the Blue Team can respond prior to reaching the objective.
After the exercise is complete, ask the larger Purple Team the following 3 questions: what went well, what did not go well, and what should we change?
And repeat those 3 questions after every exercise going forward.
Step 5 — External Infrastructure
If you’ve done everything in steps 1–4, you’re ready to make this more realistic with a C2 server that is actually external, but I still recommend you phase in the complexity. I also recommend sticking with assume breach as a starting point for a little while longer and keeping your objectives simple while you do so: just privileged access to systems. This will enable you to start to test your organization’s entire defensive technology stack, including egress telemetry and filters. After all, real adversary’s won’t have C2 servers on your network (or at least if they do, they’re special).
Start with Domain Fronting (if that’s still available for CDNs that you are allowed to use) or use a whitelisted domain, such as a free DNS domain suffix provided by any of the common cloud providers. This will get you a mostly categorized and definitely aged DNS domain to make your first external redirector simple. You can even ask a Trusted Agent to specifically whitelist the domain as assistance for a first exercise.
Over time, add in complexity:
- Multiple redirectors/domains for different compromised hosts
- Separate domains/infrastructure for staging and gating payloads
- Different external hosting providers to start adding in variety
- DNS domains that the Red Team procures, ages, and categorizes
Open up your creativity, while continuing to use a mix of known detected and undetected TTPs, just like in Step 4.
Step 6 — Advanced Objectives
As part of the next evolution, expand your target selection to better match the threat actors with which your organization is concerned.
For example, if your organization’s top threats are FIN actors, pick data objectives and TTPs that match. This could be emulation of a specific threat actor group, or more likely, a collection of TTPs from a composite of several similar threat actors. Also, modify your target objectives to match. A FIN group probably doesn’t want long term sneaky access — they want to smash and grab monetizable data. A nation state APT, by comparison, probably does want long term sneaky access, and probably doesn’t care about things like credit cards. Leverage your threat intel program for this information, if possible.
Step 7 — More Initial Access Vectors
This particular step does not necessarily need to come after Step 5 or 6 and could be done in parallel, but it should be a conscious effort to do this separately.
There are primarily 5 ways an organization can be breached. It’s important at some point to begin to move away from the assumed breach methodology and start from the outside in using those 5 methods of initial access, because that’s how real breaches happen and as a result that will train responders to see all of the event breadcrumbs of a real attack. The level of time commitment here will vary with each organization, its size/scale, and the talent and specialties of members on the Red Team.
Definitely spend time looking at email-borne phishes as a means of external-to-internal access, because these happen to major organizations every single day and are the biggest threat by volume. While I do not recommend that you limit your Red Team to only the email-borne phish vector, I do recommend that you take a phased approach and focus only on one at a time.
As you continue to ask the team “what went well, what didn’t go well, what should we change?” after each exercise, you will likely see patterns emerge for certain skillsets that would be beneficial on the team. Use that knowledge to shape future hires when expanding the Red Team, so that you can feel comfortable with any of the 5 methods of initial access.
Timeline
I would expect any nascent Red Team program following this guide to easily spend as much as the first 6 months working on Steps 1–3, possibly longer, depending on the size of the organization, the number of people on the Red Team, and how deep your team goes on Step 2.
Most brand new Red Teams tend to underestimate the amount of time that is necessary for a new exercise, basing it upon their past experiences with penetration tests. A 3–4 week penetration test is a long test, but it’s a short Red Team exercise, especially as you get to Step 5 and have to spend time setting up and aging external infrastructure.
I would expect a new Red Team program to take as long as 2 years or more before they’re likely really ready to start digging into Step 6 or 7, but overall this is just one set of recommendations and you may be successful blending the steps or even doing a couple of them in parallel. Overall, a large and well equipped team could follow the steps laid out above for several years before they run out of areas to work on. By then, you’ll have lessons to share back with us.
