new module: smb > presence

[crosscutsaw]

Description

during my engagements, i hunt a lot of local administrators. both local administrator and local administrator privileged domain user. before seeking tokens, lsass dump or process injection; i always do "-x 'dir c:\users'" and "-x tasklist /v" for getting first level user information. if there is a domain admin user then the scenario is completed. but if not, there is a lot of work. grepping "-x tasklist /v" is time consuming and not a meta.

this module first executes 'net group "domain admins" /domain' and 'net group "enterprise admins" /domain'. then seeks domain level admin users in c:\users and tasklist /v command output. also:

-it seeks only dotted administrator folders in c:\users. ie. domainname.administrator (built in administrator will be not shown on dc -- we don't need it tho..)
-it seeks both dotted and non dotted domain level admin users in c:\users. ie. domainname.emreadmin and emreadmin.
-it seeks only domain named tasks in tasklist for administrator. ie. domainname\administrator is shown, localmachinename\administrator is not shown.

please note that i need help to improve this module. this is as far as i could get with my current knowledge.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

tested on a dummy domain, a domain controller and a domain client machine.

Screenshots (if appropriate):

domain admin and enterprise admin users:

check on client with local admin creds:

opening a cmd as domain admin:

check again:

check after creating folder with admin name:

check on dc with domain admin creds:

Checklist:

• I have ran Ruff against my changes (via poetry: poetry run python -m ruff check . --preview, use --fix to automatically fix what it can)
• I have added or updated the tests/e2e_commands.txt file if necessary
• New and existing e2e tests pass locally with my changes
• My code follows the style guidelines of this project (should be covered by Ruff above)
• If reliant on third party dependencies, such as Impacket, dploot, lsassy, etc, I have linked the relevant PRs in those projects
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[NeffIsBack]

Quite a nice module, thanks for the contribution! Gonna take a closer look at it when i got the time

[crosscutsaw]

9f9ed93

added legacy windows support, changed logging style and tried to group hosts in latest update.

[NeffIsBack]

Really like the idea of the module, but i think we should try to accomplish it without command execution if possible. That way AVs will not detect/stop the execution that easy. Especially task listing is often kinda risky.

If you need help feel free to dm me or someone else on discord/twitter or reach out on here.

[crosscutsaw]

4992c45

updated module with every request resolved. also, thank you for the help!

[NeffIsBack]

When you finished please check if your code matches the formatting/style guidelines: poetry run ruff check . --preview

[crosscutsaw]

fce0ed7

done.

[NeffIsBack]

As imo you would use this module when scanning large ranges looking for Tier 0 Admins on non-Tier 0 systems i reduced the amount of log statements a bit. E.g. the queried administrators are now only visible with the --verbose flag.

LGTM:

[NeffIsBack]

Fyi, also fixed a minor logging bug in the change-password module

[crosscutsaw]

looks good, i will def need to try on a real world pentest. i hold the original in my arsenal. :))

thank you for your extended support on this. really appreciated.

[NeffIsBack]

Thanks for the work!
If you find differences between the original version and this one please let me know and we fix it!

[NeffIsBack]

Added the ability to enumerate scheduled tasks where the logonType is Password. Therefore, these users will have the password in dpapi:

[NeffIsBack]

I will hide non admins behind the --verbose flag as the module explicitly is for searching domain/enterprise admins

[crosscutsaw]

hello again alex!

i finally got the opportunity to test it in a real world pentest. problems:

1- it doesn't get administrator.domain domain admins.
2- i think directory output shouldn't be hidden since verbose log is too much. think like you're executing this module on 12 endpoints. it.. wil be a lot output. also i dumped lsass from a machine where there was no domain admin process but entry in directory, actually found a domain admin hash. i would miss it if i didn't executed -x 'dir c:\users'. because there were some protections and dumped lsass by hand, also forgot about verbose flag. :))
3- i didn't expected local auth to display domain admins, but i think we should find a way that; if there is a domain user process in the machine, get domain groups on behalf on that domain user. or, maybe adding a module option that making our domain user (that we have creds) usable for this individual process. because this module shines mostly on local auth.

[NeffIsBack]

Hi :)

regarding your points:

1. We should fix that. Do you know why that occurs? Looked to me that only happens when there is a naming collision of the users and we should have a check explicitly for the SID 500 admin (if user.domain in dir: ...).
2. Isn't that the best argument against it? Imo the output would be pretty bloated if we list every user in every users directory we we scan, especially if we explicitely are looking for DAs. As long as we get the DAs properly that should be fine. Perhaps we should log the rest of the module in debug and not in info mode, as the info log seems to be a bit bloated indeed.
3. I think i didn't fully understand what you were trying to say. Are you looking for a way to enumerate the domain admins with local auth privileges? I am not sure if that is possible.

[crosscutsaw]

Hi :)

regarding your points:

1. We should fix that. Do you know why that occurs? Looked to me that only happens when there is a naming collision of the users and we should have a check explicitly for the SID 500 admin (`if user.domain in dir: ...`).

2. Isn't that the best argument against it? Imo the output would be pretty bloated if we list every user in every users directory we we scan, especially if we explicitely are looking for DAs. As long as we get the DAs properly that should be fine. Perhaps we should log the rest of the module in debug and not in info mode, as the info log seems to be a bit bloated indeed.

3. I think i didn't fully understand what you were trying to say. Are you looking for a way to enumerate the domain admins with local auth privileges? I am not sure if that is possible.

3- no, i meant, automatic process injection if there is domain user task/s in pwn3d machine to enunerate domain related things on behalf of injected domain user. or even better adding a module option that we can use our domain user for enumerating domain related things. for example, in whitebox tests (mostly i do) i always get a domain user from client. or we can obtain from somewhere or creating ourselves if maq is positive. so i think it's a good opportunity to augment the module with this possibility.

i.e: netexec smb 10.20.30.40 -u administrator -H 8020b81d23caa5ab922096948d7c192d --local-auth -M presence -o ALTUSER=pentestuser ALTPASS=Aa123456 ALTDOMAIN=zurrak.local

just like impacket's old smbpasswd.py.

[NeffIsBack]

There is the change-password module if you are looking for that. But i think these are a few steps combined. Impersonating users to enumerate the domain is nice, but we first have to impersonate someone and then do stuff with it. For the first step you could take something like schtask, but impersonating is not that easy to automate. There are a few ways in NetExec to do that tho

[crosscutsaw]

hello again alex,

i'd like to explain with code. you can see at:
crosscutsaw@9e05072

explanation:
"presencetest" is a domain admin user and it has an open process in domain computer "pentest". we have local administrator password and can execute remote commands.

goal is getting domain admins and enterprise admins users locally by using our domain user. and with my proposal it's possible. here is poc:

things i couldn't do (due to lack of my python knowledge):
-enumerate dc ip from module option altdomain. so we don't have to assign dc ip.
-i couldn't migrated it with current presence.py. i tried some code with like "if altuser is used" conditions to automatically switch ldap context, but in the end failed.

proposal:
migrate alternative user ldap enumeration to presence.py. that's it. :))

[NeffIsBack]

Hmm okay understood, might be worth to add it 👍