Break It 'Til You Make It: How to Test and Harden Your Security
Because If You Don’t Break It First, Someone Else Will!
In a previous post, we explored the importance of Red and Purple Teaming–why simulating real-world attacks is crucial for testing your defenses before adversaries do. Now, it's time to take that knowledge and put it into action.
How do you structure a successful Red Team engagement? What makes a Purple Team exercise truly collaborative and effective? More importantly, how do you ensure that your security operations don't just detect, but actively adapt and improve in response to these tests?
We'll break down practical steps for planning, executing, and refining Red and Purple Team engagements so that you can go beyond theory and start hardening your defenses with real-world validation. We'll do this by exploring a "blind" Purple Team approach where only select members are aware of the activity, putting the Blue Teams detection and response to the test. Let's dive in.
Preparation Phase (Red & Blue Team Coordination)
Before beginning the engagement, the Red Team (offensive security) and Blue Team (defensive security) may coordinate in the following ways:
Intelligence Gathering: The Blue Team may provide details about the organization's existing security gaps to aid in selecting high risk targets or TTPs that are of concern. The Red Team may choose from a set of proven TTPs or develop new ones for the engagement.
The Blue Team shares concerns about legacy systems relying on LLMNR/NBT-NS due to outdated network configurations. The Red Team decides to test whether they can capture and relay NTLMv2 hashes from internal workstations used by financial personnel to escalate their access.
Detection Baseline: The Blue Team assesses what security tools and logging capabilities are in place.
The Blue Team reviews SIEM logs and finds minimal visibility into name resolution attacks. They note that while network segmentation is strong for customer-facing services, the internal corporate network lacks proper monitoring for credential theft attempts.
White Cell: The combination of Blue/Red team members and leadership that are aware of the engagement ensure fair play and alignment with business goals. The White Cell will always be in communication as the engagement is ongoing.
The White Cell, consisting of the Blue/Red teams, Security leadership, and compliance officers, ensures that the engagement aligns with compliance regulations (e.g., SOX, PCI-DSS). They require the Red Team to report all captured credentials at the end of the exercise to facilitate remediation and ensure compliance standards are met.
Rules of Engagement (ROE): This establishes the boundaries, objectives, and scope of testing (targets, techniques, Blue/Red team/white cell personnel). This would typically be an official document, but for the purpose of this exercise, here is a sample of its contents.
- What's in scope: Leadership has authorized the Red Team to use Responder to conduct LLMNR/NBT-NS poisoning on a portion of the network on select dates.
- What's out of scope: The team is prohibited from using harvested credentials for real financial transactions or accessing sensitive customer data.
- Source/Target IP addresses: Red Team source and target network subnet IP addresses are tracked. The Red Team is provided with an assumed breach server on the network to test from.
- The White Cell ensures no production systems are disrupted, and legal/compliance teams approved the test scope in advance.
Execution Phase (Red Team Attacks, Blue Team Defends)
The Red Team conducts realistic attack simulations (e.g., persistence, privilege escalation, lateral movement)
The Red Team leverages the assumed breach server to gain access and deploys Responder on the network. Within minutes, NTLMv2 challenge-response hashes are captured from multiple endpoints, including a privileged Finance department user.
The Blue Team, often unaware of specific attack details (minus the white cell representatives), monitors and responds to alerts from security tools (EDR, SIEMs, etc.).
The Blue Team's SOC receives a generic "failed authentication" alert in their SIEM but doesn’t immediately correlate it with an attack. Since no specific alerts for LLMNR poisoning exists in this environment, they fail to detect that credentials are being harvested. The Red Team continues operating undetected.
The Red Team assesses detection effectiveness while continuing to escalate its attacks, while the Blue Team evaluates incident response capabilities.
Using the captured NTLMv2 hashes, the Red Team performs a Pass-the-Hash attack to access an internal financial reporting system. They attempt to extract payroll data and wire transfer logs, demonstrating the real-world impact of credential theft within the financial institution.
Debrief & Transition to Purple Team
If the Blue Team detects and responds to Red Team activity, the engagement shifts into a Purple Team exercise, where the Red and Blue teams collaborate to improve defenses. If the Blue Team doesn't detect the activity, the Red Team can intentionally be more "noisy" to tip off the activity and force the shift into a Purple Team exercise.
Assuming the activity wasn't detected, the Red Team runs Mimikatz to tip off the Blue Team as it is heavily signatured by all security tools at this point and the shift into a Purple Team takes place. During the debrief, the Red Team explains how Responder exploited LLMNR/NBT-NS to capture NTLMv2 hashes and escalate privileges. The Blue Team acknowledges that disabling LLMNR/NBT-NS was never fully enforced via Group Policy across the entire network.
The Red Team shares TTPs used, while the Blue Team refines detection rules, playbooks, and response capabilities.
The Blue Team creates custom SIEM rules to flag:
Multiple LLMNR/NBT-NS requests from non-DNS servers
Unusual SMB authentication attempts following Responder activity
Suspicious NTLM authentication failures
The focus becomes the knowledge transfer between the two teams rather than just adversarial testing. The Red Team wants to know what got caught to better refine their TTPs, and the Blue Team wants to know what avoided detection to analyze logs with the hopes of refining or creating custom detections.
After the Blue Team works with IT personnel to disable LLMNR/NBT-NS, the Red Team adapts by testing MITM6 for IPv6 spoofing attacks, showing that while one attack path was blocked, other network-level attacks remain viable. This prompts the Blue Team to strengthen DHCPv6 security and disable unnecessary IPv6 services on endpoints.
Continuous Improvement (Purple Team)
This cycle continues repeatedly to strengthen defenses based on real attack simulations.
The Red & Blue Teams implement an annual assessment strategy where they periodically reenable LLMNR in a test environment to validate the SIEM and endpoint detection rules against Responder attacks are still viable.
The Blue Team refines its security tooling and procedures, improving overall detection and response efforts.
LLMNR/NBT/NS is fully disabled via Group Policy across all workstations and servers.
SMB signing is enforced to prevent NTLM relay attacks
Multi-factor authentication is enabled for all privileged accounts and Credential Guard is enabled to mitigate Pass-the-Hash attacks
The organization gains a more proactive security posture rather than reacting to a real-life incident.
When legitimate Responder usage occurs, the use of Responder is immediately blocked, the Blue Team is immediately notified, and incident response plan is activated before any damage takes place.
Different Approaches to Purple Teaming
There are different ways to conduct Purple Team engagements depending on an organization's security maturity and objectives. Some engagements are Purple from the start, where both Red and Blue Teams are fully aware of the activity beforehand, allowing for real-time collaboration and knowledge transfer. Others, like the one described in this scenario, begin as a blind exercise where the Blue Team is unaware of the attack initially to test their real-world detection and response capabilities before transitioning into a collaborative learning phase.
Want to dive deeper? Keep an eye out for future posts where we explore different approaches and how they stack up for your security program.
This is great! Very useful information that all enterprise security teams should be replicating. Thank you for putting this together.