Username enhancement for reverse bruteforce & Kerberoasting

[Green-Wolf]

Hi Dan,

Firstly, wow, what an amazing tool. I can see this making my life so much easier! Thanks so much. I have a couple of suggestions for improvements/enhancements:

1. It would be great to have an option to provide a list of addition usernames/emails in a text file that have been enumerated separately. This could also be automated by adding tool such as LinkedInt/Prowl/InSpy (Can do multiple as they use different methods, linkedint by company name on the site, prowl by search engine results). Incorporating these to scrape & generate usernames based on LinkedIn OSINT.

2. I know DeathStar uses bloodhound & empire to escalate through the network, but would it be possible to include Kerberoasting in here somewhere? Part of initial access using GetUserSPNs to get the tickets, run them through John with your custom list and add successes into Deathstar to give it more to work with? Putting the kerberos tickets into a separate file thats clearly marked would be great so they can be extracted & run through a more intensive cracking process if needed.

[DanMcInerney]

1. That's a good idea. Will be a lot of work to implement so I can't give a timeframe.

2. I really hate relying on automated hash cracking. It's such a hassle. There's so many problems that make it not great: the machine you're attacking from rarely has a lot of resources so cracking on it is usually slow and low success. So then you can give the options for the user to specify their own cracking box which the script can remotely access, but this leads to like a billion different options that need to be configured by the user: remote IP, remote port, path to wordlist, kind of attack, path to rules (if any), etc, etc. To the point where it's like, did we even save the user any time over having them just crack them themselves? This ignores all the many many errors that can occur when running hashcat that have to be handled or else the entire functionality that you just spent a month implementing is useless. I have local cracking working in icebreaker and I've written autoresp which autocracks responder hashes and I'm pretty sure I'm not going to include autocracking in future projects unless I build an entire framework around remote cracking which I can import and I don't really want to do that right now.

But the premise that kerberoasting would be useful in DeathStar is absolutely true. I'm writing a tool msf-netpwn that's like DeathStar for metasploit and I'll probably add kerberoasting (but probably not autocracking) to it.