This blog post explores how the Phantom Platform can be used for red team automation use cases.
DerbyCon is by far my favorite security conference each year. The quality of the talks, the amazing variety of challenges to try your hand at, and the family-friendly community atmosphere all combine to form a very special event. Upon arrival at last year’s iteration of DerbyCon, I scanned the program for interesting talks that I wanted to attend live. Working for Phantom, and being a believer in the value of automation for security operations, I was immediately intrigued by a session title that claimed the author almost automated himself out of a job. You can view the recording
The project is very impressive work by the author Marcello Salvati. Basically, Salvati wrote Python code that leveraged the REST API of Empire to perform reconnaissance, lateral movement, and credential harvesting until he was able to get Domain Admin privileges within an Active Directory environment.
While listening to the author explain his work, I realized that porting the DeathStar project over to Phantom would be a great way to demonstrate the Phantom platform’s versatility. So, I wrote an Empire App for Phantom, which is now published and generally available to the Phantom Community. Now with this blog post, I’m releasing a series of playbooks that perform portions of what the DeathStar project does.
In order to use these playbooks, you will need an Empire server with REST listener setup and at least one active Empire agent. You will also need a Phantom instance with the Empire server configured as an asset. For more information on setting up Empire and Phantom, be sure to check out the resources section at the end of this post.
The first playbook, DeathStar_Setup, will ensure there is a listener on the Empire server to communicate with the compromised endpoints. It then sets up custom lists within Phantom to support the playbooks.
The second playbook, DeathStar_Polling is designed to run every 2-5 minutes to check for new agents that have connected to the Empire server. When it detects a new agent connection, it checks to see if the goal of Domain Admin credentials has been achieved.
DeathStar_Polling will either call the DeathStar_Recon playbook to gather information about the domain or the DeathStar_Spread playbook to start the lateral movement.
What I found most interesting about the effort is that it extends Phantom’s utility to red team use cases. Phantom is commonly deployed for incident response use cases, at which it naturally excels. Having worked with the platform daily for over a year now, though, I always enjoy the chance to show just how versatile it is.
While my example playbooks replicate part of the functionality of what the DeathStar project provides, they are great examples of how to use Phantom to build an automated penetration testing workflow. Yet, this is only one example of how Phantom can modularize the various security tasks and workflows performed across the gambit of security operations.
Investing the time to build out Phantom functionality on the red team side will yield even more benefits to a blue team already using Phantom. Let’s say the blue team wanted to perform control effectiveness testing or determine if they are detecting a particular attack. Often they would have to hire an external pentester or an internal technical resource to perform the simulated attack and evaluate their controls. With Phantom, the simulated attack could be built into a playbook once and then run repeatedly on a schedule or on-demand. This would save time for the red team, reduce the barriers to testing for the blue team, and be an overall win for security effectiveness. It lends an additional layer of suitability to Phantom’s signature aubergine color scheme when it brings the red and blue teams together to make purple, driving security effectiveness to the next level in the process.
Feel free to download the DeathStar playbooks, examine them, experiment with them or modify them to use in your own environment.
Connect with Tim on LinkedIn to continue the discussion.