- Our Annual Threat Report data shows a misalignment between red team activity and true attacker activity.
- They vary in frequency, surfaces targeted, and techniques used, suggesting red teamers could benefit from realigning to real world attack data.
- The bigger picture considerations point to incentives driving the misalignment, and leaders need to consider changing the incentives.
Red teamers are defenders’ allies. Their goal is to help make defenders better by exposing security weaknesses. They enable defenders to know where the holes are so defenders can reinforce their defenses. But in practice, is that goal achieved?
If you hire a red team and they don’t get in, do you think “my defenses are good,” or “maybe I need a better red team”? This dynamic of how red teams are assessed drives them to get in at all costs. A red team report showing the extent of penetration is a good report. A red team report confirming all the doors are locked? It’s unclear how that will be perceived by the receiver.
What does that mean, then, about what the red teamers are doing?
In Expel’s 2026 Annual Threat Report findings, something interesting emerged when reviewing cloud infrastructure. The biggest share (32.2%) of incidents we saw here were confirmed as red team incidents. Yet, cloud infrastructure only accounted for a very small portion (2.5%) of our overall incidents.
This raised a useful scoping question. Red teams emphasize cloud exercises at rates that exceed the attack prevalence in these spaces. This means red team reports may include successes where the risk of malicious attacks is lower than other attack surfaces—but why?.
Red teams hitting things attackers tend not to has happened for years. Red team reports, in many cases, are assessed on crude metrics of counts of findings or significance of findings. These metrics do track to a measurable value proposition to the defender, but they may also lead to misalignment. In short, if red teamers are having success where attackers don’t play, then what value is delivered?
When incentives are misaligned with outcome metrics, the value delivery fails. In practice, it’s hard to get this tuned to an efficient model for many reasons. The delivery of security outcomes red teams are meant to help suffer as a result. When red team reports are used to align resources to gaps, misaligned incentives result in prioritizing work of lower importance. This means organizations could mitigate more risk by paying attention to other, higher priority items.
To put these ideas to the test, we decided to take an objective look at incident data from our annual threat report to see if we could find mismatches between what the red team is reporting versus what real-world attackers are targeting.
Cloud infrastructure
To start, we looked at cloud infrastructure incident data. We split our attack data into two groups—the incidents flagged as red team activity versus real attacker activity. To classify these attacks, we align them to the MITRE ATT&CK framework. This gave us a categorized view of what the red teams and attackers were doing when our SOC was alerted to the activity.
Red team focus
Two tactics immediately stand out when looking at red team use compared to real attacks: initial access and privilege escalation. This makes sense because demonstrating penetration is the goal, and these two are directly related to access. The former is the moment a red team can point to and say, “we got in!” The latter can demonstrate the depth of compromise and the potential to go further with newfound access rights.
Next, and possibly most interesting, is lateral movement. This tactic stands out because it didn’t appear in any of the real-world attacks within our dataset—only red team exercises. This is the most striking difference overall. It hints at the fact that real-world attackers may not need to move laterally to achieve their objectives, especially if what they’re after resides in the cloud.
This might partially be due to red teams overusing playbooks in the wrong place. Red team alerts of lateral movement included attempting to leverage SMB or using NTLM relay. These are somewhat endpoint-centric techniques, suggesting red teams may be bringing their endpoint playbooks to the cloud. Our data doesn’t show real-world attackers making this same mistake.
Real world attacks
On the other side of the fence, real world attackers appear to be far more focused on the discovery phase. In cloud environments, where a single compromised credential could end up giving access to a sprawling infrastructure, attackers need to map out what’s in front of them before they can capitalize on the access. This is good news from a defensive standpoint because it provides plenty of opportunity for detection.
In this space, we observed attackers using AWS commands allowing them to gather details on the accounts they found themselves in and locate associated S3 buckets. Beyond that, an attacker in this position could scan for exposed services or gather details about EC2 instances.
Catching activity at the discovery level may not make for as compelling of a red team report. If red team reports are used by defenders to fill gaps, discovery activities should be part of the red team playbook. Catching the attacker in the discovery phase is a good outcome because this happens early in the attack chain.
Attackers were also far more frequently caught during the impact phase, which is where the risk is realized. A red team isn’t going to go and destroy a database just to make a more compelling report. Red teams, however, can demonstrate access to do damage and they should do so.
Command and control attacks appear in the real world, but didn’t appear in any red team exercises. We found several real incidents where real-world attackers managed to install commodity malware in EC2 instances. In other cases, cryptomining activity was detected. These are real and relatively common threats. Opportunistic attackers are looking for exposed instances and deploying semi-automated payloads when they’re found. Red teamers are absent here.
Endpoints
Seeing these results on the cloud infrastructure front made us curious about the other attack surface where we’ve seen red team activity in our annual report: endpoints.
Here, the percentage point differences are pronounced. In cloud infrastructure incidents, there was about a range of 5 percentage points. On the endpoint side of things, this range sits upwards of 15 percentage points in some cases—a much larger difference between attackers and red teams.
Red team focus
On this attack surface we find the starkest difference between red teams and real-world attacks in credential access tactics. Red teams were observed attempting to attain credential access far more often than in real world attacks (by 17 percentage points).
Dumping credentials is a red team staple, as tools like Mimikatz make this an almost ubiquitous part of red team engagements, since it produces tangible artifacts for a report.
Why isn’t endpoint credential access more common in real-world attacks? We theorize attackers pick up credentials through phishing and other identity-focused attacks, long before they reach the endpoint. And according to our report, 63.9% of the time when attackers get to the endpoint, they deploy malware—threats like commodity malware and ransomware. It looks to us like the access the bad actors start with is enough. Harvesting credentials isn’t needed if you can already get to your goal with your current access.
Real-world attacks
When it comes to actual attacks against endpoints, real-world attackers appear much more likely to focus on defensive evasion, which has a 13-percentage point gap in their favor. The reasons for prioritizing this are obvious—when the circumstances call for an attacker to stay undetected, this betters their chances of completing their objectives.
There were also two tactics used by real-world attackers where the red team was absent. Persistence was the largest, where our SOC was frequently alerted to attackers performing tasks like creating scheduled tasks for threats such as ManualFinder. The lack of red team incidents probably points to a priority mismatch, where playbooks don’t adequately cover persistence tactics. It’s also possible this is restricted by rules of engagement.
No red team exercises appeared to test exfiltration, making it the second tactic with a red team absence. It’s worth noting that supply chain attacks in early 2026 were the source of several of our exfiltration incidents, particularly NPM supply chain attacks. This exemplifies the concern of a lack of activity by red teams here. Another entire risk wholly unrepresented by red team activity.
There are practical reasons a red team would stop at exfiltration—you can’t necessarily remove the client’s data just to prove a point. The fact remains that red team engagements carry explicit boundaries around what is permitted. But this limitation can also mean a relevant stage of the attack chain regularly goes untested. The result is structural misalignment between red team activity and the overarching goals of driving better security outcomes.
A new model
Based on what our examination has surfaced about the difference between red teams and real-world attacks, here are some recommendations for what a new red team approach could improve.
For the red team
Push for the scope of engagements to model real-world TTP frequency
Instead of defaulting to standard playbooks, calibrate exercise scopes to observed attacker behavior. Our annual threat report is a good starting point, though there are several other options that publish TTP frequency data you can use. The bottom line? TTPs regularly go in and out of style, so it’s important to stay up on the latest fashions.
Leverage real attack tools and playbooks, not the red team’s default one
The data presented here gives a clear direction to start your journey. In cloud environments, simulate C2 and discovery instead of lateral movement and privilege escalation. For endpoints, put more emphasis on defensive evasion, persistence, and exfiltration. Spend less time on credential harvesting.
Dig into MITRE ATT&CK techniques to calibrate your exercises
Looking for something to do for each of the tactics we recommend? Utilize the ATT&CK Navigator to view the frequency of tactics and techniques visually, helping you better plan out your red team exercises.
Create a feedback loop
The model we’re proposing isn’t an evergreen process. Rather, it’s an ongoing calibration where data from real incidents continuously informs what your red teams prioritize in an engagement.
For leadership
Maximize realism in red team engagements
The red team is going to model attacks within the scope of the rules of engagement. Draft them too tight and you’ll get unrealistic results within constraints that an attacker won’t honor. Take care to allow red teams to test things within acceptable risk-scoped rules of engagement.
Be ready to accept “no access obtained”
There’s a feedback loop here that leadership needs to recognize: red teams don’t get hired back (or promoted) when they don’t deliver results—they’re incentivized to get access at all costs. This is classic Goodhart’s Law in action. How you define results can drive red teams to unrealistic attack modeling.
Consider creating a safety net for the red team
The industry has driven a bad outcome here, and there needs to be proactive work to drive it back. Get specific on how much you want the red team to pull out unrealistic tricks they have on hand. Define for them whether these tricks will count for or against in a rubric to hire them back the next year (or promote/deem the work successful if internal).
Most of the time, the goal is to find high risk gaps
Many times, red teams create a sort of justification for prioritizing risk mitigation. Sometimes, though, red teams can demonstrate theoretical attacks that are high impact but very low risk. This happens when they do things that attackers aren’t doing. Define explicitly how you want to score these.
The importance of red teaming
None of what we’ve covered here is an argument against red teaming or the value that it brings. Any team that stress-tests your defenses brings value, and the findings from a well-run engagement can improve your security posture. The question isn’t if you should use red teams, it’s how well you set the red team up for success.
The data we’ve shared presents a story about a gap between where red team time is spent and where real-world attackers are operating. Red teams can demonstrate that they can get in, but real attackers are focused on their objective, which goes beyond just gaining access.
The good news? Closing the gap doesn’t mean reinventing the wheel, it just means utilizing better definitions and processes. When red team exercises are grounded in real-world TTP frequency data, the output becomes dramatically more useful. You’re not hardening doors that few people walk up to and open, you’re building defenses where there is measurable foot traffic.
Red teaming works best when it reflects reality. The closer an exercise mirrors what real attackers do, the more confidence defenders can have that their detections, response playbooks, and security investments are calibrated to the actual threat. Mirroring what attackers are doing is the best way to align red team delivery to meaningful risk mitigation efforts.
