Don't be Dogmatic

Different teams and organizations will have different philosophies and approaches to red teaming.

• Be the threat actor, follow their TTPs, and target their goals
• Be your own threat actor, do what you need to get in to achieve some objective
• Ignore the threat actors: identify internal attack paths and harden those

I think they can provide even more value if you broaden the scope from Adversary Emulation to Offensive-Security-Jack-of-All-Trades-Who Understands-the-Business.

As an aside, this is more focused on internal Red Teams as opposed to consultant Red Teams (although a quarterly subscription with a Red Team consultancy could be deemed pseudo-internal), since an embedded team provides a multitude of valuable and rewarding characteristics.

• Over time you know where to attack and what to ignore
• Identify and drive systemic improvements that uplift the entire company
• Typically provide ample time for development and internal automation

Consider the following approaches.

"Red Team" All the Things

After a few successful operations highlighting compromise of assets and weaknesses around initial access, lateral movement, and exfiltration, many organizations begin to request Offensive Security work which may be fielded by the Red Team.

But poorly articulated "red team" exercises can end up looking like penetration tests. If your goal is to "test" your Azure environment you're probably conflating multiple approaches.

While the outcome might result in positive changes, a security audit, a goal-based hypothesis (e.g. can an attacker obtain AWS KMS keys to decrypt data), or an adversary emulation activity to determine detection and response capabilities could probably provide a bigger impact and relationship-building opportunities.

Adversary Emulation Red Teaming

Depending on the organization and industry, we want to understand if a Threat Group could target our business using their published techniques and strategies, validating our controls and defensive capabilities.

These typically have the following characteristics

• Executing, acting on objectives, silently leaving, and writing a report
• Are more expensive, and may take several months
• Use unique skillsets (OPSEC, initial access, EDR evasion, post-exploitation)

This seems to be how most Red Teams are operating, or at least where most of the industry chatter is. There is certainly a time and place for Adversary Emulation exercises but in my experience, these should be desired, requested, and planned with and for Blue Team leadership.

If the Red Team sees its mandate to improve detection and response capabilities without a true desire from the Blue team for those exercises, relationships and collaboration opportunities are likely to be harmed. Internal red teams should consider hiring these exercises out if politics are in play, or work in lock step with the relevant leadership and management.

Business Risk Red Teaming

An alternative to the popular understanding of Red Teaming, or maybe a throwback to the OG definition of "Red Teaming". We want to identify unexpected or unknown paths an attacker could use to achieve some objective that would harm the business.

• Identify attack chains
• Whitelist attack tools, C2 traffic, and other offensive technical capabilities
• Focus on feature abuse, credential theft, architectural issues

An average internal red team should focus here for cost-effectiveness. EDR bypass capabilities can be useful but aren't necessary to identify attack paths. This removes the skill and time barriers for obfuscated tools and techniques and allows the team to uplift organization security in cases regardless of EDR or 0-day capabilities. Consider this an extension of Assume Breach, and modify it to suit your needs. For example, if Blue identifies suspicious activity or techniques, consider that attack chain no longer valid for a given operation.

I've seen excellent success in building relationships and uplifting security controls across the enterprise when the focus is on Business Risk Red Teaming vs pure Adversary Emulation, at least from an internal Red Team perspective.

Conflicts of Interest

There are also conflicts of interest in combining attack chain identification (Business Risk Red Teaming) and response testing (Adversary Emulation). If you do adversary emulation to achieve objectives you're probably going in as stealthy as you can and then ramping up the noise and reducing the sophistication of techniques to identify a threshold of detection and response.

But this can create conflict between red and blue. Red trying to use or create cutting edge techniques and tools, with Blue distrustful of anything that may be Red Team activity, especially if they're being graded by their colleagues. Sometimes this can be healthy competition. But I've certainly seen disgruntled colleagues who feel they're playing a game where the rules are always changing and the Red Team is judge, jury, and executioner.

Keeping attack chain identification and response testing separate can still achieve your Red Team goals, still identify and fix attack chains, still cause pain for attackers (and Red Teams), still improve detection and response, all the while retaining business relationships.

Prior Art

Andy Robbins of Specter Ops has an excellent long form article on Attack Path Management Manifesto which is well worth your time. In re-reading the post, one quote stood out as articulating the message of this article:

The problem is not that the red team assessment provides no value. Red team assessments provide tremendous value by training or validating the detection and response capabilities of an organization. The problem is in trying to use the red team assessment for something it wasn’t designed for: understanding, quantifying, and eliminating or mitigating Attack Paths. This can lead to frustrating outcomes for red team professionals and their customers, where Attack Paths are discovered and executed year after year after year — it can start to feel like chasing your tail.

The Specter Ops post largely speaks to Active Directory but can be easily applied to systems and the organization as a whole.

Enable the Business

At the end of the day, regardless of red or blue, our job is to securely enable the business or reduce business risk to the company. Take what fits from the industry and redteam.guide, but don't be dogmatic about how the job gets done.