Replies: 1 comment
-
|
I understand this from an exploitation view, but Certipy is also used for auditing. Some mitigations involve restricting enrollment rights. For example, the built-in SubCA template is "vulnerable" to ESC1, but only administrators are allowed to enroll. Showing it as vulnerable could confuse audits. Therefore, while I agree it's nice from a ref perspective, I think these changes would have a an overall negative impact considering the blue perspective. It's true that I’m converting this to a discussion for more input on this. Thank you for opening this discussion up :) |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
✨ Feature Description
It could be useful to add a remark when there is a vulnerability but the current user cannot exploit it.
🚀 Why is this feature important?
To avoid having to rerun Certipy for each new user found.
An example where this could be useful is the current seasonal machine from HTB (Fluffy).
🔄 Alternatives or Workarounds
Rerun Certipy each time credentials for a new user are discovered.
Another way was to use the -old-bloodhound option with custom queries, but it was removed :(
📎 Additional Context or Mockups
Remark examples:
"Template is vulnerable to ESC1 but current user cannot enroll."
"CA is vulnerable to ESC16 but current user cannot enroll."
Beta Was this translation helpful? Give feedback.
All reactions