Nowadays, even for dogs, remote control has been invented .

Returning to the “Admin Summary” cycle, I would like to tell you about the options for running executable programs on remote computers. This article will be interesting to those who do not yet have centralized management systems, but already have an understanding of the tediousness of manually bypassing workstations and servers. Or those for whom decisions on a turnkey basis are not interesting due to unsportsmanship.

As a matter of why such a program launch is needed, one can cite the recent hysteria with Petya \ Ne-Petya, when everyone rushed to check / disable SMBv1 and download updates. Yes, and make an inventory or install an urgent patch with this method is also possible.

Once upon a time I got a job in an organization during the period of the Kido \ Conficker epidemic. The easiest way to find out if everything is all right in the company's IP was a nice Kaspersky utility called Kido Killer , which checked for the presence of the virus and eliminated it. Running the program on a good hundred cars was unhappy with my hands, so I had to get acquainted with automation.

If in operating systems * nix for remote launch, as a rule, SSH is used, then Windows has ways to launch programs and scripts like sand in the desert. I will analyze the main options, both well-known and exotic. I will not touch on such obvious things as a telnet server, especially since Microsoft has already removed it from modern OS.

Ways old, time tested

Psexec

Perhaps this is the first thing that comes to mind when it comes to remote launch programs. The utility from Mark Russinovich has been used since the days of Windows NT and is still used. In addition to the main function, you can use it both as Runas, and for launching programs in a user session of a terminal server. Psexec also allows you to specify the processor cores on which the program will run, and its priority in the system.

As an example, let's see if an update is installed that closes the sensational SMB vulnerability on the list of computers:

psexec @computers.txt /u USER /p PASS cmd.exe /v /c ""systeminfo | find "KB4012212" || echo !computername! >> \\server\share\log.txt""" 

The computers.txt file contains a list of computers. To run across the domain, you can use \\ *. In the \\ server \ share \ log.txt file, the names of workstations or servers without an update will appear. If there are computers in the domain with * nix on board or there is no access to the admin network resource Admin $ - the command on this machine will not be executed, but processing will continue. To prevent the script from hanging up every time you try to connect, you can specify a timeout using the -n option .

If the computer is turned off - we will not know about it. Therefore, it is better to pre-check the availability of machines or to collect in the file information about success or failure.

By cons Psexec can be attributed to the fact that it is because of its convenience and popularity is often used by virus writers. Therefore, anti-virus systems can detect the utility as a danger of the remote admin type.

By default, the process on the remote machine is executed on behalf of the user who launched Psexec. If necessary, the username and password can be set explicitly or use the SYSTEM account.

WMIC

WMI (Windows Management Instrumentation) is often used to manage Windows systems using different graphical utilities - an implementation of the object-oriented management standard WBEM. You can use wbemtest.exe as a GUI utility for working with WMI.

To work with WMI from the console created wmic.exe . For example, to check for installed updates instead of the creepy construction from the previous example, you can use a simple command:

 wmic /node:"servername" qfe get hotfixid | find "KB4012212" 

You can also use the list of computers with the command /node:"@computers.txt ".

Even with WMI, you can run programs - the syntax is extremely simple:

 wmic /node:"servername" process call create "cmd /c somecommands" 

Unfortunately, unlike Psexec, it will not work to get output in the console - you will have to output the command results to a file.

By default, the process on the remote machine is executed on behalf of the user running wmic. If necessary, login and password can be set explicitly.

Group Policies and Scripts

If the previous options did not require a domain environment, then a domain would be required. Scripts are supported when a user logs in and out of the system, as well as when it is turned on and off. Since every Windows administrator came across them, I will not describe in detail how to use them - just remind you where to look for them.

Scripts running at startup and shutdown.

Scripts running when a user logs in and out.

The scripts configured in the user section are executed on behalf of the user, and in the computer section - under the SYSTEM account.

Assigned Tasks

Quite an interesting way to deserve the right to life. Assigned tasks can be created from the command line using the schtasks.exe utility, execute them, and then delete them. More information about the syntax can be found in the documentation , but I will analyze an example of the use of scheduled tasks in a domain environment. Suppose we need to execute a command as quickly as possible, regardless of whether the computer is turned off or not. For this, the so-called Group Policy Preferences are used.

Search for setting scheduled tasks in the configuration of a computer or user - "Settings - Control Panel Settings - Scheduled Tasks".

Create a new scheduled task.

To execute an ASAP command or script, you will need to create an “Immediate Task (Windows 7 and higher)”. If suddenly in the infrastructure there are machines running Windows XP, then the "Next Task (Windows XP)" will do.

It is worth making several policies with the corresponding WMI filters or creating two different assigned tasks in the same policy with targeting - for example, using the same WMI filter. This will help avoid conflicts in a heterogeneous environment with old and new Windows.

An example of a WMI filter for applying the policy only on computers with Windows XP:

 SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "5.1%" AND ProductType = "1" 

The rest of the procedure for creating a scheduled task is trivial. The only thing, do not forget to check the “Apply once and not reapply” item, if the task does not require re-launch.

Run the immediate task only once.

When using such scheduled tasks, the program will start as soon as the computer receives the Group Policy update. This is convenient: you do not need to check the availability of computers in the case of Psexec and wmic and force users to restart the machines, as in the case of group policy scripts. If necessary, you can copy the script file locally in the section “Settings - Windows Configuration - Files”.

Assigned tasks allow you to explicitly specify the user name for running the program, including for SYSTEM.

Through the registry

Modifying the registry on user machines is a strange option, just in case of emergency. You can use the Run or RunOnce branches. Read more about them in the documentation . The registry modification itself can be done through group policies or from the command line — for example, with the following command:

 reg add \\COMPUTER\HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce /v script /t Reg_SZ /d "script.cmd" 

Depending on the registry branch, the process will be executed either under the user who has logged into the system or under the SYSTEM account.

There are other methods, such as editing shortcuts in the “Startup” folder or adding a shortcut to the popular program && script.cmd , but these methods are already from the “can, but not necessary” series.

We now turn to the new tools.

Ways new or where without PowerShell

PowerShell, justifying its name, can connect to remote computers using WMI, RPC and WS-Management (WSMan). Using the latter method requires pre-tuning.

Cmdlets that do not require pre-configuration usually have the ComputerName parameter, but do not have the Session parameter. You can view the list of such cmdlets with the command:

 Get-Command | where { $_.parameters.keys -contains "ComputerName" -and $_.parameters.keys -notcontains "Session"} 

To configure WSMan, it is generally enough to run the Enable-PSRemoting-Force command . It will start the WinRM remote control service and register exceptions in the firewall - in principle, this can be done for the entire domain using group policies. Details are described in the documentation .

After all computers are ready to accept requests, we can connect using the appropriate PowerShell cmdlets. To test connectivity, use the Test-WSMan cmdlet .

Check connectivity.

To execute a specific command or script, use the Invoke-Command cmdlet with the following syntax:

 Invoke-Command -ComputerName COMPUTER -ScriptBlock { COMMAND } -credential USERNAME 

Where COMPUTER is the computer name, COMMAND ― is the name of the command, and USERNAME is the name of the user, if necessary.

Look at the contents of the C drive from the remote computer.

If we need to get a full-fledged console - not for the sake of automation, but for the sake of controlling a specific computer, then we can use the Enter-PSSession cmdlet.

We work in the console of the remote computer.

Let me remind you that with the help of JEA, you can limit the cmdlets that are available for such a session or give access to those that are needed without administrative rights.

Of course, besides the built-in tools and small utilities, there are many programs for managing the structure. In addition to adult solutions, you can use monitoring tools like Zabbix and even the Kaspersky Anti-Virus management console to manage configurations like Chef, Ansible and MS SCCM.

In the period of heterogeneous structures, it would be good to have the possibility of unified management of Windows and Linux. This can be done with the help of PowerShell, which in itself is worthy of a separate article - is it worth it or is it already superfluous?

By the way, share your methods of hidden and not very launch programs on remote computers. Well, except for exploits.