> ## Documentation Index
> Fetch the complete documentation index at: https://siriusbar.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Phase 1 — Windows Fundamentals

> A Linux person's first contact with Windows: PowerShell objects, WMI, and reaching the box over RDP.

As a seasoned Linux person (and of course a security researcher :)), I never really wanted to dig into Windows systems. Lately that has started to change. For some reason, I feel this sudden burning curiosity, so this is the start of a short, practical series where I map what I already know from the Linux kernel and userland onto how Windows actually works.

> My main goal across these four phases is `mapping` my Linux knowledge to Windows internals, and being honest about where that mapping breaks.

Before any of the deep internals, we need one mental model that colours everything else. Linux lives by **"everything is a file"**. Windows does not. Windows leans on **"everything is an object"**, and we will see that idea leak into places we would not expect, starting with the shell. We come back to it properly in Phase 4.

## A graphical shell that grew a kernel

The first version of Windows was a graphical operating system shell sitting on top of `MS-DOS`. That framing helps: early Windows was closer to a desktop environment bolted onto a separate OS than to a kernel in its own right. The Windows we care about today runs on the `NT` kernel, but the historical shape still shows: a lot of the system is reached through tooling and a GUI rather than through plain files in a tree.

So the starting mapping is simple: kernel, userland, and a shell I trust. On Windows the shell is the first thing that feels different, so that is where we start.

## PowerShell is not bash with different command names

It is tempting to read PowerShell as "bash, but Microsoft". That mapping breaks almost immediately.

In bash, the pipeline carries **text**. Every tool reads bytes, writes bytes, and we spend our lives in `grep`, `awk`, and `cut` reassembling structure out of that text. In PowerShell the unit is the `cmdlet`, a lightweight command for the PowerShell environment, and a cmdlet does not return text. It returns a **Microsoft .NET object** to the pipeline.

* `cmdlet`: a small `Verb-Noun` command (like `Get-Process`) backed by a .NET class.
* the pipeline: passes structured objects with properties and methods, not a flat byte stream.

That is the "everything is an object" philosophy showing up before we even touch the kernel.

```powershell theme={null}
# bash instinct: text out, then carve it up
# ps aux | grep firefox | awk '{print $2}'

# PowerShell: the objects already carry the fields
Get-Process firefox | Select-Object Id, Name
```

> When something looks like text in PowerShell, it is usually an object that printed itself. The question stops being "which column do I `awk`?" and becomes "which property do I select?".

## WMI: one query interface for the whole machine

On Linux, asking the system about itself means a scattered toolbox: `ps` for processes, `systemctl` for services, `dmidecode` for firmware, `uname` and `/etc/os-release` for the OS, plus a lot of reading under `/proc` and `/sys`.

Windows centralises much of that into `WMI` (Windows Management Instrumentation). One classic way in is the `Get-WmiObject` cmdlet, which queries `Win32_*` classes:

* `Win32_Process`: process listing — the `ps` view.
* `Win32_Service`: service listing — the `systemctl list-units` view.
* `Win32_Bios`: firmware information — roughly `dmidecode`.
* `Win32_OperatingSystem`: OS version and build — roughly `uname -a` plus `/etc/os-release`.

```powershell theme={null}
Get-WmiObject Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber
```

Because these are objects, the `-ComputerName` parameter lets us aim the same query at another machine over the network, without opening a shell on it. The instinct is `ssh host 'command'`; here the query itself travels over RPC/DCOM and comes back as objects.

> One honest note: `Get-WmiObject` is the old door. Modern Windows and PowerShell push us to `Get-CimInstance`, which queries the same classes over `WS-Man` instead of legacy DCOM. The mental model is identical; only the transport changed.

For a security researcher this is the first real recon surface. `Get-CimInstance Win32_Process -ComputerName target` is process enumeration on a remote host, and remote WMI is something both attackers and defenders watch closely.

## RDP: the GUI is the remote shell

On Linux, "remote access" defaults to `SSH`: a text session on port `22`, usually with `sshd` already running. Windows inverts both halves of that.

The default remote model is `RDP` (Remote Desktop Protocol). Instead of a text shell, it ships the actual graphical desktop to us. The server listens on port `3389`.

```text theme={null}
Client (connecter)                              Server (connected)
  [ PC ]  ─────────────▶  172.16.200.11:3389  ─────────────▶  [ PC ]
```

Two differences matter here:

* RDP is **graphical first**. The remote experience is the desktop, not a pipe of text.
* RDP is **not allowed by default**. Unlike a box already running `sshd`, a fresh Windows install does not accept remote desktop until someone turns it on.

> So when we find `3389` open on a Windows host, that is a deliberate decision someone made. Normally I read an open port as "a daemon is listening"; here it also means "remote desktop was enabled", which is a meaningful fact during recon.

That is enough to move around and talk to a Windows box. In Phase 2 we walk the filesystem and see how to read the `C:\` tree.