The future of red teaming not only requires updated adversarial tradecraft – although that’s a big part of it – but also a shift in buyer mindset to scope realistic scenarios that continue to test and challenge their defenses.
Red teaming involves the assessment of an organization’s ability to detect and respond to a real-world breach event. To emulate this type of event, it’s typical for providers to take a no-knowledge, no-access approach to ensure an unbiased engagement. As corporate and software development environments evolve with the adoption of new technologies, such as Kubernetes, containerization, fleets of MacBooks, and Mobile Device Management (MDM) solutions, the rules of engagement for red team exercises must also change to truly test an organization’s threat detection and response capabilities.
Applying the Adversarial Mindset to Non-standard Environments
Understandably, clients can become a bit flustered when pressed for environmental information during the scoping of a red team assessment. They are afraid that any knowledge transfer to their vendor will skew the assessment’s results. This is a valid concern, given the whole point of scoping one of these assessments is to see what an outside attacker could accomplish.
Hunting specific sensitive data in a traditional Windows network is largely the same across client engagements. A majority of the time, Active Directory and internal documentation discovered during the assessment contains enough direction to be able to track down and exploit goal systems, lending itself quite nicely to the no-knowledge, no-access methodology many red teams are accustomed to.
Where we see the traditional red team playbook breakdown is with clients who leverage modern technologies: cloud systems, SSO providers, fleets of MacBooks, MDM solutions, etc. While this certainly poses a challenge to red team service providers – requiring a change in tradecraft and potentially hours of custom tool development – it can also create significant costs to buyers of red team services. How much value can you really extract from a red team exercise when the engineers performing it are spending time upfront developing custom tools used to phish your MacBook and YubiKey?
In these situations, instead of leaving a red team in the dark, use your knowledge of known risk in the environment to focus assessments for maximum value. Put simply, test the scenarios that keep you up at night.
“Exceptional security services that provide high quality talent/resources and deliverable. You call Praetorian when you are not afraid of what they might find.”
– Director of InfoSec at Fortune 500 Company
You may now be wondering, “if your red team is not coming in through standard phishing attacks, then how are they going to break-in with zero prior knowledge or access?” This is where an honest assessment of risk comes into play. Do you allow your developers to install their own tools? What about third-party application dependencies? Does your infrastructure-as-a-service application allow for multi-tenancy?
Every modern application delivery system represents legitimate risk to an organization and phishing isn’t needed to compromise those systems. Given the custom nature of these systems and environments, it’s often hard to justify using them as targets for red team assessments.
However, attackers are beginning to show us that these systems are much more frontline than we once thought, with malware that performs supply-chain style attacks. Because many of these systems are custom built, some knowledge transfer or access granting may be essential to meeting the engagement goals.
To illustrate how this might work in your environment, we will present two real-world examples of red team engagements that targeted modern application environments. Each scenario highlights how the red team mindset can be successful without the need to fully restrict knowledge sharing between client teams and outside red team vendors.
Scenario 1: Modern software development supply chain attack
There is no better example of applying the red team mentality to new environments than doing so with non-traditional attack vectors. This scenario involves a Fortune 1,000 fintech customer who came to us looking to examine the impact of a supply chain compromise. The environment was about as modern as you would expect for a company that ships code several times a day: custom continuous integration/delivery (CI/CD) code, containerized microservices, mutually authenticated TLS connections, the whole nine yards. The supply chain attack scenario was intriguing to us and we were curious how they wanted to approach it while preserving the red team mentality.
Because this engagement involved tons of custom work, the client dedicated two members of its team to play the role of the “white team,” a unit with deep knowledge of the application environment we were assessing, that could act as an oracle for things the red team operators wanted to know. This oracle was not meant to introduce bias into the assessment, but to focus it, keeping the operators on track and eliminating attack paths that would otherwise take us away from the objective.
To start the assessment, our red team operators were given a week up front to do custom tool development. This included writing a backdoor for a Java artifact used in the build chain in one of the client’s applications. Time was spent developing the backdoor, a custom post-exploitation agent, and corresponding command-and-control server to complete all of the activities.
Once the malicious dependency was created, one of the client’s engineers with access to the artifact cache placed the malicious JAR amongst the other legitimate dependencies. Once in place, Praetorian operators waited until the natural build and deploy process picked up the malicious artifact and executed it in the CI/CD environment. From there, engineers were able to access numerous things in the application pipeline including deployment secrets, and other cloud resources.
The systems we came into contact with were proprietary and developed in-house, including the CI/CD framework, build systems, and container orchestration platforms. Because of this, Praetorian engineers adopted an approach that involved pulling application source code from accessible repositories, analyzing it for knowledge of the particular service, pulling deployment artifacts for the built version, and examining it for its running configuration.
Internal documentation was also queried to augment gaps in what code/deployment artifacts could provide. Through this process, engineers built a roadmap of attack chains throughout the microservice architecture. It was from this perspective that Praetorian was successfully able to demonstrate an attacker’s ability to go from a backdoored package, to full compromise of a production application with little to no detection.
The most important takeaway from this engagement was the level of direction and focus that was achieved through our relationship with our client and their engineers. It was a perfect example of remembering that even though we are there to represent the adversary, both teams were on the same side and ultimately pursuing the same goal. It was through this level of collaboration that both teams were able to successfully simulate a supply chain attack in a live production application environment, a task that prior to the engagement we would have not assumed was possible without months of preparation.
Learn more about Praetorian’s red team exercises and professional services →
Want to see how your defenders and their systems fare against sophisticated attackers in a safe environment? Stress-test your team’s capabilities against red team exercises led by Praetorian’s team of world-class professional operators.
Scenario 2: Demonstrating risk in CI/CD environment
In this next scenario, Praetorian was approached for a red team assessment in the traditional sense. However, it was later found that the client’s network was made up of MacBooks and they believed phishing was not going to be an effective vector for them, but they still wanted us to assess this assumption and see if our team could prove them wrong. Ultimately, we were able to confirm their suspicions – phishing was not going to be a highly-successful vector for a red team targeting their environment. A defense-in-depth approach had been applied to every component of their phishing-protection pipeline, including email gateways, web proxies, and endpoint detection and response systems on top of a fleet of MacBook laptops.
Next, our client wanted to attempt a scenario involving a compromised end-user system. Again, it was indicated to us that several iterations of red team exercises were done in this area, and they expected few results, but they still wanted to evaluate those assumptions. We provided them with a malware sample to run on a selected MacBook to attempt a compromise from this perspective and ultimately confirmed their assumptions. The endpoint detection and response software they had tuned for these systems was effective, and no further compromise of this environment was able to be demonstrated.
Lastly, the production server and CI/CD environment was targeted, in efforts to highlight detection gaps in production. As before, we prepared malware and sent it to the client. This time, engineers discovered that there were issues in their Jenkins implementation and privileged access to several production databases was possible by exploiting those issues. Secondly, this level of access revealed that CI/CD environment lacked detection and response systems that were running on corporate endpoints, rendering the subsequent response to the red team activities ineffective.
In conclusion, this client successfully applied the red team mentality and operations to an environment that would not typically be looked at as a starting point for red team engineers. Through the activities in the beginning of the engagement, it was clear that the client had spent many iterations improving the capabilities of their team to detect and respond to traditional corporate phishing and endpoint attacks, but ultimately learned new things when it came to doing the same in a production application environment.
Shifting expectations for red team providers and buyers
As technology shifts, and clients move away from traditional Windows-based IT stacks to more modern zero-trust networks, providers of red team engagements must also be willing to shift their idea of what a red team engagement might look like, and understand that ultimately, they should be custom fit to the needs and risk profile of a client. Modern adversaries do not have the same time and monetary restrictions as a red team will, making client collaboration an important tool for ensuring the success of a red team operation.
It is also worth understanding that red team assessments are possible in non-traditional environments, including development, containerized, and production application environments. Ultimately, providing your vendor with knowledge about your organization does not necessarily bias the results.
Want to see how your defenders and their systems fare against sophisticated attackers in a safe environment? Stress-test your team’s capabilities against red team exercises led by Praetorian’s team of world-class professional operators.
Sophisticated red team exercises are only part of the portfolio. Learn how Praetorian provides CISOs with valuable leverage across every phase of the enterprise IT security.
