[EN] Running an Application as Administrator Without Giving the User Admin Rights: Runas, RunAsSpc, and Secure Usage Methods

In corporate or personal Windows environments, some applications may require administrator privileges in order to run properly. This is especially common with legacy software, hardware management tools, camera monitoring applications, accounting software, driver-level utilities, or applications that need to interact with system services.

The easiest solution may seem to be adding the user to the local Administrators group. However, this approach creates serious security risks. When a user is given full administrator rights, they are not only able to run the required application but can also make system-wide changes, install software, modify security settings, or accidentally run harmful files with elevated privileges.

For this reason, the main goal should be to allow a standard user to run only a specific application with elevated permissions, without granting full administrator rights to the user account.

There are several methods to achieve this in Windows. One of the most common built-in methods is the runas command. In addition, third-party tools such as RunAsSpc and RunAsRob can provide more controlled and flexible solutions.

What Is Runas?

runas is a built-in Windows command-line utility that allows a program to be started under a different user account.

For example, a user who is logged in with a standard account can use the runas command to start a specific application with an administrator account.

Basic example:

runas /user:Administrator "C:\Windows\System32\cmd.exe"

When this command is executed, Windows asks for the password of the Administrator account. If the password is entered correctly, Command Prompt opens under that user account.

Runas Command Syntax

The basic syntax of the runas command is as follows:

runas /user:UserName "program_path"

Advanced syntax examples are:

runas /user:UserName program [ [/noprofile | /profile] [/env] [/savecred | /netonly] ]

runas /smartcard [/user:UserName] program [ [/noprofile | /profile] [/env] [/savecred] ]

runas /trustlevel:TrustLevel program

The most commonly used parameters are explained below.

/user:UserName

This parameter specifies which user account will be used to run the program.

The username can be written in different formats:

/user:localuser
/user:localhost\localuser
/user:DOMAIN\domainuser
/user:domainuser@domain.local

For a local user account:

runas /user:localhost\admin "C:\Windows\System32\cmd.exe"

For a domain account:

runas /user:DOMAIN\adminuser "C:\Windows\System32\cmd.exe"

or:

runas /user:adminuser@domain.local "C:\Windows\System32\cmd.exe"

program

This represents the application or executable file that will be started. It can be an .exe file, a management console, a script, or an application that runs with specific parameters.

Example:

runas /user:administrator "C:\Program Files\Application\program.exe"

If the application path contains spaces, it must be enclosed in double quotation marks.

/noprofile

This parameter prevents the selected user profile from being loaded.

Example:

runas /noprofile /user:administrator "C:\Windows\System32\cmd.exe"

This option can make the application start faster. However, some applications may require access to the user profile, AppData folder, registry settings, or user-specific configuration files. In such cases, the application may not work correctly.

/profile

This parameter loads the selected user profile. This is the default behavior.

Example:

runas /profile /user:administrator "C:\Windows\System32\cmd.exe"

This option should be preferred when the application needs user-specific settings.

/env

This parameter uses the current environment variables instead of the environment of the target user.

Example:

runas /env /user:DOMAIN\admin "C:\Windows\System32\notepad.exe"

This can be useful in scripts or automation scenarios where the current user environment needs to be preserved.

/netonly

This parameter uses the specified credentials only for remote access.

Example:

runas /netonly /user:DOMAIN\admin "C:\Windows\System32\cmd.exe"

This option does not fully run the local process as the specified user. Instead, it uses the provided credentials when accessing remote resources.

For example, a user may continue working with their local standard account while using different credentials to access a network share or domain resource.

/savecred

This parameter saves the provided credentials in Windows Credential Manager.

Example:

runas /user:administrator /savecred "C:\Windows\System32\cmd.exe"

When this command is executed for the first time, Windows asks for the password. After the password is entered successfully, the credential is saved. On the next run, the password is not requested again.

Example for running a specific application:

runas /user:myadmin /savecred "C:\Path\Program.exe"

This may look practical, but it must be used very carefully. Credentials saved with /savecred are not limited to only one application. The same saved credential can potentially be used to run other applications with the same account.

This means that a standard user may be able to start not only the allowed application but also other programs with the saved administrator credentials. This creates a serious security risk.

/smartcard

This parameter is used when credentials are provided through a smart card.

Example:

runas /smartcard /user:DOMAIN\admin "C:\Windows\System32\cmd.exe"

It is generally used in corporate environments where smart card authentication is required.

/showtrustlevels

This parameter displays the trust levels that can be used with the runas command.

runas /showtrustlevels

/trustlevel

This parameter starts an application with a specific trust level.

runas /trustlevel:Level "program_path"

It can be used to run applications with restricted trust levels. However, for most administrator privilege scenarios, the /user parameter is more commonly used.

Runas Usage Examples

Open Command Prompt as a Different User

runas /user:administrator "C:\Windows\System32\cmd.exe"

This command opens Command Prompt as the administrator user.

Open CMD with the Local Administrator Account

runas /noprofile /user:localhost\administrator "C:\Windows\System32\cmd.exe"

This command uses the local administrator account on the machine.

Open Computer Management with a Domain Admin Account

runas /profile /env /user:DOMAIN\admin "mmc %windir%\system32\compmgmt.msc"

This command opens the Computer Management console with a domain administrator account.

Open Notepad as a Different User

runas /env /user:user@domain.local "C:\Windows\System32\notepad.exe"

Run a Specific Application with an Administrator Account

runas /user:administrator "C:\Path\Program.exe"

If the program needs to be started with a parameter:

runas /user:administrator "C:\Path\Program.exe parameter"

Is It Possible to Pass the Password Directly with Runas?

One of the most common questions about runas is:

“Can I write the password directly inside the command and run the application automatically?”

For example, some users may try the following command:

runas /user:administrator /password:password "C:\Windows\System32\cmd.exe"

However, this does not work. The built-in Windows runas command does not support a direct /password parameter.

The main reason is security. Writing a password directly in the command line is dangerous because the password may be visible in command history, script files, process monitoring tools, or logs.

For this reason, runas asks for the password interactively.

Using Runas with /savecred

If you do not want the password to be requested every time, the /savecred parameter can be used.

Example:

runas /user:administrator /savecred "C:\Windows\System32\cmd.exe"

The password is requested only during the first run. After it is entered successfully, Windows stores it in Credential Manager. On subsequent runs, the password is not requested again.

Example:

runas /user:myadmin /savecred "C:\Path\Program.exe"

This method can be useful when a standard user needs to start a specific program with an administrator account.

However, there is a very important security concern: credentials stored with /savecred are not tied only to the target application. The same saved administrator credential can be used to run other applications as well.

Security Risk of /savecred

The /savecred option is easy to use but risky from a security perspective.

For example, assume that you want a user to run only a camera monitoring application with administrator privileges. If the administrator credential has been saved with /savecred, the user may try to run another application with the same saved credential.

For example:

runas /user:administrator /savecred "C:\Windows\System32\cmd.exe"

This would allow the user to open an administrator Command Prompt. From that point, the user may gain broad control over the system.

Therefore, /savecred should only be used in trusted, controlled, and low-risk scenarios. In corporate environments, more restrictive and auditable solutions should be preferred.

What Is RunAsSpc?

RunAsSpc is a third-party tool used to run a specific program with a different user account. It works similarly to the runas command but provides additional functionality.

With RunAsSpc, the password can be passed directly as a parameter, or the login information can be stored in an encrypted .spc file.

Basic usage example:

runasspc.exe /user:myadmin /password:"password" /program:"C:\Path\Program.exe"

This command starts the specified program with the myadmin user and the provided password.

However, writing the password directly in the command line is not recommended. The password may be visible inside script files, command history, process listings, or other monitoring tools.

For this reason, using an encrypted .spc file is a safer approach.

Using an Encrypted File with RunAsSpc

One of the safer methods provided by RunAsSpc is storing the user credentials and authorized application information in an encrypted .spc file.

This file can be created with the graphical tool called RunAsSpcAdmin.

The encrypted file may contain information such as:

• Username
• Password
• Domain or local computer name
• Authorized application path
• Application parameters

After the encrypted file is created, the application can be started with the following command:

runasspc.exe /cryptfile:"C:\Path\AnyApplicationWithCredentials.spc"

The advantage of this method is that the password is not written openly in the command line. In addition, the .spc file can be prepared for a specific application, which makes the authorization more controlled.

Example command to create a .spc file:

runasspc.exe /cryptfile:"C:\Path\Application.spc" /domain:localhost /user:admin /password:"password" /program:"C:\Windows\System32\cmd.exe"

A separate encrypted file can be created for each application. This makes it possible to define different authorization files for different programs.

RunAsSpc Usage Scenario

Assume that standard users in a company need to run a camera monitoring application that requires administrator privileges. Instead of giving those users local administrator rights, a dedicated .spc file can be created for that application.

Example command:

runasspc.exe /cryptfile:"C:\Tools\CameraApp.spc"

This command can be added to a shortcut or batch file. When the user clicks the shortcut, only the authorized application is started with the specified administrator account.

This method is more controlled than using runas /savecred, because the goal is not to allow all applications to run with administrator privileges. The goal is to allow only one specific application to run with elevated rights.

Advantages of RunAsSpc

RunAsSpc provides several advantages:

• The standard user does not need to be added to the local Administrators group.
• Specific applications can be started with an administrator account.
• Encrypted .spc files can be used.
• Separate authorization files can be created for different applications.
• It can be used as a portable tool.
• It does not require installation.
• It can be integrated into shortcuts, batch files, or scripts.

However, it is important to remember that administrator credentials are still being used in the background. Therefore, file permissions, folder access, and user rights must be configured carefully.

Security Recommendations for RunAsSpc

When using RunAsSpc or similar tools, the following security measures should be considered:

1. Do not store .spc files in public or insecure folders.
2. Restrict file and folder permissions with NTFS permissions.
3. Use an account that has only the minimum required permissions.
4. Do not use Domain Admin accounts for application elevation.
5. Use strong password policies for local administrator accounts.
6. Allow access only to the required application.
7. Avoid writing passwords directly in the command line.
8. Protect the application path so that users cannot replace the executable.
9. Make sure shortcuts or batch files cannot be modified by standard users.
10. Enable logging and auditing where possible.

In corporate environments, these solutions should be reviewed together with security teams, system administrators, and privilege management policies.

RunAsRob as an Alternative

RunAsRob is another tool used for similar purposes. However, it follows a different approach compared to RunAsSpc.

In some scenarios, RunAsRob can temporarily place the user account itself into the local Administrators group. This allows the application to run with elevated rights while still using the user’s own profile.

The advantage of this approach is that:

• The user’s own profile settings are preserved.
• Printers, network shares, NTFS permissions, and user-specific registry settings remain unchanged.
• The application can run in the context of the user’s own session.
• Specific program paths or folders can be authorized.

RunAsRob can also allow certain applications to run under the SYSTEM account. The SYSTEM account has more privileges on the local machine than a standard administrator account. Therefore, this option must be used very carefully.

Processes running as SYSTEM are not blocked by UAC and can access many protected system directories. This can be useful for maintenance operations, backup tasks, monitoring tools, driver installation, software updates, or other system-level jobs. However, if configured incorrectly, it can create serious security risks.

Comparison of Runas, RunAsSpc, and RunAsRob

Method	Advantage	Disadvantage
Runas	Built into Windows, no installation required	Cannot pass the password directly, limited automation
Runas /savecred	Does not ask for the password after the first run	Saved credentials may be used for other applications
RunAsSpc	Can use encrypted files for specific applications	Third-party tool, must be configured carefully
RunAsRob	Can run applications using the user’s own profile	Incorrect configuration may create serious security risks
Scheduled Task	Built-in Windows method, controlled execution	Requires careful initial configuration

Another Secure Alternative: Task Scheduler

In some cases, Windows Task Scheduler can be used instead of third-party tools.

A scheduled task can be created with administrator credentials and configured to run only a specific application. A standard user can then trigger that task without knowing the administrator password.

Example command to run a scheduled task:

schtasks /run /tn "ApplicationRunAsAdmin"

This method can be useful for maintenance tasks, service restart scripts, or specific administrative operations.

The important point is that the task must be configured to run only the intended application or script, and standard users must not be allowed to modify the task configuration.

Recommended Approach in Corporate Environments

In corporate environments, standard users should not be given local administrator rights unless absolutely necessary.

Instead, the following principles should be followed:

• Apply the principle of least privilege.
• Give users only the permissions they actually need.
• Manage local administrator accounts centrally.
• Do not use Domain Admin accounts for end-user applications.
• Prefer application-based authorization.
• Use AppLocker or Windows Defender Application Control where appropriate.
• Log and audit elevated application usage.
• Restrict the file paths that users can execute with elevated permissions.
• Prevent users from modifying scripts, batch files, shortcuts, or executable paths.
• Rotate administrator account passwords regularly.

Example Scenario: Running a Specific Program as Administrator for a Standard User

Assume that users in a company need to run the following application:

C:\Program Files\CameraApp\Camera.exe

The application requires administrator privileges, but the users should not become local administrators.

Risky Method

runas /user:administrator /savecred "C:\Program Files\CameraApp\Camera.exe"

This may work, but the saved credential may also be used to run other applications.

More Controlled Method

Using RunAsSpc, an .spc file can be created only for the required application:

runasspc.exe /cryptfile:"C:\Tools\CameraApp.spc"

This file is prepared specifically for the camera application. The user does not receive the administrator password. This provides a more controlled usage model.

Best Practices

When implementing this type of solution, the following best practices should be followed:

• Never write passwords in plain text inside scripts.
• Avoid using /savecred unless the environment is fully controlled.
• Authorize applications individually.
• Do not give users full local administrator rights.
• Use an account with the minimum required permissions.
• Protect the application directory from user modification.
• Make sure the executable path cannot be replaced by the user.
• Test the solution in a test environment before production use.
• Regularly review logs and elevated execution events.
• Use security tools such as AppLocker, WDAC, or endpoint protection solutions where possible.

There are several ways to run a specific application with administrator privileges in Windows. The built-in runas command is simple and useful, but the /savecred parameter must be used carefully because saved credentials can potentially be reused for other applications.

RunAsSpc provides a more controlled method by allowing credentials and the authorized application to be stored in an encrypted file. RunAsRob offers a different approach by allowing certain applications to run with elevated privileges while preserving the user’s own profile.

Regardless of the method used, the main principle should always remain the same: do not give users more privileges than they need. The goal is not to make the user an administrator, but to allow only the required application to run securely and under control.

For this reason, the best approach is to combine application-based authorization, strong password policies, proper file permissions, logging, auditing, and the principle of least privilege.

Download Link : https://runasspc.com/index.html