Feature Request / Discussion: smart credentials selection, smart target selection, caching

[ajanvrin]

Please Describe The Problem To Be Solved

First of all, this is an enhancement that I'd be open to implement myself via a Pull Request, but it is sufficiently complex that I'd like to discuss with maintainers before starting work on it, to determine the best course of implementation.

Many actions in netexec have prerequisites, such as:

• Having credentials,
• Having admin rights on the targets,
• The target having a specific service enabled (ad cs, etc.).

And there is no feature to automatically select the right set of credentials to apply a given module or action on the right set of targets.

Currently, netexec has the -id feature allowing to do something using some or all known credentials

But credentials selection remain manual (you have to export the creds table and do a lot of grepping to e.g., get a list of all users with admin rights on one machine)
Target selection remains also largely manual, you similarly have to extract tables and use grep to e.g., get a list of targets where you have at least one set of credentials with administrative rights.

And you also have to manually keep track of "what's been done with this set of credentials on which targets", there is no easy way to determine "ok I have dumped dpapi secrets on this set of machines, but I just got a new set of credentials, I'd like to know if they have admin rights on new machines, and possibly dump dpapi secrets on these new machines"

In a typical engagement, that means I usually end up with hundreds of CSV files with names like "new_admin_creds_to_try" and I do a lot of grep|cut|join to get my lists of credentials and targets to move on to the next step.

It would be nice if netexec provided a way to do away with all these CSV files and provided a smart built-in creds and target selection.

Suggested Solution

I've delved into the code base a bit to see how this could be done pragmatically, and here are my first ideas:

• Add an "auto" keyword to the "-u", "-p", "-id" options as well as the target selection
  a command may thus look like: nxc smb auto -id auto --shares
• Where credentials selection happen (typically where the "all" keyword of the "-id" selection is processed), introduce logic that would:
  a) Have a look at the arguments (what we are doing),
  b) If autoselection is not currently implemented for one of the actions selected, raise something like NotImplementedError,
  c) Infer the prerequisites from what we are currently doing ("does enumerating shares require admin rights ? No, we can try with all credentials in the db") ("does dumping sam require admin rights ? yes, filter out all creds with an admin count of 0"),
  d) Automatically select from the db the set of credentials that meet the prerequisites, based on the highest prerequisites (if something requires admin rights, filter out all credentials that are not admin).
• Apply a similar logic for target selection:
  a) Have a look at the arguments (what we are doing),
  b) If autoselection is not currently implemented for one of the actions selected, raise something like NotImplementedError,
  c) Infer the prerequisites from what we are currently doing ("does enumerating shares require admin rights ? No, we can try with all hosts in the db") ("does dumping sam require admin rights ? yes, filter out all hosts where we have no admin creds"),
  d) Automatically select from the db the set of credentials that meet the prerequisites, based on the highest prerequisites (if something requires admin rights, filter out all credentials that are not admin).

It can even be smarter: if what we are doing requires local admin rights on one machine, and we have more than one set of admin credentials, it is unlikely that we need to do it more than once, so we should only keep one set of (cred, target) per target in this case (ex: there is no need to dump SAM twice). This seems harder to implement however, and may not be feasible at credentials selection time (if we have the creds A, B C, A and B being admin on target X, B being admin on target Y and C being admin on target Z, then we can neither remove A nor B).

And the cherry on top, an addition that would make this feature truly amazing:

• Create a table in the db, to keep track of what has been done on each target with each set of credentials. Did we enumerate shares on this target with these creds already ?
• If indeed something has already been done on a target, do not do it again (remove the set of credentials from the selection if the action does not require admin rights, remove the target otherwise)
• The db would be updated automatically, but I don't know yet where in the code (maybe as a module? I need to delve a bit deeper in the code to have a clearer picture).
• This feature would be opt-in or opt-out (preferably opt-in, with a new switch?), and may or may not be implemented at the same place as smart creds/target selection (in which case only this selection method would benefit) or elsewhere (in which case it may also be enabled with the usual creds input methods)
  In fact, this "caching" mechanism would probably be implemented at a later time (different Pull Request) than the previously discussed selection mechanism.
• Some finesse might be required: if lsass has been dumped with lsassy, surely there is no need to do it again with another method

The problems and challenges of these ideas are that they fall apart pretty fast (or rather, the complexity explodes) if one is trying to do multiple things (like enumerating shares and dumping dpapi secrets) simultaneously, because filtering becomes a nightmare (we've already enumerated shares but not dumped the secrets, so can't filter things at target selection, and introducing logic down the line will quickly become very annoying and unmaintainable. To address this, I'd like at first to tell users that doing more than one actions is unsupported and raise an error, but there may be a better, smarter way.

Also, it has the potential of being a footgun (users locking accounts and crashing stuff) and introduce bugs, so I'd like to tackle this conservatively, by first implementing the scaffolding (adding support for these arguments in args parsing and raising appropriate NotImplementedError on target/creds selection, before writing selection logic)
also, the whole DB caching would be implemented after at least some trivial actions such as listing shares are already done

I do not expect to really start work on this right away (I'll probably start this summer), so this is supposed to be a long-standing issue, I'm posting it mostly to get feedback from maintainers ahead of time

[Hackndo]

Hey there!

Some finesse might be required: if the SAM has been dumped with lsassy, surely there is no need to do it again with another method

lsassy doesn't dump the SAM :)

[ajanvrin]

Hi!
Dammit
I thought I'd reread the message enough times to correct all the mistakes, but no of course not.
It took the author of lsassy himself to notice this one :)
Thanks for pointing it out, I fixed the first message

[NeffIsBack]

Hi, first of all thank you for taking the time and effort for writing down and explaining your idea! It is always awesome to know that people really put a lot of effort into thinking how to improve the tool :)

I can see how it can be hard to track down which credential sets have access to what kind of machine. I have taken some time to think about such an auto selection feature, but i am still torn. For me it is critical to always know exactly which credentials i use for which command. This is why i am not sure if i would like to have something that decides for me which credentials to use, which could potentially harm the environment i am working in.
One example would be due to a bug or a missconception what the feature does, it does not select my created set of admin credentials, but a critical one because perhaps the id in the database is lower than my set of credentials (because it was added earlier) and than locks out an important admin/service account because of a fgpp or else. Imo selecting credentials should always be an active process and could be dangerous to automate. But that is only my view, happy to hear other point of views.

As i can still see the problem of keeping track if you have already owned a host or even which actions have been performed on it. Perhaps a more passive approach would be better suited? Maybe something like an auto suggesting feature would be an option, which could be turned on in the config and than suggests a set of credentials for a given host, if found in the database. This could also include information such as level of privilege on that host (admin/sudo/normal user), id in the database for the selection or even number of total owned hosts.

To the technical part of this:
Before such a feature (if we agree to integrate it) could be implemented there is probably still a lot of work to be done on the database side of nxc. For example ldap does not have this implemented correctly (alteast it is not working at the moment).

But, perhaps we could use the integrated system of the @requires_admin label on functions and the information about the two different kind of login functions inside of the modules (on_login and on_admin_login), but i think it would be just easier to select the highest privileges available instead of matching credentials to a set of commands (could get even be really difficult if you chain commands).
Though, most of the information for a rudimentary credential selection/suggestion feature should be already available inside the database, such as cross mappings from credentials to owned hosts. But still, this is probably not working 100% reliable on every protocol (if even implemented for all protocols, not sure atm) and would need to be checked&implemented if missing.

I would still like to hear other thoughts on a potential auto selection or suggestion feature @mpgn @Marshall-Hallenbeck @zblurx.
Would you like to have such a feature? Do you see any technical or logical problems with auto selecting or auto suggesting credentials?

[zblurx]

Hey, thanks a lot for bringing this discussion
In my opinion auto selection of credential is very dangerous: you can easily block target or use credentials you don't want to. Personnaly I would never use this.
Auto suggestion is already available through Bloodhound integration (or maybe I don't get your idea)
What could be really cool is your idea of keeping tracks of what has been dumped on which target, and also working on the DB to improve information storage (what has been dumped, when where and with which set of credentials)

[ajanvrin]

Hello!

Thank you for your initial feedback!

I can see a growing consensus around three ideas:

1. My proposed credentials autoselection feature did not win any heart, I have not managed to convince anyone of its usefulness, and it's seen as risky. It is best for credentials selection to remain a manual process, so that the risk of locking accounts remains fully managed by the user.
   On that front, I hear you, and I fully share the opinion that it can be risky, and such a feature should not be put into users'hands without robust risk management

2. There is room in the database for additional tables, some of which may be required to implement the autoselection feature, and all of which might be interesting in themselves. Some protocols are not on par with others in terms of database structure

3. The idea of keeping track of what's been done with which credentials, on which hosts, in what would perhaps be a new database table (per protocol), seems much more interesting in itself than the autoselection feature. Let's call this feature logbook (for lack of a better name yet)

Regarding the autoselection feature, I may have done a poor work of explaining what it would look like, what its purpose would be, how it could be designed to lessen the risk of account lockout. I have a few ideas, but they are complex to explain and implement, and I think I'd feel much more comfortable explaining it after having made progress towards developing a Proof of Concept I can showcase.

In light of this apparent consensus, here is what I suggest:

• A new branch is created besides main, maybe called autoselection_testbed
• I'd make progress on all three fronts, conservatively adding the database tables / information that might be wanted, advancing the logbook feature, and making progress towards the autoselection feature I think I want
• I'd make Pull Requests against this autoselection_testbed branch, taking great care of separating commits that are related to the autoselection feature (tagged autoselection) from those that are related to other parallel advancements (maybe tagged logbook)
• You'd disregard commits tagged autoselection and only review the other commits tagged logbook, cherry picking and merging the ones you deem worthwhile to the main branch. We'd only discuss these commits, I would not expect you to review or merge autoselection commits into main
• Once I feel that the autoselection feature has enough meat that I can make a proper case for it, I restart this very discussion, and try to convince you that this feature is 1) useful, 2) introduces minor/manageable risk 3) worthy of being merged into main
• From this point onwards, two possible outcomes:
  1. I manage to convince you, and the autoselection_testbed branch is merged with main
  2. I don't, and the autoselection_testbed branch is scrapped, having fulfilled its purpose

Does that sound reasonable?

[NeffIsBack]

Hi,
i am really sorry for the late response. I was really busy, but i also somehow didn't get a notification for this thread.

If you want to put the work into this kind of feature i would recommend creating two branches. One for the "logbook" mode and one for "autoselection". That way you can always update autoselection by merging main/logbook into it, while we still have two seperat branches, which you can make a PR from/we can merge.

Regarding the content: We are always happy about people putting work into the database side of netexec, but as already mentioned you probably have to first implement a lot of functionality that might be missing in lesser used protocols. If that doesn't scare you off, feel free to go ahead :)

Also if you want join our discord server. I am much more active there (compared to github discussions) and can react quickly to questions of any kind.