Choose Your Own (Pwn) Red Team Adventure by Matt Kiely
A fun table-top role playing game for red team professionals. Experience 0-99.
Have you read the book series, GooseBumps? Or played, Dungeons and Dragons? Or watched, Black Mirror: Bandersnatch on Netflix?
Each of these media (collectively refers to a book, a game, a movie and an article or a blog) features an interactive style narrative where the user (collectively refers to a reader, a player and a viewer), must make a choice to advance the narrative.
Recently, I came across another such media, focusing on red team engagements (read about the previous one here).
Choose Your Own (Pwn) Red Team Adventure by Matt Kiely
It is a series of posts, written by Matt Kiely, in which he takes the reader on the journey of a fictional red team engagement. The end of each post requires the reader to make a choice as they would in a real-world red team engagement. I found it to be a good thought exercise. Do try it out.
Red Team Notes
- Choose Your Own (Pwn) Red Team Adventure by Matt Kiely is a table-top role playing game depicting the narrative of a fictional red team engagment.
- A good thought exercise for red team professionals with experience 0-99.
Follow my journey of 100 Days of Red Team on WhatsApp or Discord.
If you decide to play it, please share your notes and thoughts in comments. I am sharing unfiltered and unedited notes from my game play below.
DO NOT READ FURTHER WITHOUT PLAYING THE ADVENTURE
SPOILERS AHEAD
Game Play 1
Rationale for selecting this choice:
Given that I am new on the team and I am not the red team lead, it would make sense to approach the lead for the engagement and work with them to understand the scope and rules of engagement better.
Rationale for not selecting other choices:
The rules of engagement do not provide much clarity on scope, restricted actions, out of scope items etc. Jumping right in does not seem to be a viable option.
I definitely need more clarity on scope but better to get an opinion on the same.
Outcome:
The red team lead is supportive of the idea. She has asked me to take a call on this matter and lead this discussion with the client, if I plan to go ahead with this idea.
Rationale for selecting this choice:
A little more time spent in clarifying the scope might help us avoid hours or days spent chasing wrong rabbit holes, later in the engagement.
Rationale for not selecting other choices:
I know we have a short window for the engagement but I think getting more clarity will help the team avoid any pitfalls during the engagement. It is possible that we don't come out any wiser from that discussion but at least we'll be able to justify further actions as we did all we could to get more clarity.
Outcome:
So now, we a have slightly more clarified scope that includes out-of-scope items. However, I still feel that it needs more details such as restricted actions (e.g. are we allowed to phish a senior executive?), escalation of forces (i.e. which activities will need a prior approval), legal disclaimers and indemnification clauses etc. At the same time, I am also feeling time conscious as we have a short window to conduct the engagement and we don't want to spend better part of it fixing the scope (even though it can be better). I think I'll go ahead with one more round of discussion and then call it a day.
Rationale for selecting this choice:
Without an airtight scope and properly drafted rules of engagement document there is always a risk of the red team not being able to meet the objective. I think we should go for one more round of discussion with the client before beginning our ops.
Rationale for not selecting other choices:
I know we have a short window for the engagement but I think getting more clarity will help the team avoid any pitfalls during the engagement. It is possible that we don't come out any wiser from that discussion but at least we'll be able to justify further actions as we did all we could to get more clarity.
Outcome:
We were able to add more details to the scope and rules of engagement. It seems that the team is comfortable with the scope now. Let's move ahead.
So, we have identified three applications to target. Time to make a choice again.
Choice 4 - Enumerate the File Browser site and attempt a careful admin password brute force.
Rationale for selecting this choice:
The File Browser seems like a juicy target. Let's go ahead with it.
Rationale for not selecting other choices:
Any instance of Apache Spark is out of scope so not going to target that.
A default instance of WordPress seems like a good target. Maybe someone was trying to setup a WordPress site but then moved on to some other project and forgot about it. It is also possible that this could be decoy.
Outcome:
We brute force the application login and are able to obtain a working set of credentials.
The application has an in-built shell but it is not letting me execute any command. Also, since the communication is over HTTP, it is possible that any activity we perform here is getting monitored. Need to switch to a secure communication channel. Maybe upload a web-shell and then use it to establish an SSH connection?
Ok. Turns out there was a feature to enable basic commands. I enabled that, continued enumeration, eventually identifying an attack path for privilege escalation via SSH. Need to extract the private SSH key for the user. Time to make another choice.
Choice 5 - Extract the SSH key by using the web shell and log into the server via SSH.
Rationale for selecting this choice:
I can write and deploy a simple custom web shell (to avoid signature based detection) to extract the SSH key. I can probably encode or encrypt the SSH key before extraction to avoid further detection. Since we are communicating over HTTP there is a risk that all of this might get detected.
Rationale for not selecting other choices:
Deploying a Sliver agent seems like more of a overhead for this. It will provide a more secure communication channel but the agent itself might get detected via network based security solutions while being downloaded. Also, since we are running inside a container, it may not have required dependencies for the agent to work.
Outcome:
Ok. I personally would have definitely not extracted the key as described in the scenario. The operator used the shell access they already had instead of deploying a web shell. I would have used my method as described above but I made a choice so got to live with it.
That didn't end well for the operator and it led to GAME OVER.
Alternate Choice 5 - Inject a Sliver agent into the container and set up an mTLS channel to extract the SSH key.
Rationale for selecting this choice:
The web shell method didn't work out. So let's go with this.
Outcome:
Requires to setup a re-director which seems logical. With C2 infra all setup lets move ahead.
Seems like we were able to establish an SSH session on the DMZ server with root access and everybody is happy about it. Let's move on.
Upon further enumeration of the host, we identified a folder with possibly sensitive contents. What to do with it?
Rationale for selecting this choice:
This seems like the most responsible and logical choice to make. The folder could be a decoy as well. Even if it is, going via this route is a responsible choice and the client might appreciate it.
Rationale for not selecting other choices:
Plausible deniability is not applicable in case of irresponsible conduct. Besides, neither the folder nor the data within were mentioned in the scope, so 'Get out of jail' card won't be applicable here.
Only an attacker may consider downloading the stolen data. We are not the attackers.
Outcome:
The client has been informed and they are investigating it. The engagement has been considered as COMPLETE & SATISFACTORY.
It's time to debrief.
Closing thoughts
I enjoyed playing this choose your own adventure. There were lots of twists and turns and some hard choices to make.
I liked how choices are laid out. They help demonstrate that a step missed early in the engagement can lead to a disastrous and failed engagement.
The scenarios also help in understanding that a red team engagement is objective-oriented and not about finding all vulnerabilities in the environment. For example, in my game play I was able to successfully complete the engagement (after losing 1 life) without exploring another valid attack path.
It also helps in etching the importance of being a responsible red team professional. Throughout this adventure, there are choices that you will test your integrity and ethics.
Follow my journey of 100 Days of Red Team on WhatsApp or Discord.