Chapter 6. Red Teaming

We have come to the final chapter, dear readers. Maybe this is a misnomer, but in the context of the book, it kind of makes sense. Ordinarily, red teaming refers to a holistic approach to testing. It's debated whether this is the best, worst, or just another form of testing. I'm using it as a term for bringing together all the earlier types of testing that I've covered.

This last chunky portion will cover two full implementations of the stuff I've told you so far, so you can copy, I mean, learn from them and design your own challenges. I will cover sections from each of the earlier chapters and show them in a working environment. I will also present some alternative ideas, suggest further opportunities, and cry a bit at the end when I've finally finished. In this chapter, we will cover the following in detail:

• Scoring systems

• Setting the scenario

• Reporting examples

• Variations for assault courses

• The missile silo scenario

• The vulnerability assessment scenario

Chapter guide

This chapter is much longer than the previous chapters, and is therefore split into smaller chunks. The chunks are made up of the following:

• A rough approach and guidelines to creating test environments: The aim here is to create a single laptop or piece of infrastructure capable of hosting the full attack range.

• A scenario focused on chain-of-attack education: The idea here is to create a range that forces the attack to pivot multiple times to achieve their goal. Expect cunning uses of IPtables and the like. We will be creating an example, and I'll be providing examples of various exploits to be hosted as we go along. I don't want to just give you one solution and say, "that's how it's done," because there are very few things you can actually do that with.

• A scenario based on a standard penetration test: The idea here is to host a number of different systems with varying degrees of vulnerability. The aim is to allow the tutor or pen-tester-in-charge to have options for how...

Scoring systems

There are multiple approaches that can be taken to scoring. The intention in all scoring systems should be to encourage good behavior for real-life engagements. Emphasis should be put on accuracy, completion, reporting, and breadth of knowledge. Yes, being 1337 is important, and smashing everything tooth and nail is admirable, but that's not the point of the exercise. If you're already into bending systems over your knee, perhaps you should seek a greater challenge (or take on a new skillset; teach yourself malware development, and go work for some shady people—they pay better anyway). So, here are some suggestions for scoring methods:

• Fixed point exploits: This is super simple. There are x number of exploits out there in the network. y of them are pretty simple, so they are worth 10 points. z of them are moderate, so they are worth 20 points. The last one is impossible, so it's worth 100 points. This kind of arrangement is good for someone to quickly judge the breadth and...

Setting scenarios

As shown in the section mentioning variations , it's important to engage your audience. Of course, you can say, "something's vulnerable and there's a flag somewhere; go nuts," but that doesn't represent a proper test or real-life scenario. Let's get them into good habits early. The idea is to provide the testers with a brief that fits the kind you would expect to receive for a test. So, the following should be covered as a minimum:

• Scenario: This can be as basic (this is a standard internal infrastructure test) or as far-fetched (you're testing Artemis missile command) as you like. The important thing is to give context to the actions that the users will undertake. You can also then use this to provide flavor to the servers you set up, naming conventions, red herring content, and so on. Ultimately, you need to frame the exercise so that it's relatable for the users.

• End goal: Again, this can be stupidly simple or very complicated. I've seen enumerate and report all the...

Reporting

As mentioned in the scoring systems and scene setting, reporting requirements are strongly recommended for these challenges. Reporting is necessary for most tests, and it's good practice to keep testers in the habit of noting and reporting all that they do. If not to present to the client, then to present to the police when they eventually come knocking. Now I realize that a lot of organizations don't have standard reporting practices (or if they do, they don't stick to them), so I thought I'd provide a basic example that can be matched against.

Reporting example

The following report template is a generic setup that is split into three sections: summary, risk, and mitigation. Read the example through, and check the descriptions of each in the following sections.

Summary

Five servers operate one or more of the following dated software packages, which have known vulnerabilities:

• OpenSSH (version 3.0.2p1)

• Apache (version 6.020)

Multiple servers were found to be operating Windows while...

CTF-style variations

The exercises presented in this chapter are very basic, straightforward examples that are designed for people already intending to get involved in penetration testing or are perhaps already practicing the craft. They will target the majority of users in the middleweight category with some skills but not excessive pwnage. In order to attract the skilled practitioners and new blood out there, you will need to mix it up a little. Poor pen testers will shrug off a simple faux pen test, and those without testing experience are likely to be intimidated by the required skill and toolset. The following options are some ideas on how to vary the course to attract the intended audience.

DEFCON game

While at London Bsides 2014, I was lucky enough to see Joseph Greenwood's presentation on a Capture the Flag event that he ran at his university incorporating elements of the game DEFCON. He set up a situation that mimicked a nuclear weapons' command that also invoked elements of hacking...

Scenario 1 – ladders, why did it have to be ladders?

For this scenario, we will construct a penetration test environment that relies quite heavily on pivoting. We will also use this scenario to try out some more inventive methods of setting scenes and will provide an interesting brief. I will reuse vulnerabilities from earlier in the book, but these environments can be set up with any vulnerabilities of your choosing.

The structure of the scenario is broken down into the following:

• Network diagram

• Brief

• Setup

• Exploitation guide

• Variations

• Summary

Network diagram

As you can see, the setup for the network diagram is fairly simple, as shown in the following diagram:

We start with a host called DMZ that is hosting a hidden wireless network. This is the breach that we will refer to in our brief. The DMZ host is also housing a telnet solution (from Chapter 2, Linux Environments) and a legitimate SSH server. Within the server itself, a set of obfuscated credentials for both DMZ and missileman are stored...

Scenario 2 – that's no network, it's a space station

For this scenario, we will construct a penetration test environment that simulates a standard testing environment. It'll be a fairly simple setup with no pivoting required. I will refer to this one as the reporting range because realistically that's the best purpose for this setup. In order to gauge the reporting ability of your staff, run them though a similar setup and see what comes back.

The structure of the scenario, which is similar to the previous one, is broken down into the following:

• Network diagram

• Brief

• Setup

• Exploitation guide

• Variations

Network diagram

This scenario can feature as many or as few systems as you like. I'm going to use five to create a representative environment without taking up a ridiculous amount of space. Have a look at the following diagram:

Before going into depth on the creation and organization of the VMs, I'm going to share some observations about small networks.

First, on a small internal network, the systems...

Summary

In this chapter, we have covered how to create full tests and gone through two full-scale deployments. We've gone through some different ideas on how to present tests and make them a bit more challenging and generally faffed around in the world of VMs. I hope it has been interesting and challenging.

At this point, I would normally say what's coming in the next chapter, but this is the last chapter. What comes next is a small closing statement, some recommendations for further reading, and a number of CTF recommendations that you should try out. Following that is a bunch of legal stuff that no one reads. It has a lot of interesting numbers though, such as ISBN and the like. You should read it if you like that kind of thing. I didn't write it though, so don't expect any joke or anything. I'm not an accountant, I can't do funny things with numbers (ho ho ho!).

This is the end of the five months it's taken me to write this book. In that time, I grew a beard and shaved it off, visited four...