Psexec 32 Bit Download VERIFIED
Violetta Hooke
Figured it out finally after some more internet searching and trial and error. psexec needs /c to run multiple commands, but that syntax doesn't work with the setup I wrote above. I've gotten the below command to run what I need.
So when psexec is used to run something on a remote system, it works by creating a new service executable called psexesvc.exe which is embedded within the original psexec.exe file. This is copied to the Windows folder on the remote machine via the admin$ default share (hence why you need to be an admin to get psexec to work remotely). It then creates the PSEXESVC service with this, now local, executable, starts it and then runs the specified command.
What I found was that even when I copied psexec.exe to another file name, the file produced and copied to the remote system was still called psexesvc.exe. This is what happens when you run the copied psexec.exe and tell it to invoke a command on a remote machine:
psexec copies a psexecsvc file to the admin share and then using remote management starts up a service using that file. It opens up named pipes and uses that for further communication. When it's finished it tidies up after itself.
Port 135 (TCP) - for Remote Procedure Call (RPC) Service (that's what psexec will do too)Port 137 (UDP) - for NetBIOS Name ServicePort 138 (UDP) - for NetBIOS Netlogon and Browsing (used in PSEXEC to verify the provided user name annd password)Port 139 (TCP) - for NetBIOS session (NET USE)Ports above 1024 (TCP) - for RPC Communication.DCOM needs open UDP ports in the 1024-5000 range.
i seem to struggle getting psexec tool to open DC administrative tools like AD users& computers , DHCP , etc...using psexec URL .
Whenever typing psexec://mmc.exe dhcpmgmt.msc
it come up with message saying you need new APP to open this psexec link , and ask to open windows store
Help documentation is the most important thing for getting started with any tool. If you run the psexec command without any switch, you will see detailed help, including its usage syntax and all the supported switches. The following screenshot shows what the help section looks like.
If you do not see this help page but instead see an error that says 'psexec' is not recognized as an internal or external command, operable program or batch file, it means you did something wrong while setting up the Path environment variable.
In addition to the metadata, a Windows Registry artifact (such as HKEY_CURRENT_USER\software\sysinternals\psexec\eulaaccepted) can indicate when PsExec has been used. Additionally, an admin must accept an End-User License Agreement if they want to use the utility, and the acceptance is written to this key. As with binary metadata and named pipe usage, this will not change if PsExec is renamed, but it can be easily removed by an informed adversary.
When I run the SSIS package manually and have the Windows Style option of the Execute Process Task set to Window I notice the DOS window does not disappear after the psexec has called the remote process - it just hangs there. This probably has something to do with it
I had a similar issue recently. I remoted into the machine and ran the psexec command that the SSIS package was attempting to run and it worked fine. So I logged off of the machine and logged back in with the credentials used by SQL Server Agent (which is the same credentials the agent job was configured to use) and tried running the psexec command and to my surprise, a window pops with the license agreement and the program wouldn't execute until I clicked the accept button. After that, the scheduled SSIS package worked without issue. Basically, the 1st time you run any of the executables from sysinternals this window pops up and it isn't machine specific, but user specific. I'm sure there is probably a registry entry you could edit, but it's easy enough to login with the agent account credentials or runas the agent account credentials to get this squared away.
Implements remote process execution similar to the Sysinternals' psexectool, allowing a user to run a series of programs on a remote machine andread the output. This is great for gathering information about servers,running the same tool on a range of system, or even installing a backdoor ona collection of computers.
To use this, a configuration file should be created and edited. Severalconfiguration files are included that you can customize, or you can writeyour own. This config file is placed in nselib/data/psexec (ifyou aren't sure where that is, search your system fordefault.lua), then is passed to Nmap as a script argument (forexample, myconfig.lua would be passed as--script-args=config=myconfig.
$ ./nmap -n -d -p445 --script=smb-psexec --script-args=smbuser=test,smbpass=test,config=examples,host=1.2.3.4 192.168.1.21[...] Example 5: Can the host ping 1.2.3.4? Pinging 1.2.3.4 with 32 bytes of data: Request timed out. Request timed out. Request timed out. _Request timed out.For the final example, we'll use the upload command to uploadfgdump.exe, run it, download its output file, and clean up itslogfile. You'll have to put fgdump.exe in the same folder asthe script for this to work:
mod.url is displayed to the user if mod.programisn't found in nselib/data/psexec/. And finally,mod.outfile is the file that is downloaded from the system.This is required because fgdump writes to an output file instead of tostdout (pwdump6, for example, doesn't require mod.outfile.
- upload (boolean) true if it's a local file to upload, false if it's already on the host machine. If upload is true, program has to be in nselib/data/psexec.
- name (string) The name to display above the output. If this isn't given, program .. args are used.
- program (string) If upload is false, the name (fully qualified or relative) of the program on the remote system; if upload is true, the name of the local file that will be uploaded (stored in nselib/data/psexec).
- args (string) Arguments to pass to the process.
- env (string) Environmental variables to pass to the process, as name=value pairs, delimited, per Microsoft's spec, by NULL characters (string.char(0)).
- maxtime (integer) The approximate amount of time to wait for this process to complete. The total timeout for the script before it gives up waiting for a response is the total of all maxtime fields.
- extrafiles (string[]) Extra file(s) to upload before running the program. These will not be renamed (because, presumably, if they are then the program won't be able to find them), but they will be marked as hidden/system/etc. This may cause a race condition if multiple people are doing this at once, but there isn't much we can do. The files are also deleted afterwards as tempfiles would be. The files have to be in the same directory as programs (nselib/data/psexec), but the program doesn't necessarily need to be an uploaded one.
- tempfiles (string[]) A list of temporary files that the process is known to create (if the process does create files, using this field is recommended because it helps avoid making a mess on the remote system).
- find (string[]) Only display lines that contain the given string(s) (for example, if you're searching for a line that contains "IP Address", set this to 'IP Address'. This allows Lua-style patterns, see: -users.org/wiki/PatternsTutorial (don't forget to escape special characters with a %). Note that this is client-side only; the full output is still returned, the rest is removed while displaying. The line of output only needs to match one of the strings given here.
- remove (string[]) Opposite of find; this removes lines containing the given string(s) instead of displaying them. Like find, this is client-side only and uses Lua-style patterns. If remove and find are in conflict, then remove takes priority.
- noblank (boolean) Setting this to true removes all blank lines from the output.
- replace (table) A table of values to replace in the strings returned. Like find and replace, this is client-side only and uses Lua-style patterns.
- headless (boolean) If headless is set to true, the program doesn't return any output; rather, it runs detached from the service so that, when the service ends, the program keeps going. This can be useful for, say, a monitoring program. Or a backdoor, if that's what you're into (a Metasploit payload should work nicely). Not compatible with: find, remove, noblank, replace, maxtime, outfile.
- enabled (boolean) Set to false, and optionally set disabled_message, if you don't want a module to run. Alternatively, you can comment out the process.
- disabled_message (string) Displayed if the module is disabled.
- url (string) A module where the user can download the uploadable file. Displayed if the uploadable file is missing.
- outfile (string) If set, the specified file will be returned instead of stdout.
- req_args (string[]) An array of arguments that the user must set in --script-args.
- $lhost: local IP address as a string.
- $lport: local port (meaningless; it'll change by the time the module is uploaded since multiple connections are made).
- $rhost: remote IP address as a string.
- $rport: remote port.
- $lmac: local MAC address as a string in the xx:xx:xx:xx:xx:xx format (note: requires root).
- $path: the path where the file will be uploaded to.
- $service_name: the name of the service that will be running this program
- $service_file: the name of the executable file for the service
- $temp_output_file: The (ciphered) file where the programs' output will be written before being renamed to $output_file
- $output_file: The final name of the (ciphered) output file. When this file appears, the script downloads it and stops the service
- $timeout: The total amount of time the script is going to run before it gives up and stops the process
- $share: The share that everything was uploaded to
- (script args): Any value passed as a script argument will be replaced (for example, if Nmap is run with --script-args=var3=10, then $var3 in any field will be replaced with 10. See the req_args field above. Script argument values take priority over config values.