4.1 Windows and Linux Architecture, Auth, Filesystems, Processes

Kernel Mode Versus User Mode

Every modern operating system splits execution into kernel mode and user mode. Kernel mode (ring 0 on typical x86 designs) can program the memory manager, talk to devices, and see every process. User mode (ring 3) is where browsers, office apps, shells, and almost every business service run. When user-mode code needs a privileged action—create a process, bind a port, read a protected file—it issues a system call. The kernel enforces access checks and either performs the work or returns an error.

That split is a security control, not trivia. Code that stays in user mode can still steal files and tokens, but a malicious driver or kernel implant can hide processes, strip logs, and lie to Endpoint Detection and Response (EDR) tools. As a Security Operations Center (SOC) Level 1 analyst you will not reverse the kernel on day one. You will decide whether an alert is an ordinary user-mode crash or privileged activity: a driver load, a service running as Local System, or a process that should never open LSASS (Local Security Authority Subsystem Service).

Why the boundary matters in triage

A help-desk crash dump of excel.exe is usually noise. An unknown binary opening lsass.exe, writing under C:\Windows\System32\drivers, or calling insmod on Linux is privileged until proven otherwise. On Linux, compiling in /home is expected; writing to /lib/modules is not. Ask two questions on every endpoint alert: what privilege does this process already have, and did it cross the kernel boundary or only touch another user-mode process?

Windows NT Architecture

Windows NT is the architecture behind current Windows client and Server editions. Layers, from the metal up:

1. Hardware, then the Hardware Abstraction Layer (HAL) so one kernel can run on different chipsets.
2. The NT kernel and Executive (ntoskrnl.exe): process and thread manager, virtual memory, I/O manager, object manager, and the Security Reference Monitor that evaluates access checks against security descriptors.
3. Kernel-mode device drivers.
4. User-mode system processes that do not own a desktop: smss.exe (session manager), csrss.exe (Client/Server Runtime Subsystem for Win32), winlogon.exe (interactive logon), lsass.exe, services.exe (Service Control Manager, SCM), and many svchost.exe hosts.
5. Interactive applications such as explorer.exe.

Winlogon presents the logon desktop and passes credentials to LSASS. LSASS talks to the local Security Account Manager (SAM) for local accounts or to a domain controller for domain accounts. services.exe rarely hosts every service itself. It starts service processes, often as svchost.exe instances that share one process among related services. A svchost.exe whose image path is C:\Windows\System32\svchost.exe is normal. A svchost.exe launched from C:\Users\Public is not. Name collisions are a daily trick: malware drops lsass.exe next to a user folder while the real Local Security Authority remains in System32.

Linux Kernel and Userspace

Linux uses a monolithic kernel with loadable kernel modules. Privileged work happens in kernel space; everything else is userspace. Process ID 1 is the init system. On most current distributions that is systemd. Systemd starts unit files (services, sockets, timers), then daemons: sshd for remote shells, cron or crond for scheduled jobs, logging services, and user sessions. Older appliances may still boot System V init with /etc/init.d/ scripts and runlevels; treat those as the same idea with a different control channel.

Commands such as ls, cat, and sudo are ordinary userspace binaries. sudo is special because of its set-user-ID (SUID) bit, covered with permissions below. Analysts live in userspace logs (auth.log, journald) unless the case involves kernel modules. A user compiling in a home directory is expected. A user writing to /lib/modules or loading a module is a privilege story.

Authentication Stores: SAM Versus passwd and shadow

On a standalone Windows host, local accounts live in the SAM database, typically %SystemRoot%\System32\config\SAM. Windows stores NT hashes (and historically LAN Manager hashes, which you should treat as legacy and high risk if still present). The live SAM file is locked while Windows is running. Offline copies still need the SYSTEM hive to decrypt. A workstation does not hold a full replica of every domain password in SAM. It may cache some domain logons and otherwise asks a domain controller.

Linux splits identity from secrets:

• /etc/passwd is world-readable. It holds username, user ID (UID), group ID (GID), home directory, and login shell. The password field is usually x, meaning the hash is in shadow.
• /etc/shadow is readable only by root (and sometimes the shadow group). It holds the password hash (commonly SHA-512 crypt $6$ or yescrypt), last-change day, and aging fields.
• /etc/group maps group names to GIDs and membership.

If /etc/shadow is world-readable, that is a finding by itself. If passwd shows UID 0 on an unexpected name, that account is root-equivalent. A disabled Linux password often appears as ! or * in shadow; that is not the same as an empty hash.

NTLM versus Kerberos at a conceptual level

NTLM is a challenge-response family used for local logons, workgroup hosts, and many fallback cases. The client proves knowledge of the NT hash without sending the password. Because the hash is the authenticator, a stolen NT hash can be replayed against NTLM services. You will still see NTLM on printers, older applications, and local SAM logons.

Kerberos is the default for Active Directory (AD) domain authentication. Instead of proving a hash to every server, the user obtains tickets from a Key Distribution Center (KDC) on a domain controller: a ticket-granting ticket (TGT), then ticket-granting service (TGS) tickets for individual services. Section 4.2 walks that flow at analyst level. Remember the split: SAM plus NTLM for local Windows identity; Kerberos (with NTLM fallback) for domain identity; passwd and shadow for Linux local identity. Do not treat NTLM as unused just because the domain prefers Kerberos.

Filesystems and Permissions

NTFS is the default Windows filesystem. It supports journaling, per-object discretionary access control lists (DACLs), auditing system access control lists (SACLs), the Encrypting File System (EFS), compression, and alternate data streams (ADS) that can hide extra content on a file. A document named invoice.pdf with an ADS invoice.pdf:payload.exe is a classic analyst miss if you only hash the default stream.

ext4 is the common Linux default. It is a journaling filesystem with extents. Access control starts with POSIX mode bits, not Windows ACLs:

• Three triples: owner, group, other.
• Each triple is read, write, execute (rwx).
• Extra bits: SUID (run as the file owner, often root), SGID (run as the group, or inherit group on directories), and the sticky bit on /tmp so users cannot delete one another's files.

/usr/bin/passwd is typically mode 4755—SUID root plus rwxr-xr-x. That is expected so unprivileged users can change their own password. SUID copies of bash or python3, or any SUID file under /tmp, are persistence or privilege-escalation leads. Optional POSIX access-control lists exist on many Linux volumes; if getfacl shows extra named users, the simple ls -l triple is incomplete.

Auth stores and filesystem traits

Services and the Common Process Roster

Windows services are background programs registered with the SCM. They often run as Local System, Local Service, or Network Service, start at boot, and have no interactive desktop. Image paths live under HKLM\SYSTEM\CurrentControlSet\Services\<name>. Linux equivalents are systemd units (*.service files) in /lib/systemd/system (package defaults) and /etc/systemd/system (admin overrides), or leftover /etc/init.d/ scripts. A new unexpected Windows service or systemd unit is a persistence lead. Event ID 7045, covered in the next section, exists because service installation is worth logging.

Windows processes you should recognize on sight:

• lsass.exe — Local Security Authority; authentication and in-memory secrets.
• winlogon.exe — interactive logon orchestration.
• svchost.exe — generic host for many SCM services; path must stay under System32.
• explorer.exe — user shell. A missing explorer can be a crashed session; extra explorers with odd paths can be decoys.

Linux processes you should recognize:

• systemd — PID 1 on modern distros; parent of most daemons.
• sshd — Secure Shell daemon, typically listening on TCP/22 unless administrators moved it. Privilege-separated children are normal.
• cron / crond — scheduled tasks. Check /etc/crontab, /etc/cron.d/, and user crontabs, not only the running process name.

Worked example: why dumping LSASS is high-signal

Workstation ACCT-14 shows cmd.exe launching rundll32.exe with comsvcs.dll MiniDump against the LSASS process ID, writing C:\Users\Public\lsass.dmp. You do not need to open the dump to know this is not a backup job.

LSASS caches material Windows uses to keep a logon alive: NT hashes, Kerberos tickets, and sometimes single sign-on secrets. A memory dump of that process is credential access, not a performance trace. Legitimate vendors almost never MiniDump LSASS into Users\Public. Follow-on behavior is usually lateral movement with the stolen hash or ticket. On Linux the closest analog is an unprivileged read of /etc/shadow or dumping memory of sshd or an agent that holds keys—still high-signal, but the LSASS dump is the Windows pattern SOC queues light up first. Pair the dump with the parent process and image path: procdump from a software-distribution folder during a documented EDR troubleshooting window is a different ticket than rundll32 from a world-writable directory at 02:00.

Analyst traps

• Do not treat every svchost.exe as malware; check the full image path and parent process.
• Do not assume /etc/passwd exposure equals password theft; the hashes live in shadow.
• Do not call NTLM unused. Domain estates still emit NTLM, and local SAM logons depend on it.
• Do not skip Linux SUID review because the kernel looks hardened. Privilege often starts at a userspace binary with the SUID bit set.