HTB Academy - Windows Sessions and Subsystem
HTB Academy - Windows Sessions and Subsystem: iInteractive An interactive, or local logon session, is initiated by a user authenticating to a local or domain system by entering their credentials. An interactive logon can be initiated by logging directly into the system, by requesting a secondary logon session using the runas command via the command line, or... • HTB Academy • htb-academy, module-49
get-LocalGroup | ft Name, SIDiInteractive
An interactive, or local logon session, is initiated by a user authenticating to a local or domain system by entering their credentials. An interactive logon can be initiated by logging directly into the system, by requesting a secondary logon session using the runas command via the command line, or through a Remote Desktop connection.
Non-interactive
Non-interactive accounts in Windows differ from standard user accounts as they do not require login credentials. There are 3 types of non-interactive accounts: the Local System Account, Local Service Account, and the Network Service Account. Non-interactive accounts are generally used by the Windows operating system to automatically start services and applications without requiring user interaction. These accounts have no password associated with them and are usually used to start services when the system boots or to run scheduled tasks.There are differences between the three types of accounts:
Account Description Local System Account Also known as the `NT AUTHORITY\SYSTEM` account, this is the most powerful account in Windows systems. It is used for a variety of OS-related tasks, such as starting Windows services. This account is more powerful than accounts in the local administrators group. Local Service Account Known as the `NT AUTHORITY\LocalService` account, this is a less privileged version of the SYSTEM account and has similar privileges to a local user account. It is granted limited functionality and can start some services. Network Service Account This is known as the `NT AUTHORITY\NetworkService` account and is similar to a standard domain user account. It has similar privileges to the Local Service Account on the local machine. It can establish authenticated sessions for certain network services. Windows Subsystem for Linux (WSL)
WSL is a feature that allows Linux binaries to be run natively on Windows 10 and Windows Server 2019. It was originally intended for developers who needed to run Bash, Ruby, and native Linux command-line tools such as sed, awk, grep, etc., directly on their Windows workstation. The second version of WSL, released in May 2019, introduced a real Linux kernel utilizing a subset of Hyper-V features.
WSL can be installed by running the PowerShell command `Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux` as an Administrator. Once this feature is enabled, we can either download a Linux distro from the Microsoft Store and install it or manually download the Linux distro of our choice and unpack and install it from the command line.
```sql
```sql
WSL installs an application called `Bash.exe`, which can be run by merely typing `bash` into a Windows console to spawn a Bash shell. We have the full look and feel of a Linux host from this shell, including the standard Linux directory structure.PS C:\htb> ls / bin dev home lib lLib64 media opt root sbin srv tmp var boot etc init 1lib32 Libx32 mnt proc run Snap sys usr
```sql
```sql
We can access the C$ volume and other volumes on the host operating system via the mnt directory, making the transition from the WSL host and the Windows host OS seamless. Once in this bash shell, we can interact with WSL as we would interact with any Linux-based operating system: running commands, installing updates/packages, etc.PS C:\htb> uname -a Linux WS01 4.4.0-18362-Microsoft #476-Microsoft Frit Nov 01 16:53:00 PST 2019 x86_64 x86 _64 x86_64 GNU/LinuxSecurity Identifier (SID)
Each of the security principals on the system has a unique security identifier (SID). The system automatically generates SIDs. This means that even if, for example, we have two identical users on the system, Windows can distinguish the two and their rights based on their SIDs. SIDs are string values with different lengths, which are stored in the security database. These SIDs are added to the user's access token to identify all actions that the user is authorized to take. A SID consists of the Identifier Authority and the Relative ID (RID). In an Active Directory (AD) domain environment, the SID also includes the domain SID.
PS C:\htb> whoami /user USER INFORMATION ---------------- User Name SID =================== ============================================= ws01\bob S-1-5-21-674899381-4069889467-2080702030-1002
The SID is broken down into this pattern.
(SID)-(revision level)-(identifier-authority)-(subauthority1)-(subauthority2)-(etc)List all users sid you could use
wmic useraccount get name,sidCreate a local user
New-LocalUser -Name "User02" -Description "Description of this account." -NoPasswordList all users
Get-WmiObject win32_useraccount | Select name,sidList All groups
get-LocalGroup | ft Name, SIDGet Serial number of system with WMI
Get-WmiObject win32_bios | select Serialnumber
All different ways of collect info below
(SID)-(revision level)-(identifier-authority)-(subauthority1)-(subauthority2)-(etc)List all users sid you could use
wmic useraccount get name,sid wmic bios get SerialNumber Get-WmiObject win32_bios | select Serialnumber Get-WmiObject win32_bios | select pscomputername,serialnumber,name wmic bios get serialnumber Get-CimInstance Win32_BIOS Get-WmiObject -Class Win32_OperatingSystem | select SystemDirectory,BuildNumber,SerialNumber,Version | ft