Regarding this KB https://attackerkb.com/topics/TEBmUAfeCs/cve-2021-36942?referrer=home Microsoft patched the EFSRPC for another issue, now needing packet-level privacy. Is this possible to integrate in PetitPotam?

Hello,

I tried using the ntlmrelayx.exe that was provided in the repo but unfortunately it does not recognize the --adcs flag which I from my understanding is needed to exploit the ADCS - did I do something wrong or is the binary not working?

Trying to exploit this in a live enironment I get:

[-] Connecting to ncacn_np:172.20.247.109[\PIPE\lsarpc]
[+] Connected!
[+] Binding to c681d488-d850-11d0-8c52-00c04fd90f7e
[+] Successfully bound!
[-] Sending EfsRpcOpenFileRaw!
[-] Got RPC_ACCESS_DENIED!! EfsRpcOpenFileRaw is probably PATCHED!
[+] OK! Using unpatched function!
[-] Sending EfsRpcEncryptFileSrv!
Something went wrong, check error status => EFSR SessionError: code: 0x7b - ERROR_INVALID_NAME - The filename, directory name, or volume label syntax is incorrect.

PetitPotam Version: 2ae559f938e67d0cd59c5afcaac67672b9ef2981 Impacket Version: impacket==0.9.22 (Kali Repos) EDIT: Also tried with latest impacket release (0.9.23)

From what I can understand the target might have the patch applied, but as far as I understand that does not patch all possible functions. Petitpotam seems to fail when trying one of the alternatives (EfsRpcEncryptFileSrv).

Hi,

I added a couple of the alternate EFS APIs to the c-version of your tool so you can test without impacket. I did not include the exe in the pull since I don't know how you feel about publishing precompiled executables from strangers ;-)

Thanks, Christoph

First of all, thanks for your excellent research work.

I'm trying to reproduce it using a Windows Server 2012 R2 with no patches installed either automatically or manually.

I installed AD CS using all default options offered by the setup wizard.

When I invoke the Python script from your repo and cooperate it with ntlmrelayx from https://github.com/ExAndroidDev/impacket/tree/ntlmrelayx-adcs-attack , it just kept telling me HTTP 401 Unauthorized.

Since it's totally all default situation, I have no idea what's wrong with it to reproduce.

More information might be useful for debugging:

• Certificate can be requested via any other machine in the domain. DC itself also has a certificate. Any other machine also can request machine account certificate in GUI.
• Web Endpoint /certsrv will ask for human user credential, then it works as intended. But in this situation, machine account NTLM authentication seems not to work.
• If I replace ntlmrelayx with responder, I could successfully get a response and hash capture notice from responder, which means, at least, NTLM Relay part, works fine.

Thanks for your help in advance.

Use other func in efs to bypass MS August patch. there are many other func in efs rpc, similar to the original PetitPotam. (After fuzzing win10 rpc)

info: https://twitter.com/red4blue_sec/status/1425475468715769858

Hello,

Following the previous patch to force the use of Privacy Level AUthentication (https://github.com/topotam/PetitPotam/issues/14), the Python script generate the following error: Traceback (most recent call last): File "XXX/PetitPotam.py", line 448, in <module> main() File "XXX/PetitPotam.py", line 441, in main dce = plop.connect(username=options.username, password=options.password, domain=options.domain, lmhash=lmhash, nthash=nthash, target=options.target, pipe=options.pipe, doKerberos=options.k, dcHost=options.dc_ip, targetIp=options.target_ip) File "XXX/PetitPotam.py", line 353, in connect dce.set_auth_type(RPC_C_AUTHN_WINNT) NameError: name 'RPC_C_AUTHN_WINNT' is not defined

I think you need to add the following line to the imports: from impacket.dcerpc.v5.rpcrt import RPC_C_AUTHN_LEVEL_PKT_PRIVACY, RPC_C_AUTHN_WINNT

added Kerberos auth support (without thorough testing, but where I tried it worked flawlessly).

• a basic fix for compiling the C version on default Visual Studio 2019 setups.

Function rpctransport.set_credentials was called with arguments in a wrong order (nthash was at lmhash's place) preventing pass-the-hash from working.