This multi-part blog post is about a tool we released: RedELK. In a few words you can describe it as a “Red Team’s SIEM”, although it actually does a few more things to ease the life of red teams. We released it right after our talk at BruCON 2018, and you may have already seen it at our GitHub. But until now we haven’t had the time to articulate our reasoning and give it a proper introduction.
This first part covers our reasoning. A the second part (soon to be released) we’ll dive into the technical details, explain basic usage and show you how you can benefit from using it as a red teamer.
red teaming != red teaming
When discussing red teaming with clients or talking with our peers it becomes very clear that there is no common definition of ‘red teaming’. It’s explained in many different ways, all with varying goals and approaches. We hear things like Adversary simulation, pentesting plus phishing, carte blanche pentesting, playing offensive Devil’s advocate, or things along the line of the US DOD definition for non-IT red teaming. This results in many forms of professional services offered in the market.
In many ways this reminds me of ‘hacker vs. cracker’ in the late 90s, or the more recent discussion about using the word cyber. I have no intention in trying to close this debate. I know of more fun things to do with my time. 🙂
But before going forward I want to stress a few things we see as very important when we perform a red teaming engagement, and what our clients tell us they greatly appreciate. I’m talking about using creative but relevant attacks, performing simulation of real adversaries (how many attackers run Nessus?), creating a team with a relevant and diverse skillset and creating and using tools that support your workflow. These are all pretty standard, right? Yet often its forgotten that red teaming is just as any professional service. This means that perhaps the most important aspect of it all is that you need to create value with your service.
Create value
You are not doing this red teaming thing (just) for fun. You need to be helpful and create value. This reflects in many things, one being that your hacks can be super l33t, but if you can’t properly write it down or present it, or if you go after targets that have zero business impact you are not creating any real value. If you don’t create any value, then what’s the point?
Keeping that in mind, let’s look at a few important topics that we often find to be forgotten in discussions about red teaming. These may also help in understanding why we created RedELK. I’m talking about: training goals, attack scenarios and keeping track of highly adaptive attack infrastructures. I’ll explain each of these below.
Wrecking ball approach
Red teams have obvious target goals, e.g. full access to a financial core application, export 5000+ records of important application X, copy the engineering files of the newly designed rocket ship, etc. These are obvious targets, which we often dub impact goals during discussions with our clients. But we strongly feel there is also something called learning goals. Let me explain why.
Roughly said, the blue team’s role is to defend, the red team’s role is to attack. Defending is not done just in preventive measures. Just as important is the ability to detect and to respond to attacks. Blue teams have tools for this, but for a larger part this comes down to actions and decisions made by the blue team when an attack is happening. So, this needs to be trained. And ideally this needs to be trained on a level that is just above the team’s skills as learning is excelled when done just outside the comfort zone. Yet, at the same time we see many red teams keeping important details of their attacks for themselves (minimising learning opportunity), as well as red teams going for the what we like to call wrecking ball approach: all power used, completely blow away the blue team, loot the gold and walk away from an utterly destroyed Blue Team. This only helps for making an impact, and perhaps your ego. But are you really helping? Are you creating value?
We strongly believe that there are invaluable lessons for the blue team in experiencing to be under attack. This means that if during an engagement we are not caught, we will make more noise, generate events that will get us noticed and will put processes in motion on the blue team. Within professional services we go as far as stating that a red team that went undetected in the entire operation is a failed red team (at least in terms of learning goals). So, we strongly feel that a second important goal of a red team should be to generate a learning experience for the blue team. You want KPIs? How about generating 3 AV alerts, or a bit more relevant: a prio 1 SOC alert or a blocked C2 channel.
YOLO red teaming
Attacks without a reasonable scenario definition are a hit or miss. We like to call this “yolo red teaming“. Example: an organisation with PII or IP is really concerned about a competitor from the other side of the world and hires a red team. The red team choses to perform the attack via mainly physical components (attack guest WiFi, walk in dressed like AV mechanic, etc.) because that poses an easy way in. One can ask the question if that is relevant when the adversary is on the other side of the world. Sure, when the data is important enough it’s possible they might fly over agents to perform the attack locally. But is it realistic? And sure, the client may get really good findings that helps them fix issues regarding WiFi, physical access, badges, etc. But does this really help them? I’m pretty sure that in this case a more likely path would be an attack carried out along the lines of online recon, spear phishing with maldocs, domain fronted C2, internal recon, pivoting to administrator of the system and gaining access to data. This may also mean that for a single engagement you define multiple scenarios that are relevant, and you carry out multiple scenarios. The TIBER framework for example states its mandatory to define, agree and perform multiple relevant scenarios based on relevant threat intelligence.
You want KPI’s? Prior to the start define a scenario that resembles at least 2 publicly known actors and use their techniques in the campaign (MITRE ATT&CK can help you with this). Another is the amount of money you transfer from the financial system if that’s your scenario. You may think that 1 million euros is a lot, but for many organisations it’s immaterial.
Infrastructure herding and recording
When doing larger operations that span multiple months, multiple scenarios, multiple different C2-servers and where you put redirectors in front of every entry point where your target interacts with you, you are working with an infrastructure that becomes very large very quickly. This makes it harder to keep track of what is happening on your offensive infrastructure. In some cases it may already be a problem to even keep track what components are part of it.
Just as blue teams need to protect their infra, red teams need to do just so. But this goes beyond typical preventive security measures for IT systems. I’m also very concerned about keeping control of all the operational logs of all relevant systems used during the engagement. I’m talking about traffic logs from your redirectors, about transcript logs of your performed actions on your target’s systems, about clear lists of IOCs and details on where and when they were positioned, etc. Knowing all relevant details and events of your infrastructure during as well as after the operation is paramount.
Muhammed Ali’s trainer
To summarise: we don’t want to be a wrecking ball, but want to engage in a proper (sparring) fight. We don’t want to bring a gun to a fist fight, but want a fair fight according to defined rules. And lastly we want recordings of the fight so we can analyse every bit afterwards if needed.
In other words: we don’t want to perform like a Mohammed Ali that uses all his force and skill to knock down a (junior) player. A better analogy is that we believe the blue team is Muhammed Ali, and the red team’s role is that of the trainer that helped Muhammed Ali reach that magnificent level. We explain this in a tad more detail in the first few minutes of our BruCON talk, roughly from min2 to min8.
Your redteamlog.txt and grep-fu are insufficient
As red teams grow in team members, as engagements grow in level of detail and in interaction with blue teams, as the amount of parallel engagements increases, your redteamlog.txt will simply not suffice. Although your teamservers do store logs, those logs are local on that system. The same goes for traffic logs of your C2 redirectors, payload delivery webservers, email servers, etc: it is all local on that system. Of course, you can centralise logs rather easily and run some greps. Once centralised you may even perform some enrichment on those logs. But this is all very flaky, error prone and simply not a mature solution.
What we want goes further than that. We want to be “in control” at any time. I mean this in two ways:
- In control in the sense that we want as much central overview and enhanced usability as possible. With a few clicks I want to have full listings of IOCs, easy overview of commands performed by operator X on day 34 in scenario B and, an easy way to find that one keystroke logging that contained that vital password, quickly be able to answer if we moved laterally from system A to B, etc. I want this during the operation, as well as afterwards when we go ‘Full Monty’ in post-attack sessions with the blue team.
- In control in the sense that we want to know when we are getting near the learning goals: we want to detect blue team actions, so we can make informed decisions about next steps and overall provide a better learning experience for the blue team. In other words, we want to know when the blue team has spotted us and even when they are simply investigating some of our artefacts. In case of very mature blue teams we want to exploit the slightest failure in their OPSEC to gain next steps in our attack.
RedELK was created to get in control on both those aspects.
The current public release does a good job on the first, and a basic job on the second. Already it has helped us a lot during our operations. But before we are at a level that we are truly happy we have many more steps to make. Amongst others in more ways for detecting blue team activity. Any blue team will tell you they are never truly happy with their monitoring rules, so the same goes for us. The supported infra components are also something we feel needs improvement. However, as it has already helped us a lot, we feel it’s ready for a public release.
Go read the second blog, watch our BruCON talk or head over to our GitHub and give RedELK a try. For complaints, fanmail and rants you best check me on Twitter. Or if you want to see what we have got planned for new releases make sure to catch our upcoming presentations at x33fcon and Hack in Paris.