Phases Of A Red Team Assessment - Revisited

Back in 2014, a question from a reader asked about the different phases of a Red Team assessment / engagement. Then we listed 8 phases.
These phases were, of course, based on our own experience, and a generic list. Each engagement is different, however having a list to begin the process and have a good visual map of what is needed, is a good thing.
During the last couple of years, we narrowed the phases down to 5:

Phase 1: OPORD

The Operations Order (OPORD). An OPORD describes the project, the situation the team faces, the target, and what supporting activities the team will have to achieve their objective.
In this phase, the team gets exposed to the upcoming project or operation. The initial information about the target and the scope of the assessment are dumped and the team members begin to prepare the tools and techniques based on the information they have. The team begins to study the target and formulate the initial plan.

Phase 2: Recon

This phase is the most important one. If you do it right it will most likely end in the success of the project. If done right, a good team can ID the targets quickly, modify the plan accordingly, adapt the tools and finish the project.
During this phase the team observes the target and learns about it. Physical and digital surveillance are performed, as well an open source intelligence gathering. The physical, digital and social footprints of the target are mapped and analyzed. At the end of this phase there is a clear view of the possible vectors of attack. Usually, during this phase, all activities are passive, however in some cases - and the target is open to attack - a more active scan/surveillance is performed.

Phase 3: Target ID

During the Recon Phase, the team identified the possibles options for an attack. In this phase each option is further analyized and a plan of attack is crafted. On the digital side, a deeper scan is performed and exploits are identified. On the physical side, more information about security measures and controls are sought out. Social engineering calls are made and phishing mails are sent. Dry runs, if any, are performed during this phase too. In many cases, custom tools are written to exploit a specific vulnerability or to provide support for penetration and data exfiltration. This is a more active phase.

Phase 4: Live Run

Phase 4 is the Go! phase. Armed with all the knowledge and tools, the team executes the assessment for real. Whether a digital intrusion or a physical infil, the team tries to go inside. Once in, the team begins the lateral movement and smaller Phase 2 and 3 happen again. Important targets are indentified within the primary target and these are exploited as well. Backdoors, and further persistance are set and data exfil channels are open.
Once the team in inside, the team tries to exfiltrate data and also exploit targets of oportunity. Once all this is done, the point of contact that set the assessment is notified.

Phase 5: Report

The assessment is over. This phase is used to clean anything left behind and analyze all that was done. Findings are reported to the point of contact, and a debrief meeting is set.
The final report writing begins. This is the sucky part. Report writing happens after the endless cries from the point of contact.

The Red Teamer's Bookshelf 2017 edition

It’s been a couple of months since we first announced that Red Team Journal,, and OODA Loop would be compiling the latest “Red Teamer’s Bookshelf” jointly. For those of you who’ve been waiting, the list is finally here. It’s larger than previous years, so we’ve organized the titles by category (and yes, some of these titles would fit in more than one category). The titles address a range of red teaming activities and skills, with a noticeable increase in special operations books this year. Thank you to everyone who submitted titles.

Here's the list.

Focusing on the goal

I've experienced plans going wrong many times during the several years I've been Red Teaming. Sometimes because of poor planning, some others because the real world always has the last word, especially when Mr. Murphy is along for the ride - and he always is.

Over the years both experience and mental resilience had taught me to assess the situation and adapt the original plan, go to a plan B or just work without a plan. While on the field, ideally you’d be looping through 4 steps constantly:

  1. Understand the problem (in this case what caused the plan to not work)
  2. See the solution (how do I solve this in a simple, fast and reliable way)
  3. Communicate the new plan (to your team or to you, mentally saying the plan helps red team the issues)
  4. Execute it

However, while doing this you have to keep in mind the goal of the mission, assessment or engagement. It is very easy to lose focus of the goal. An instructor at one of the schools I attended while on the military, always told us to focus on the end goal, no matter how bad it was. Mission came first and if the mission was to recon a target and gather intel then that should be the focus. All our planning was geared towards achieving that mission. Once we had that, then the rest (kit, transport, alternative exfil points, etc) would cascade from there. Remember: Rule 16: Target dictates the weapon and the weapon dictates the movement. The goal comes first. The what you are planning for.
It is very easy to lose focus of this when the conditions on the field are chaotic, or not as expected. We tend to focus on the things on front of you, and while these are often pressing and more important (sometimes life or death), once we solve the immediate problem, we need to go back to the original mission.

The best way I found to do this is adding the following to the steps described above: 0. What is the goal.

So, identify the goal, identify the problems preventing you from achieving the mission, find a solution (don’t forget: the solution is in the problem), communicate that solution and execute it. If it didn’t work, or a new problem arises, start again, but always keeping the question what is the goal as the first step. This will keep you focused on your mission.

Offensive security? Yes.

Some people don’t see the benefits of Red Teaming until you show them. Offensive security is not something organization are often willing to undertake, but sometimes is the only way to really find who is after them.
This was the case for one of our customers. We run a Red Team engagement for 3 months, we showed them what their competition and other adversaries can do to get to their IP (Intellectual Property) and, while doing so, we uncover signs of an ongoing exfil of data.

Once we presented the findings, including the possibility of the bad guys already inside and extracting information, their CTO asked us if we could help their security department find out what/when/how/who. After some discussions with the CTO and the CSO, we mentioned the need for offensive security, or as they put it, to hack back. Well, I hate that term hack back. Offensive security is not that, but good luck trying to explain this to execs that don’t really understand security on the field. We tried to walk them through the many possibilities of offensive security, we tried to explain that there’s nothing wrong with trying to go after the people already inside their network in a more pro-active way. They brought the legal department… Things got more complex..

After about a week of discussions, where all the while, the attackers might have still managed to exfil information, even when we told them what to block (if these were good attackers,they would have contingency routes and access, so I was still convinced they were active), we went nowhere. On the out, their CSO grabbed me and told me that he would arrange for us to come on-site, covertly as he called it, and do our thing from within. The idea was that he would bring us is as a group of contractors working on a network issue, and while we were there we should investigate and attack back (again, his words). We were happy to oblige.

It took 10 days, but we figured out a pattern. The bad guys were good and were covering their tracks (we discovered some IP addresses, but they were just not their real ones), but they were after a specific kind of data. So, we set a trap. We set a bunch of weaponized Office documents, along with some fake developer environment systems that had some extra monitoring in place. These systems also had a particularly vulnerable version of Apache and PHP, making it an attractive target for lateral movement for the attackers.
Meanwhile, in our office, we had a bunch of listeners to see if any of the weaponized documents managed to drop our attack code and get us a way in.
While we discussed the findings with the CSO and his VP of security, we agreed to temporarily pull the real data the adversaries were going after and slowly replace it with fake data and some watermarks. This way we could also track that data if it would appear on some competitor’s site, or news site, etc.

Anyway, 3 days later, we had a ping. One of our listeners emailed us. We had a shell. A day later 2 more. At the end of the week we had all of them pinging home.

Now we needed to move fast. While I did the recon on where we were and possibly who they were, JD try to get some redundancy (extra ways in, just in case) and uploaded some really nasty code to bring the buys down if we needed it. I uploaded our digital drone and set it up to discovery mode. In this mode, the drone only maps the network and reports back any targets of interest, such as DBs, web servers, domain controllers, network devices, email servers, etc. It’s really fast and surprisingly nimble and quiet. Hard to detect unless you know what you look for.
Within the hour we already had an idea that this was a simple setup, it seemed like a bunch of laptops (based on their MAC addresses) connected by a wireless router. We had also a possible real IP and geolocation of the bad guys. Z run a bunch of searches on this IP and locale and we compiled a brief of all we knew for the CSO.
In the meantime, some of the fake information we dispersed began to appear in a forum in Asia and on some download sites. While these are hard to crack to get who the users uploading the info were, it was an indication that these people were after just money, not really the damaging of our customers. So, we added that to the brief.

With all this information, the CSO briefed the legal department and they decided to get the law enforcement involved. However, they asked us to bring this guys down and help reconstruct what happened to help the forensics team sent by the LE.

So, we did.

Mandatory Books

A while back a reader asked me for a list of MUST READ books. While I was compiling a list from our bookshelf, it occurred to me that, a lot of the guys in the Team haven’t read some of these books. So, after talking to them, I decided to make them mandatory reads.

Here’s the list: