outflanknl
Kerberoast roast command is now OPSEC safe
Changed Kerberoast so it doesn't perform the heavily signatured LDAP query when you use the roast command, as it was unnecessary for targeted kerberoasting. Also added dynamic architecture selection in the cna script + building of x86 and x64 in makefile (didn't do this for everything).
Changed Kerberoast so it doesn't perform the heavily signatured LDAP query when you use the roast command, as it was unnecessary for targeted kerberoasting. Also added dynamic architecture selection in the cna script + building of x86 and x64 in makefile (didn't do this for everything).
Nice, i'll take a look at the changes asap.
Thanks! It's not a big pull request, but I learned the hard way that Kerberoast performs that ldap query when you specify one user (was late and I was tired, didn't test in our lab first 😅). Just did some quick patching and using it again now.
Kind regards,
Firat
From: Cn33liz @.> Sent: Tuesday, November 29, 2022 12:21:04 PM To: outflanknl/C2-Tool-Collection @.> Cc: Firat Acar @.>; State change @.> Subject: Re: [outflanknl/C2-Tool-Collection] Kerberoast roast command is now OPSEC safe (PR #4)
Changed Kerberoast so it doesn't perform the heavily signatured LDAP query when you use the roast command, as it was unnecessary for targeted kerberoasting. Also added dynamic architecture selection in the cna script + building of x86 and x64 in makefile (didn't do this for everything).
Nice, i'll take a look at the changes asap.
— Reply to this email directly, view it on GitHubhttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foutflanknl%2FC2-Tool-Collection%2Fpull%2F4%23issuecomment-1330474800&data=05%7C01%7Cfacar%40nviso.de%7Cc90a1b2d29924432bf5408dad1fbcea9%7C164afbb8055043cc94da24e7f8574228%7C1%7C0%7C638053176692992088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=O47Z7SQRwsoeFjkxXoaEHMpyPKJTznwqrVJqxn6yeE8%3D&reserved=0, or unsubscribehttps://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FARW3KL4Z5RWIBGOZY76YKK3WKXRKBANCNFSM6AAAAAASOKYDYA&data=05%7C01%7Cfacar%40nviso.de%7Cc90a1b2d29924432bf5408dad1fbcea9%7C164afbb8055043cc94da24e7f8574228%7C1%7C0%7C638053176692992088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=eo6GJroP8fE5p%2B5QossNesiQdF%2FTEPhphXw%2BjAfo7kY%3D&reserved=0. You are receiving this because you modified the open/close state.Message ID: @.***>
Classification: Internal
Hi, i used your feedback/changes en made an update to the Kerberoast code. Code is bit different then your change but works the same. Could you check if this works for you?
Hey,
It looks good, but is the UserAccountControl check really necessary for a targeted Kerberoast? If you’re doing a targeted kerberoast, you should know the details about the account (e.g. enabled or not). The current query might still look suspicious according to some rules.
Kind regards!
Good one.. If it still looks suspicious then i think it's best to remove it from the query. I'll update asap.
Thank you! I wouldn't say suspicious per se, but it's unnecessary and at least part of quite some signatured queries.