Otto background

Purple Teaming to Challenge Your Security Team's Assumptions

Many companies with mature security teams are becoming increasingly aware of the benefits of purple teaming, and Automox is no different. As an endpoint solution that runs on every one of our customer systems, we understand the need to regularly evaluate our people, processes, and technologies against common and emerging threats targeting our industry.

At Automox, we wanted an efficient way to identify detection gaps and challenge our assumptions while also fostering a collaborative culture across the organization. This is what led us to go all-in on purple teaming.

Today’s discussion on purple teaming comes to you from Automox Director, Security Chris Hass, and Senior Security Engineer Adam Nadrowski. These gents are well versed in threat research, malware analysis, and adversary simulation. Read on to learn about purple teaming and how Chris and Adam have implemented the practice at Automox.

What Is Purple Teaming?

Purple teaming is a way for an organization's offensive and defensive security teams (the red and blue teams, respectively) to work together and learn from each other. The red team presents and executes their attack, while the blue team detects and responds.

Both teams are genuinely interested in each other's techniques. And we found this naturally fosters a positive discussion without the typical “them vs. us” mindset. The results of each phase of the attack are then documented and followed up on after the main exercise.

The goal of a purple team exercise will depend on the security risks targeting your organization. Typically, we work with our leadership and network owners to help identify our greatest risks. Some questions our purple team exercises have aimed to answer:

  • Are we prepared to detect and respond to a credential-harvesting attack?

  • Do we have the capability to detect a compromise of our DevOps pipeline?

  • Will our Endpoint Detection and Response (EDR) product detect a malicious IDE plugin performing post-exploitation techniques on developer endpoints?

We come out of every purple team engagement with a list of validated and challenged assumptions. Both are valuable in their own way, but challenged assumptions are naturally more interesting as they teach us about ourselves and require improvement, so let's talk about these.

EDR and macOS/Linux

EDR tooling has fundamentally changed the game for both defensive and offensive teams. The amount and type of data being collected provide insights into environments that enable us to detect anomalies and adversary behavior.

If you’re lacking an endpoint solution and are considering improving host visibility in your environment, EDR is a must. However, be warned: As with all security products, it should never be treated as a silver bullet.

When we were a less mature security team, our EDR solution played a large role in our endpoint detection technology stack, so we focused our initial attention there. As we ran through various initial access, execution, persistence, and defense evasion techniques, we were fairly satisfied with out-of-box detections around Windows endpoints. This was not a surprise given the attention Windows adversary behaviors have received via the influx of MITRE ATT&CK EDR evaluations. But unfortunately, we quickly learned that the same attention was lacking for macOS and Linux agents, and we were able to consistently complete objectives undetected, even with the noisiest techniques.

This wasn’t necessarily the fault of the vendor: We understand detection at scale is difficult due to environmental factors, and the last thing we’d want as a customer is to be overwhelmed by an influx of false-positive alerts. But as we continued with our purple team exercises, we found other gaps that affected our ability to respond and remediate.

We lacked expertise with the product and found it difficult to receive answers to simple questions like, “For this network connection, what is the parent process?” Other smaller assumptions were challenged when we learned Linux network connections were not being collected. This made the blue team blind to network activity when the red team pivoted to our workloads environment.

These findings only highlight the importance of developing a mature defense-in-depth strategy that must be built on a strong foundation of cyber hygiene. Defense-in-depth helps you build resilience into your company's ability to stop an attack even when some of your tooling fails to detect or respond to malicious activity. As long as you stop an attack before any real damage is done in the attack cycle, you have successfully mitigated the attack.

As our security team matured, it became evident our existing defense strategy no longer met the needs of the team. We needed:

  • More control over detections

  • Increased data retention

  • A threat-hunting platform with a convenient user interface and easy-to-use query language

So, we decided to look at alternative solutions. After an evaluation period, we landed on a defense strategy that worked well given the strengths of our team.

Phishing for SSO Session Cookies

SSO solutions are high-value targets for adversaries due to their obvious nature: They provide single sign-on access to a large number of applications users rely on daily.

A compromise of an SSO session means an attacker can impersonate that user and access the majority of the same services (excluding services requiring a VPN). This could be an HR app with personally identifiable information (PII), GitHub containing intellectual property, or a cloud provider with sensitive customer data.

We wanted to evaluate our ability to detect and respond to a phishing attack targeting our SSO provider. We simply didn’t know the answers to questions like:

  • Will our spam detection work and prevent phishing from landing in the inbox?

  • Can we identify phished users?

  • If a user is phished, how do we respond and eradicate the threat?

This was an engagement where we saw our blue team shine. The phish was quickly identified, causing them to spring into action to contain the threat. But like all our purple team exercises, assumptions were still challenged.

In particular, we learned about some unexpected behavior that limited our ability to identify phished users. When using the console of our network monitoring solution to determine who navigated to the phishing landing page, we received no results.

This was highly suspicious since the red team knew users clicked the link by viewing server logs. But where was this data? Our blue team reacted by pivoting to another source of information, our EDR, to see if any DNS requests were made to the phishing domain. This was a perfect example of defense-in-depth, as we found the data we were looking for within our new EDR solution.

We were surprised our network monitoring solution didn’t contain this data, so we reached out to them to learn more. After some back and forth, we were told the product was working as designed and had the following requirements for data to be logged:

  • Web traffic connection needs to have at least 12 HTTP transactions

  • Response for the HTTP request should be more than 3k in size

Since the interaction with our phishing server did not meet these requirements, it simply wasn’t tracked by our network monitoring tool. Thanks to our defense-in-depth strategy, this wasn’t a real problem for us since we had the data in our EDR. Nevertheless, it was an interesting find.

We also challenged some assumptions in terms of eradicating the threat. The blue team was quick to suspend the SSO accounts to prevent further compromise of SSO applications.

But what about the apps the attacker was able to access prior to the suspension? Were the sessions still active and valid?

We learned the answer was yes: If the attacker received a session of an SSO app prior to the suspension, they still have access to said service post-suspension. It is true that eventually the session will expire, but depending on the app that could be hours, which is typically sufficient for an attacker to find what they’re looking for.

Learn More

When it comes to purple teaming, there’s so much more we can discuss. We’ve really only scratched the surface here. The key things to remember if you’re considering purple teaming at your organization are:

  • Purple teaming unites red and blue team security goals

  • It can foster positive discussion and problem solving between offensive and defensive teams

  • It’s a great way to identify detection gaps and challenge your organization’s assumptions

Have we convinced you to ramp up a purple team program at your organization? If so, we highly recommend using the Purple Team Exercise Framework from Scythe. It’s a super detailed and invaluable resource when getting started.


Where can I learn about common IT security mistakes (and how to fix them)?

How important is endpoint security in this day and age?

What is the future of IT Operations?

Automox for Easy IT Operations

Automox is the cloud-native IT operations platform for modern organizations. It makes it easy to keep every endpoint automatically configured, patched, and secured – anywhere in the world. With the push of a button, IT admins can fix critical vulnerabilities faster, slash cost and complexity, and win back hours in their day.

Demo Automox and join thousands of companies transforming IT operations into a strategic business driver.

Dive deeper into this topic

loading...