Invoke-FileTransferOverWMI always gives 0 bytes on remote system when uploading..

[KurtDeGreeff]

ALthough I get 0 returnvalue with upload of *.txt , remote file always is 0 bytes...however with correct name ;) Do you know how to solve this?

Command: Invoke-FileTransferOverWMI -Targets SERVER1 -LocalUser ($cred.UserName) -RemoteUser ($cred.UserName) -LocalPass ($cred.GetNetworkCredential().password) -RemotePass ($cred.GetNetworkCredential().password) -File 'c:\temp\procs.htm' -Upload 'C:\Temp\new2.htm' -Verbose

Here is my verbose output: VERBOSE: Read in local file and base64 encode it VERBOSE: Writing encoded file to local registry VERBOSE: Connecting to SERVER1

__GENUS : 2 __CLASS : __PARAMETERS __SUPERCLASS : __DYNASTY : __PARAMETERS __RELPATH : __PROPERTY_COUNT : 2 __DERIVATION : {} __SERVER : __NAMESPACE : __PATH : ProcessId : 5360 ReturnValue : 0 PSComputerName :

VERBOSE: Sleeping to let remote system execute WMI command VERBOSE: Removing registry value storing uploaded file VERBOSE: Done!

[ChrisTruncer]

What file are you running on the remote system? And does it have PowerShell constrained mode active on it?

[ChrisTruncer]

Main this is it could possibly be AV, or it could be constrained Mode due to the way this is currently engineered.

[KurtDeGreeff]

What do you exactly mean with constrained mode? How can I check this? Thx

[ChrisTruncer]

You'll have to check if the remote system is configured with applocker or device guard because that can enforce PowerShell to run in constrained mode and prevent anything that uses .net within PowerShell.

[ossie-git]

I ran into the exact same issue. Tried it on two different targets (Windows 10 Pro and Windows Server 2012). In both cases the resulting file size is 0. I verified the credentials are valid and working. Here is what I ran

Invoke-FileTransferOverWMI -RemoteUser EXAMPLE\Administrator -RemotePass password -LocalUser user -LocalPass password -TARGETS 192.168.123.105 -File C:\Users\user\PipeList\pipelist64.exe -Upload c:\Users\pipelist64.exe

and the result returned was:

__GENUS          : 2
__CLASS          : __PARAMETERS
__SUPERCLASS     :
__DYNASTY        : __PARAMETERS
__RELPATH        :
__PROPERTY_COUNT : 2
__DERIVATION     : {}
__SERVER         :
__NAMESPACE      :
__PATH           :
ProcessId        : 3660
ReturnValue      : 0
PSComputerName   :

the file is created but with length of zero. I captured all the activity related to the process on the target (PID 3660) using Process Explorer and exported it as a CSV file - https://0x0.st/zPum.CSV - in case that helps

[ChrisTruncer]

Wow, I didn't even realize there was a long standing open issue here. For what it's worth, I did just test WMIOps, specifically uploading from one system to another. I ran essentially the same commands you guys did other than specifying my user account and file to transfer. I did successfully upload the file, and i verified that it does have the full file contents. So I did not get a 0 file after the upload. The only difference I can see from the above commands is the user accounts I gave for both local and remote are domain accounts (vs. local accounts). Would you mind trying this out?

Also, I believe that WMImplant is a better tool than WMIOps (it has more functionality and is a better way to operate on on computers). If I could, I would recommend that you guys check that out.

[ossie-git]

Just tried it. It worked when both local and remote are domain accounts. So it looks like it's an issue with non-domain accounts. Will try WMImplant as well. Thanks.