Choose your own red team adventure by Tim MalcomVetter
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 one such media, focusing on red team engagements.
Choose your own red team adventure by Tim MalcomVetter
It is a series of posts, written by Tim MalcomVetter, 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 and Tim has shared a lot of insights from Defender’s perspective as well. Do try it out.
Red Team Notes
- Choose your own red team adventure by Tim MalcomVetter is a table-top role playing game depicting the narrative of a fictional red team engagment.
- Offers a 360 degree view of the engagement as the write-ups include a post-analysis section where the author has explained the narrative from Blue team's perspective.
- 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
Choice 1 - Figure out what's running on this host
It will be unwise to run Mimikatz on the host without knowing what monitoring tools are running. It might trigger alarms and stop the engagement then and there.
In order to figure out where I am, it will require certain enumeration tools to be executed on the host. I wouldn't want to do that until I know what monitoring tools are running on this host. For example, if I run a PowerShell based enumeration script and AMSI is enabled, it may send an alert to the SOC team. I will need to figure out which type of OS the host is using, that can also be done by seeing what's running on this host.
I am already on the host machine, won't need the password right away. If needed, this step can be performed once I know what's running on the system and where I am.
"You didn’t stop to figure out where your phish payload landed" - this line on this page seems ominous. Maybe I chose wrong, we'll see.
"You see an outdated anti-virus product and nothing else running. The operating system is old, lacking many of the new security controls." - I would have paused here, as this is too good to be true. This system is most likely a decoy / deception to trap attackers.
The author didn't mention if the system was a decoy but it led to GAME OVER with FBI knocking on the door. Bad choice. Let's start over.
Game Play 2
Choice 1 - Figure out where I am
It will be unwise to run Mimikatz on the host without knowing what monitoring tools are running. It might trigger alarms and stop the engagement then and there. Before that, let's try and figure out where I am.
Based on game play 1 it will be unwise to figure out what's running on this host without first knowing where I am. Will this also lead to game over? We'll see.
I am already on the host machine, won't need the password right away. If needed, this step can be performed once I know what's running on the system and where I am.
So not game over this time. Need to figure out how do I make myself aware of where I am. Time to make another choice.
Choice 2 - Watch the egress IP address
I wouldn't want to run standard OS recon commands as they are easy to catch and will be a dead give away.
Execution guardrails seems like a good idea but I am assuming that I don't know what type of OS I am dealing with.
I am not sure if watching egress IP will help. May be I can grab some banners from Shodan to identify which services are running and the type of OS. I am little hopeful about this as most enterprise hosts are behind NAT, so even if I do get some information that might not be relevant for this particular host.
"You are a careful and considerate Red Teamer" - This line gives me hope. I hope it isn't sarcastic.
Ok. So I was right, in the sense that I could gather some information via this technique just not the way I thought.
I have identified the egress IP addresses and configured my C2 to respond only to them. Now, I need to figure out what's running on the host. Time to make another choice.
Choice 3 - Use the Windows API
I wouldn't want to run standard OS recon commands as they are easy to catch and will be a dead give away.
Running VBA macros is dangerous as well and not that straightforward anymore, specially with recent changes implemented by Microsoft.
I'd rather rely on using Windows API for host recon.
So this choice lead to GAME OVER. Not sure what get caught.
Ok, I forgot that I have a callback that's coming from the phish payload. I might already be leveraging VBA, so option 2 would have made sense.
Also, the client organization seems to have a robust blue team.
Alternate Choice 3 - Review running processes from VBA in the macro
I wouldn't want to run standard OS recon commands as they are easy to catch and will be a dead give away.
Since I am already operating in the context of phishing payload, it is likely that that payload was using VBA macros. It might make sense to gather this information via VBA.
Already got burnt by using Windows API.
The author chose to go with another phishing payload, containing the VBA macro. I can see the logic behind it but I am not sure if landing another phish, post initial access, is a good idea. It increases the risk of detection. Lets see where this lands me.
SUCCESS. The red team was able to achieve their objective. So it's game over but in good sense.
Follow my journey of 100 Days of Red Team on WhatsApp or Discord.