search

veso266 / impacket

Automatically exported from code.google.com/p/impacket
Other
0 stars 0 forks source link

CMD.exe not open #31

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
[*] Requesting shares on 192.168.148.52.....
[*] Found writable share E$
[*] Uploading file xjgawhWr.exe
[*] Opening SVCManager on 192.168.148.52.....
[*] Creating service DglE on 192.168.148.52.....
[*] Starting service DglE.....
[!] Pipe not ready, aborting
[*] Opening SVCManager on 192.168.148.52.....
[*] Stoping service DglE.....
[*] Removing service DglE.....
[*] Removing file xjgawhWr.exe.....
[!] Error performing the uninstallation, cleaning up
root@kali:~#

Original issue reported on code.google.com by i...@mehran.co on 21 Aug 2013 at 4:59

GoogleCodeExporter commented 9 years ago 
Hey there...

Thanks for the report. The following info could help me spot the problem:

1) Impacket version used ( it is printed whenever you run psexec.py )
2) Target OS for that machine with IP 192.168.148.52
3) If you have a wireshark capture of the session that would be helpful

cheers,
beto

Original comment by bet...@gmail.com on 21 Aug 2013 at 1:54

GoogleCodeExporter commented 9 years ago 
1) Impacket v0.9.10
2) Windows XP SP2
3) capture file : https://www.dropbox.com/sh/gldx36nphkdq6re/F_oKRJLFLO/cap

Thanks .

Original comment by i...@mehran.co on 22 Aug 2013 at 6:03

GoogleCodeExporter commented 9 years ago 
Thanks for the info..

What I can understand from the packet capture is:

1) Credentials are ok, psexec was able to log in successfully
2) The RemCom server executable is copied to the target machine (packet No. 86 
thru 167), share E$
3) The service is configured and correctly started. This means it was requested 
to execute the filename we just uploaded.
4) Right after that, we try to connect to the RemCom service, to a particular 
pipe (PIPE\RemCom_comunicaton). Here, it fails, saying there's no such pipe on 
the other end. Psexec tries for a while to connect to that pipe and then gives 
up.
5) When uninstalling everything, services are correctly removed, but when 
trying to remove the file we uploaded in step 2), the machine answers that 
there's no such file on the other end (packet 2731-2733).

Unless I'm missing something here, the file is uploaded but then it disappears. 
Do you know if there's an antivirus/IDS running on the target machine? That 
might be the reason.

Do you have access to that machine to inspect the eventlog?

I just tested psexec on a Windows XP SP2 and it's working well. I'll keep 
testing it on other XP SP2 images in case i'm missing something.

Original comment by bet...@gmail.com on 22 Aug 2013 at 3:56

GoogleCodeExporter commented 9 years ago 
I have seen this when using the same remcomservice that was spawned from a 
previous run of psexec; using randomly generated names for development gets 
super messy for the regsitry.  Not that my problem had anything to do with your 
problem per say, but you could be seeing a general error message that get's 
pushed back for any error while communicating with the remcomservice.  This 
still doesn't explain why the executables would go missing.  Can you check that 
the service does indeed exist after psexec.py is called?  I wonder if this is a 
permissions problem in windows as I have seen windows many of times tell me 
that something doesn't exist when I really just don't have access to it.  What 
permissions are you executing with?

Original comment by rustysco...@gmail.com on 30 Aug 2013 at 11:15

GoogleCodeExporter commented 9 years ago 
Hey there...

"same remcomservice that was spawned from a previous run".. How did you do 
that?.. Remember psexec trieds to remove the service, remove the executable, 
etc. 

I'm actually not having problems.. I was just speculating based on the 
wireshark dump you sent me. I haven't been able to trigger this problem with my 
VMs :s. That's why I'm needing you here ;).. Were you able to check the 
target's machine event log?

With regards to the service existing on the other end.. again.. since I can't 
reproduce it I can't answer. But if you can.. you can quickly list the remote 
services running on that machine by using the services.py utility bundled in 
impacket as well. Running it this way:

services.py user:password@targetIp list

cheers
beto

Original comment by bet...@gmail.com on 30 Aug 2013 at 11:34

GoogleCodeExporter commented 9 years ago 
oops.. sorry rustycottweber.. Just found out you weren't the original bug 
reporter ;) Unless you're using different accounts ...

regards,
beto

Original comment by bet...@gmail.com on 30 Aug 2013 at 11:36

GoogleCodeExporter commented 9 years ago 
Hi,
I am not sure if this is the process for asking questions, but i am having a 
similar issue with "Pipe not ready". 

I am using 0.9.13-dev and trying to use psexec.py to push an .MSI and install 
on a remote client, but the script is erroring as per above with the "Pipe not 
ready".

Is there a known reason for this issue that i am missing?

Original comment by stuart.d...@gmail.com on 26 Jul 2014 at 2:04

GoogleCodeExporter commented 9 years ago 
Stuart:

1) What's the target OS? (architecture included).
2) Please send me the argmuents you passed to psexec.py and the output it 
generates.
3) Did you try pushing something different to that MSI? Is it working?
4) A wireshark traffic is always helpful.

We never nailed down the original problem for this issue. Not sure yours is 
similar.. we'll see .

Original comment by bet...@gmail.com on 26 Jul 2014 at 3:09

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi,
1) WinXPSP3 and WIN2K8R2SP1. tried on both. same error
2)..
root@ACME:~/Desktop/agent# psexec.py -c Agent.msi 
Administrator:password@192.xxx.xxx.xxx msiexec -path C:\\Windows\\system32\\ 
-file Agent.msi 
Impacket v0.9.13-dev - Copyright 2002-2014 Core Security Technologies

Trying protocol 445/SMB...

[*] Requesting shares on 192.xxx.xxx.xxx.....
[*] Found writable share ADMIN$
[*] Uploading file YDLwGZtA.exe
[*] Opening SVCManager on 192.xxx.xxx.xxx.....
[*] Creating service efCd on 192.xxx.xxx.xxx.....
[*] Starting service efCd.....
[*] Uploading file Agent.msi
[!] Pipe not ready, aborting
[*] Opening SVCManager on 192.xxx.xxx.xxx.....
[*] Stoping service efCd.....
[*] Removing service efCd.....
[*] Removing file YDLwGZtA.exe.....
3) No, haven't tried a different file. I can see the MSI dropping on the target 
system, but then removed. This MSI isn't corrupted as i am using it currently 
for a few other systems.
4) screenshot of pcap output: 
https://drive.google.com/file/d/0B9KZ0eC1L0NneW5rbVZWaFF3aFk/edit?usp=sharing

HTH,

Original comment by stuart.d...@gmail.com on 26 Jul 2014 at 3:41

GoogleCodeExporter commented 9 years ago 
Oh, forgot to mention, this will work if i am simply invoking cmd.exe, without 
any file upload, etc.

It looks like it has to do with the remote execution. I have confirmed it is 
not AV causing the issue.

Original comment by stuart.d...@gmail.com on 26 Jul 2014 at 3:56

GoogleCodeExporter commented 9 years ago 
Hey,

1) Thanks
2) The way you're calling psexec.py is wrong. I don't think that is bringing 
the problem but so you know, whenever you specify a -c option, the command you 
specify is used as parameter for the -c file that is being executed:
  -c pathname           copy the filename for later execution, arguments are
                        passed in the command option
So.. if your example what's gonna end up being executed is:
"Agent.msi msiexec -path C:\\Windows\\system32\\ -file Agent.msi "
3) It might be worth trying it out.. or at least just do a psexec.py w/o 
uploading anything else and just running a cmd.exe. Does it work?.. That'd rule 
the RemComSvc out of the possible list of issues.
4) I was asking for an export file so I can import here. Don't worry tho.. 
still not needed.

I would do another test stuart:

1) Upload manually the file to the target server (let's say at c:\\)
2) Instead of psexec.py, use wmiexec.py:
wmiexec.py Administrator:password@192.xxx.xxx.xxx  msiexec -path 
c:\\windows\\system32\\ -file c:\\Agent.msi

Executing via WMI is way cleaner that with psexec (no services are created). If 
this works putting everything together in a single scripts is a piece of cake.

let me know.
beto

Original comment by bet...@gmail.com on 26 Jul 2014 at 3:59

GoogleCodeExporter commented 9 years ago 
Hey,
Choosing psexec.py over wmiexec.py was specifically due to wmiexec not being 
able to copy the file over prior to running the command, as this is a design 
requirement.
Do you know a way of incorporating the file upload with the wmiexec.py ?

Original comment by stuart.d...@gmail.com on 26 Jul 2014 at 5:36

GoogleCodeExporter commented 9 years ago 
Hey,

So is it working with the WMI if you upload the file manually?

I'll send you an example of how to upload a file to a target server 
(smbclient.py is another good example).

Original comment by bet...@gmail.com on 26 Jul 2014 at 5:52

GoogleCodeExporter commented 9 years ago 
send me a mail to bethus at gmail dot com and I'll help you.. 

We're going outside the scope of this ticket to keep writing in here

beto

Original comment by bet...@gmail.com on 26 Jul 2014 at 6:03

GoogleCodeExporter commented 9 years ago 
I ran into this same issue while testing on Windows 7 x64 running in a MAC OSX 
Fusion VM.  I was running "tasklist.exe" via psexec with hashes from the host 
to the guest. 

I found that the clean up code was unable to delete the executable, because it 
had not terminated yet. I added a time.sleep(.5) just before deleting the file, 
and the problem was solved. However, I plan to separate the file delete to it's 
own try/except and attempt to delete the file every second, and then give up 
after 3 attempts.  Note: sleep(.1) did not solve the problem.

I did not have any issues with Windows XP in the same configuration.

Original comment by betafocu...@gmail.com on 2 Dec 2014 at 3:42

GoogleCodeExporter commented 9 years ago 
Hey mate.. 

Thanks for the report!! Patches are welcome :)

cheers!
beto

Original comment by bet...@gmail.com on 2 Dec 2014 at 3:45