Common Red Team Techniques vs Blue Team Controls Infographic

Despite the large investment many companies have made in detective controls, it’s still pretty common for us to take over an entire network during a penetration test or red team engagement, and never trigger a single response ticket. Naturally this has generated some concern at the CSO level as to whether or not a real breach would be detected.

Testing the effectiveness of detective and preventative controls can be a challenge. However, the process can be a lot easier if common attack workflows are understood, and broken into manageable pieces. In this blog, I’ll share an eyechart an infographic that illustrates some common red team attack workflows and blue team controls to help get you started.

Disclaimer: Unfortunately, it’s a pain to get lots of information into one diagram. So it only represents common phishing attacks workflows and should not be considered complete or comprehensive. The tools, techniques, and procedures used by attackers are constantly evolving and changing so there is just not enough room on the page to fit it all in.

Hopefully the information will be interesting to security teams in the process of building out and testing their preventative and detective capabilities.

Infographic Download

You can download the infographic here. And learn more about NetSPI’s red team security services here.

Also, below are some general tips for red and blue teams who are just getting their feet wet. They’ve helped me out a lot in the past.

General Red Team Tips

Below are a few general tips for avoiding detection during red team engagements.

1. Do not perform large scanning operations.
2. Do not perform online dictionary attacks.
3. Do perform recon locally and on the network.
4. Do perform targeted attacks based on recon data.
5. Do not use common attack tools. Especially on disk.
6. Do try to stay off disk when possible.
7. Do try to operate as a normal user or application.
8. Do try to use native technologies to access the environment remotely without a C2. If C2 is required the use of beaconing, tunneling, and side channels typically goes undetected.
9. Do not change major configuration states.
10. Do not create accounts.

General Blue Team Detective Control Tips

Below are a few general tips for detecting unskilled attackers.

1. Define clear detective control boundaries.
   It may be cliché, but detection in depth is as important as defense in depth these days. Make sure to have a good understanding of all the layers your environments and define clear detective control boundaries. This should include, but is not limited to networks, endpoints, applications, and databases. Also, don’t neglect your internal processes and intelligence feeds. They can be handy when trying to evaluate context and risk.
2. Map out your data and logging sources for each layer of the environment.
   You may have information that can be used to detect IoAs and IoCs that you were unaware of. Having a solid understanding of what information is available will allow you to be a more adaptive blue team.
3. Find solutions based on value not price.
   There are lots of preventative and detective control products out there. Most of the mature options are commercial, but the open source options are getting better. Also, don’t be afraid to get a little dirty and write some of your own tools. Naturally this can include things like HIDS, HIPS, NIDS, NIPS, SIEM, DLP, honeypots, tarpits, and canaries. I’m personally a big fan of canaries – they are cheap and can be really effective.
4. Be creative.
   For example, many endpoint protection suites can detect common scanning activity on the LAN in the absence of internal net flow data.
5. Audit for high impact security events. Make sure you have coverage for the most common IoC and IoAs at each layer of your environment. This one seems obvious, but a lot of companies miss common high impact events.
6. Work with your red team to test controls.
   In my experience, you get the most value out of red team engagements when the red and blue teams work together to understand attacks in depth. That collaboration generally leads to better preventative and detective controls.While performing offensive actions against implemented controls consider asking the following basic questions to help ensure ongoing improvement:
   1. Were any security events logged for the attack? (Where, Why/Why not?)
   2. Did the security events trigger alerts? (Where, Why/Why not?)
   3. Did the security events trigger an incident response ticket? (Where, Why/Why not?)

Conclusion

Go purple team! Naturally, every red team engagement has different goals and collaborating with the blue team isn’t always going to align with them. However, if one of your goals is to test the effectiveness the technical detective controls in place, then working together will yield much better results than doing everything in a silo. Hopefully this was helpful. Have fun and hack responsibly!