The First Task When Entering The Prelude Security Team

As the new recruit of the security team, I was initially tasked with hacking our fearless CTO David. David keeps himself mostly private and he knew my task this week so I suspected and rightfully so, this would be an uphill battle and I had limited time to pull something together. Going into this, I had available to me any open source tools I wanted to use with the caveat that I would integrate techniques used into the Operator platform later on. It was very important to me as I did this engagement that any tools that I had developed would make it to Operator at some point.  

I don’t personally consider myself as someone who does things like penetration testing. David recently wrote a blog post (Dichotomy of Buttons) that described the difference between button clickers vs. button makers and I’m certainly within the button maker crowd. While I’ve used a fair amount of offensive security tools within the open source and certainly understand the overarching process; my pentesting engagement experience is severely limited. My offensive security background dives more within reverse engineering, malware analysis, application security, and writing post exploitation capabilities. As I attempted to go after David, I also saw this as a great opportunity to discover some holes in my own technical knowledge set and fill those gaps over time. 

Open Source Intelligence (OSINT)

So let's get the previous knowledge of David out of the way.

  • I know David uses a variety of different operating systems but this week he chose to use the Arch based Linux distro Manjaro...basically hard mode (Noticed during a meeting we had)

  • He has two emails at Prelude (maybe one is used for something like automated emails?)

  • I know he previously worked at MITRE (This is important because if you just search David Hunt you're going to get the actor but MITRE shows a decent bit of stuff David has done in the past. Good thing his parents didn't name him Ethan or this would be Mission Impossible)  

  • Twitter Handle is @privateducky

  • David’s LinkedIn (His page is open for anyone to see location, experience, education, recent activity, and about. This will become important later)

All the weekend capture the flag competitions with some crazy obscure challenges have made me a decent Googler over time. Challenges that come to mind are a couple of Eric Liang challenges during CSAW and challenges during DEFCON_CTF where you needed to learn obscure emulators or architectures. I take pride in myself having some pretty decent Googling skills. It has certainly gotten me out of jams in the past.

At least within the US, things like real estate transactions and voter registrations are public record and personally identifiable information sites have popped up over the years making finding people much easier. Usually as long as you know the name of the individual you're looking for and their current general location you can find them. In this case, I knew David’s name, of course, and through his LinkedIn I knew his general location. So with this information I went hunting.

What I discovered:

  • David’s current address which I could then pull up on Redfin/Zillow where I found detailed pictures of his house, layout, and how much it was purchased for.

  • His parents house plus their names/ages

  • Potential Relatives and their information 

  • Potential Previous Addresses

  • A potential email and a likely web hosting site he used

  • Potential phone numbers (which I all deemed were wrong)

  • His age and month of birth

  • I could look up his neighbors and all their information

  • His wife’s name, working cell number, maiden name, age and month of birth, email, previous addresses, LinkedIn, her parents names/ages/location/emails/possible occupation

I think I found enough. So I decided to change gears a bit and go through all of David’s Twitter.

What I discovered:

Essentially, if desired, I could build out a detailed information map of David’s information and all known associates to either gather more information, blackmail, scam, or try to get initial access. In this scenario, I did none of that although, looking back, I should have at least ordered pizza or something to David’s house. 

I could have definitely dug into OSINT some more but suffice to say, I think I covered this.

The Plan...

At some point you just have to bite the bullet and start formulating a plan of what you might do to get access. As with all plans, sometimes they work out and sometimes they don't. 

So knowing the information that I have gathered, my plan was to send David an email using a slightly off domain of misformalware.com letting David know that this new coloring book was available and that he should download it, attach a Rust based payload to the freely available coloring book pdf, and have it communicate using one of my favorite lite open source C2 platforms MerlinC2

Executing The Plan   

So first I needed a way to send a phishing email with an attachment. While I could have just used a regular old email client and built a template I wanted whatever I did to be able to be ported and potentially expanded on within Operator at a later date. So instead, I broke out the trusty development editor and went to work. What I wanted to build was a way to send emails using SMTP while also having the ability to write, store, and send email templates and attachments. For the people that know me, I have a huge love for both Rust and Go. I intend for most of my development contributions to be in these languages when possible as it's the 21st century and we should be using memory safe languages. For this, I wrote a quick mailer within Rust to be able to send phishing emails for initial access. I had some initial issues while writing this like it kept spamming my inbox with mail (maybe a feature not a bug haha) but eventually I was able to iron out the kinks. I intend to include this as a plugin within Operator with some expanded features over time. One feature in particular I have in mind is for beacon agents with long time periods (weeks/months between beacons) to remind the user of an upcoming beacon in case you would like to make adjustments before the next beacon.

The other piece of software I wanted to look at was building an agent for Merlin C2. I love Merlin because it has a great easy to use and understand command line interface design, it's written primarily in Go, the software stack is nicely written, it does some newer-ish type stuff like HTTP/2 communications, all while not being completely bloated. While I'm a huge fan of Go and we use Go for Pneuma agent, Go does potentially have some limitations when you consider its garbage collection that could produce larger than desired file sizes. Pneuma is perfect for what we are doing with Operator, but it would be really cool to have a Rust agent as well. Google has done some amazing work with Go libraries especially when it comes to network and crypto. I would say Go is perfect as an agent management platform. What I wanted to build was a Rust agent that utilizes the Merlin C2. This should provide the best of both worlds in that you can get memory safety, amazing+newly developed libraries, while also having a smaller agent footprint since you forgo the garbage collection. As I stated earlier, I intend for everything that I built to be ported to Operator. As I continue to learn the code base of Operator, we look to make available a modular based Rust agent that is derived from this work.                   

Gaps In The Plan

The biggest gap in my plan was initial access on Manjaro. In general, Manjaro and any Arch based Linux install is a significant undertaking to get access on. Arch tends to utilize the latest and greatest software and users tend to not carry legacy software baggage. From experience, sometimes it's easier to just reinstall Arch in hopes it solves an issue than trying to fix some rabbit hole problem. While the previous statement might suggest otherwise, I absolutely love Arch and I hope as Arch becomes even more popular with things like SteamOS 3.0 people will really start to consider it as their daily driver. Arch has come a long way since I was first exposed to it over 10yrs ago. If this writing says anything it's that you're pretty safe on Arch. 

I basically needed to tailor something from scratch to gain initial access because it would be a rare occurrence for someone to just openly release an initial access on newer Linux software and I wasn’t flying to David’s location to try and get physical access. I recently read a Twitter post that I seemingly can no longer find, that basically said that 10 to 20 years ago getting a targeted exploit and weaponizing it used to take a staff member a few days to a week but now it takes roughly a few months with more than a few expert staff. While not a good sign for me, it does point to the continued effort that software security is getting better over time (we still have a lot of work to do though). 

Doing this over again, I would have started at initial access since I could have leveraged the open source for everything else but, I think the potential of porting over the software I developed will be better for Operator especially considering our users tend to already have access.        

Final Thoughts and What's Next

While some might be apprehensive about doing this as their first assignment, I found it to be an extremely fun and humbling experience. I was able to build some software that I intend to port and extend functionality to Operator in the near future. I also came out of this thinking about other cool potential additions for plugins like an automated way to build out a VPN network, having a way to store an OSINT target diary, and a way to build and manage personas. I was also able to find some weaknesses in my own red team toolbox which I intend to bolster in my free time and hopefully help build tools that help with this within Operator. At the end of the day, I was able to successfully find David and with a bit more time, I certainly had more avenues I could have pursued.