the windows os’s Basic Terminology - on sessions, Processes, Services, etc.

The vast majority of computer users utilize the Windows OS. Many of these users however, do not realize the nuances and subtle distinctions of various terms their OS uses to identify their inner workings’ components.

It could be confusing for a novice to figure out the various mechanisms that Windows utilizes and the way they differ from one another.

You may have run into terms such as “tasks”, “processes”, “services” and “jobs” and failed to understand the distinctions between them.

The confusion’s root runs more deeply than the ambiguity of the terms however.

The terminology is derivative, and is the outcome, first and foremost, of the Windows OS’s mechanics, its basic principles of operation, and its underlying logic.

The average user’s lack of understanding of the terms, therefore, stems from his/her lack of understanding of the various Windows methods of operation. Again, the various terms are derived from these methods of operation.

For instance, have you ever wondered to yourself , “Suppose I log into a Windows host with my particular user account, run some processes on it and keep the session active/open while accessing the same host with the very same user remotely. Will the new remote session have all of the processes that have been running on the initial session running as well?”

On sessions

The answer is no, typically each session on a Windows OS operates independently. Processes running in one session won't automatically be visible or accessible on another session, even if it's the same user accessing the system remotely. Each session has its own environment and resources. Each session operates independently, and while they share certain aspects like user settings and preferences, they do not automatically share running processes.

One can however hijack an existing active session, meaning that if you’d left your previous session in a “live” state (basically, by not logging off) you could reconnect to it.

But how can one access an existing local session remotely? Won’t it necessarily be a new session?

Generally, that’s correct. When accessing a Windows session remotely, it typically creates a new session rather than accessing the existing local session. In that case, the new remote session won't have direct access to the processes running in the original local session.

But sessions that are not actively being used are not necessarily obsolete, and you could make use of them, and even reconnect to them

Many times, users will choose to lock their session (by pressing the windows key +L) instead of logging off. Also, when logging via RDP into a remote session, many people would simply close the session’s window once they are done working with it, not realizing that they are actually leaving the session in a live, reusable state. It is important to keep in mind that it is possible to close a session window without logging out of it, and to later reconnect to the very same live session, whether locally or remotely (with the TScon executable).

To terminate a session one must log off of it. Period.

If not logged out of, an active session would remain dormant on the computer, and is vulnerable to being hijacked by another active session

The procedure for doing so is as follows.

• Identifying the active session on the host by utilizing the “quser” or “query user” executable.
  

• Syntax: quser /server:<ip-address/hostname>
  

• This command will output a list of sessions on the host.
  

Sessions labeled as “active” are ones that are currently being used, however any other session labeled as “Disc” is in fact a live session, meaning that its owner-user hasn’t logged out of it, and could potentially be reactivated by connecting to it.

• Once we have the particular session ID that we wish to connect to, we need to use the tscon.exe executable (located in the system32 folder) following the session ID we had previously acquired from the output of the previous command.
  

Syntax: tscon /session: <sessionID/session name> /dest:<your own session ID ie. the one you wish to attach the live, inactive session to>

• Note that to reconnect to an existing live session you first need to have your own active session on the machine. You would then use the tscon command to hijack the other session and merge it with your current session that you had logged on to.
  
• Also note that to do this you would typically need the Disc sessions user password. (Unless certain conditions are present such as you are the system user on the host and the Windows edition permits System users to hijack old sessions without a password.)
  

Once reconnected to the same live session, you will find that:

• Its Network Connections will persist:active network connections established in one session will typically persist when accessing the same user session.
  
• Session State will persist: Any applications or processes left running in the background will continue to run in the same state.
  

Okay, so that is the case when reconnecting to an old session that hadn’t been logged out of. The next logical question one may ask might be, what persists on distinct sessions of the same user's account?

When logging into a whole new session with the same user account, what carries through?

Most people do know that a user’s permissions will remain the same on all of his/her sessions, but is that the only characterization separating one user’s account from the rest of the OS’s users’ sessions?

When accessing different sessions of the same user’s account on a Windows OS, certain aspects do persist:

• Desktop Environment: The desktop layout, wallpaper, icons, and open windows will be the same across sessions for the same user
  

• User Settings and Preferences: User-specific settings and preferences, such as theme settings, browser bookmarks, and application configurations, will remain consistent.
  

However, it's important to stress that this applies to aspects of the user’s environment and settings, but not to individual processes.

Each session operates independently in terms of running processes, meaning that you won't see processes initiated in one session automatically appear in another session, even for the same user.

Processes

A process is basically an action performed or initiated on the OS. It has certain representations (such as a process ID) that can be accessed (for example by the task manager), and it uses up a certain amount of the hardwares resources.

As mentioned, processes running in the background within a user session will continue to run when accessing that session remotely, so in that sense, the state of those processes does persist.

However, new processes initiated in one session won't automatically be visible or accessible in another session of the same user.

Hiding processes

To make processes ( that are either run by a service or independently) more discreet, you can employ several techniques to enhance their privacy and security:

• Use Cryptographic Techniques: Encrypt sensitive data handled by the processes to prevent unauthorized access or interception. Use strong encryption algorithms and secure key management practices to protect data confidentiality.
  
• Minimize Visibility: Configure processes to run with minimal visibility to other users and system monitoring tools. This can involve setting the process priority to low, reducing its resource usage, and minimizing its presence in system logs and monitoring reports.
  
• Obfuscate Process Names: Give processes nondescript or generic names that do not reveal their purpose or functionality. Avoid using names that might attract attention or disclose sensitive information about the process's activities.
  
• Implement Stealth Techniques: Employ stealth techniques to hide processes from detection by system monitoring tools and antivirus software. This can include using process injection, rootkit-like techniques, or hooking system functions to conceal the process's presence from scrutiny.
  
• Limit Process Permissions: Restrict the permissions and privileges of processes to prevent them from accessing sensitive resources or performing unauthorized actions. Use least privilege principles to ensure that processes only have access to the resources they require to function properly.
  
• Monitor Process Activity: Regularly monitor process activity and audit logs to detect any suspicious behavior or unauthorized access attempts. Implement process monitoring tools and anomaly detection mechanisms to alert administrators of potential security breaches.
  
• Secure Communication Channels: Use secure communication channels to exchange data between processes and associated components. Employ encryption and authentication mechanisms to protect data integrity and confidentiality during transit.
  

svchost.exe

svchost.exe is a legitimate system process on the Windows operating systems that hosts multiple Windows services. It's a common target for malware because it's an essential system process, and it's normal to see multiple instances of svchost.exe running simultaneously.

svchost.exe processes are a common occurrence and are often used to hide other processes.

Svchost.exe characteristics:

• Hosts Processes for Services: svchost.exe is a generic host process that loads and runs multiple Windows services as dynamic-link libraries (DLLs). Instead of each service having its own individual process, multiple services are grouped together and run under a single instance of svchost.exe. This helps conserve system resources and improves system performance.
  
• Service Grouping: Services with similar security requirements and dependencies are grouped together and run under the same instance of svchost.exe. This grouping is determined by configuration settings in the Windows Registry.
  
• Identification: To identify which services are hosted by a particular instance of svchost.exe, you can use tools like Task Manager, Process Explorer, or the command-line utility tasklist (“tasklist /svc”). These tools provide information about the services running within each instance of svchost.exe.
  
• Potential for Abuse: Because svchost.exe is a legitimate system process and often runs with elevated privileges, malware authors may attempt to disguise their malicious activities by injecting their code into a legitimate instance of svchost.exe. This allows malware to evade detection and operate undetected within the system.
  

To mitigate the risks associated with svchost.exe and prevent abuse by malware, it's essential to:

• Keep your operating system and security software up to date to patch vulnerabilities.
  
• Use reputable antivirus and antimalware software to detect and remove malicious software.
  
• Monitor system activity using security monitoring tools to detect suspicious behavior.
  
• Be cautious when downloading and installing software from untrusted sources.
  
• Regularly review and audit the list of services running on your system to identify any anomalies or unauthorized activities.
  

On the flip side, if I want to create a service and have it run by the svchost.exe, thereby somewhat hiding it, how would I go about it?

if you want your service to run under svchost.exe, you would include it as a DLL. svchost.exe hosts services implemented as DLLs, so your service code would need to be compiled into a DLL format. Then, you would register your service DLL with the SCM, specifying the appropriate configuration settings and grouping information.

Creating a service to run under svchost.exe involves configuring the service appropriately and registering it with the Service Control Manager (SCM) to be hosted by svchost.exe. Here's a general outline of the steps involved:

• Create the Service: Develop your service application. This could be a standalone executable or a DLL that contains the service implementation.
  
• Service Registration: Register your service with the SCM using a unique service name and appropriate configuration settings. This involves creating entries in the Windows Registry under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
  
• Grouping Services: Determine which svchost.exe group your service should belong to. Services with similar characteristics are grouped together to run under the same svchost.exe instance. You can specify this grouping in the Registry settings for your service.
  
• Start the Service: Once registered, start the service using the Service Control Manager (services.msc) or command-line tools like sc.
  
• Monitor Service: Monitor the service's behavior using system monitoring tools and audit logs to ensure it's functioning as expected.
  

It's important to note that while running a service under svchost.exe may provide some level of obscurity, it does not guarantee complete invisibility. Malware and security researchers are aware of this technique, and sophisticated monitoring tools can still detect and analyze services running under svchost.exe.

services

Certain situations do call for non-session dependent processes, processes that will carry through between separate sessions.

Moreover there are situations where you’d like processes to persist across all of the active sessions, regardless of the users’ accounts.

This is where services come into play.

The very definition of a service, as opposed to a process, is that it persists on different sessions

Services are designed to run in the background and can persist across different user sessions and system reboots. They are intended to provide functionality or perform tasks that operate independently of any particular session.

Once started, a non-user specific service will continue running until it is explicitly stopped or the system is shut down, regardless of which user is logged in or whether any user session is in an active state at all.

However, If a service is configured to run under a specific user account and is set to start automatically or manually, it will persist across different sessions for that user and any other logged in users, but under the configured user context and permissions, regardless of which user is currently logged in. . Once started, it will continue running until it is stopped or the system is restarted, regardless of which session is currently active nor of which user is currently logged on.

When a service is initialized, it typically spawns one or more processes to carry out its tasks. Each service can have one or more associated processes responsible for executing the service's code and handling its functionality

So the initialization of a service usually involves the creation of one or more processes to execute the service's code. These processes are spawned by the service manager (services.exe) when it starts the service.

To create a service on a Windows system, you would typically follow these steps:

• Create a Service: You can create a Windows service using tools like the sc command-line tool or the New-Service cmdlet in PowerShell. When creating the service, specify the user account under which the service should run. This user account will determine the user context in which the service operates.
  
• Assign User Permissions: Ensure that the user account specified for the service has the necessary permissions to execute the desired tasks. This might include permissions to access certain files or resources.
  
• Configure Startup Type: Set the startup type of the service to either Automatic or Manual based on your requirements. This determines whether the service starts automatically when the system boots up or requires manual intervention to start.
  
• Start the Service: Once configured, start the service either through the Services management console (services.msc) or using command-line tools like net start <ServiceName>.
  

By following these steps, you can create a service that operates in the context of a specific user account rather than a session. This allows the service to perform tasks on behalf of that user, even if the user is not currently logged in.

When creating a service with the sc command you can also specify arguments for the executable. These arguments are passed to the executable when the service is started and you include them after the executable's path in the binPath parameter when creating the service. Here's the general syntax:

sc create <SERVICE_NAME> binPath= <"EXECUTABLE_PATH> <”ARGUMENTS">

For example, if you want to create a service named "MyService" that runs my_executable.exe with the arguments -arg1 -arg2, you would use the following command:

sc create MyService binPath= "my_executable.exe -arg1 -arg2"

This command instructs the system to start my_executable.exe with the specified arguments when the "MyService" service is started. Make sure to enclose the executable path and arguments in double quotes if they contain spaces or special characters.

So to reiterate:

• Services: Services can run in the background and are not tied to any specific user session. While you can configure services to run under specific user accounts they are not inherently tied to a particular user's session and will run across sessions of all of the users but in the context of the configured user account. Services can run regardless of whether any user is logged in.
  
• Processes: Processes are specific instances of programs running on a computer. When a user launches a program, it creates a process associated with that user's session. Processes are indeed user-dependent and are confined to the user's session. They do not persist across sessions and are terminated when the user logs out or the session ends.
  

The way you'd limit a service to a specific user’s context and permissions is to assign it to a specific user or create it as said user.

When you create or configure a service, you can specify the user account under which the service should run. This is done during the service creation process or by modifying the service properties after it's created.

Here's how you can assign a service to a specific user account:

• During Service Creation: When creating the service, you specify the user account using the appropriate parameter or option. For example, using the “sc” command-line tool:
  

Syntax: sc create <ServiceName> binPath= <"C:\Path\to\Your\Service.exe"> obj= <"Domain\User"> password= <"UserPassword">

• Using Service Properties: If the service has already been created, you can modify its properties to change the user account it runs under. This can typically be done through the Services management console (services.msc) or using command-line tools like sc.
  

By assigning the service to a specific user account, you ensure that it runs in the context of that user, with the associated permissions and privileges.

Hiding services

You may want to run your own services discreetly without other users being able to query it or figure out what it's doing for various reasons.

If you want a service to run discreetly on your sessions you can take several measures to enhance its privacy and security:

• Restrict Access: Configure the service to run under a user account with limited permissions. Ensure that only trusted users have access to the service's executable files and configuration settings.
  
• Obfuscate Service Names: Give the service a nondescript or generic name that doesn't reveal its purpose. Avoid using names that might attract attention or reveal sensitive information about the service's function.
  
• Hide Service Status: Set the service to run as a "hidden" service, which prevents it from appearing in the list of services in the Services management console (services.msc).
  

This makes it less conspicuous to other users.

To configure a service to be hidden, you can set its service type to SERVICE_TYPE_NO_DISPLAY using the sc command-line tool. When a service is marked as "no display," it will not appear in the Services management console (services.msc) and will be hidden from most users. However, it may still be visible to users with administrative privileges and can be queried using certain command-line tools.

Syntax: sc config <ServiceName> type= own type= interact type= kernel start= demand

Explanation of parameters:

• type= own: Specifies that the service is to be started by its own process.
  
• type= interact: Specifies that the service can interact with the desktop (required for some services).
  
• type= kernel: Specifies that the service is a kernel driver (not applicable for most services).
  
• start= demand: Specifies that the service should be started manually.
  

This configuration hides the service from the Services management console (services.msc). However, it may still be visible to certain command-line tools such as tasklist and sc query. To further conceal the service from these tools, additional measures may be required, such as modifying access permissions or employing advanced security techniques..

• Monitor Access: Regularly monitor access to the service and audit its usage to detect any unauthorized activity or attempts to query its status. Implement logging mechanisms to record relevant events and activities related to the service.
  
• Encrypt Communication: If the service communicates with other systems or processes, ensure that communication is encrypted to prevent eavesdropping or interception of sensitive data.
  
• Implement Security Measures: Employ security best practices such as strong authentication, access controls, and encryption to safeguard the service and its associated resources from unauthorized access or tampering.
  

By implementing these measures, you can enhance the privacy and security of the service, making it more difficult for other users to query or discern its activities.