This section is just to document some of my feelings on organizing a red team. Overall, I don’t know if there are wrong ways to organize a team, but here is just some ideas and thoughts.
1. Do a brief round of introductions and specialties and background; newbies are welcomed to say they’re newbies. This gets everyone’s name out there, breaks the ice for the shy ones, and helps everyone know who to ask for specific expertise. This can also let everyone know who the person in charge is, i.e. whom you ask for direction or information if needed, such as where to set up and how to connect. This person will need to repeat much of this for any latecomers.
2. Assign people tasks, rather than targets. App specialists tend to skip obvious network holes and can get distracted by app holes in various teams. It is best to keep people doing what they’d rather be doing, and giving all teams a more equalized enemy. Newbies can get pretty good with scanning as they go, but a newbie assigned a team may give that team far less successful attacks with which to evaluate their defenses.
3. Make root the goal. Sure, DoS and service interruptions from a Nessus scan, and web defacements are fun, but really make root and total ownage the end goal. Create persistent backdoors and get inside. Even a team that thinks it was up most of the event may have been completely owned and leaking valuable information to outsiders.
4. I would consider DoS a valid attack in a competition where uptime is a scoring criteria, but only insofar as configuration errors make the DoS attacks possible. In other words, preventable from a practical standpoint. Nonetheless, DoS shouldn’t be used constantly, and only to illustrate the vulnerability and drive home the point with some downtime and points loss. After the point is made, ease up and let the teams and attackers get more out of the experience. (Imagine your team is being DoSed and you don’t really know how to fix it…and it lasts the whole competition…that sucks pretty hard for just not knowing maybe the one config change to fix it.)
5. Don’t overlook the obvious deficiencies. They may not lead to root, but noting things like a lack of SSL on logins or an MS Exchange server hanging out in the winds of the public net can be important notes to make when evaluating team performances. They’d be dings on professional evaluations, so may as well ding them here as well.