FFoundationalGeneral
Windows Processes and Threads
Processes and threads are the basic units of execution on every Windows machine. This lesson explains what they are, how the parent-child relationships between them work, and why this mental model underpins almost everything you will later say about detection, persistence, and attack analysis.
Why it matters
Almost every meaningful event on a Windows machine is a process doing something. When a defender investigates an alert, an attacker establishes persistence, or an analyst reconstructs what happened during an incident, they are reasoning about processes and the relationships between them. If you cannot describe a process clearly, you cannot explain most of what happens on Windows.
This is foundational vocabulary. Concepts you will meet later, process injection, parent-process spoofing, living-off-the-land binaries, suspicious process trees, all assume you already know what a process and a thread are, and how one process comes to start another. Getting this right early makes every downstream explanation sharper and more credible.
Key Concepts
- Process — what a program becomes once Windows loads it into memory and gives it resources to run; it owns the address space, handles, and security context its code runs inside
- Thread — a single stream of execution working inside a process; one process can hold many threads at once, all sharing the process's resources
- Parent-child relationship — when one process starts another, the starter is the parent and the new process is the child; this lineage is the basis of process-tree analysis
- Process Identifier (PID) — a number Windows assigns to each running process so it can be referenced, filtered, and terminated; the System process is always PID 4
- User mode vs Kernel mode — two privilege levels the CPU runs in; kernel mode has direct hardware access for trusted OS operations, while user mode runs ordinary applications without it
Theory
Core idea
A process is what a program becomes once Windows loads it into memory and gives it the resources to run: its own address space, open handles, and security context. A thread is a single stream of execution working inside that process. Put plainly, the program is the instructions sitting on disk, the process is the live environment those instructions get loaded into, and the thread is the activity actually carrying them out. One process can run many threads at the same time, all sharing that process's memory and security context.
The second half of the idea is lineage. When one process starts another, the starter is the parent and the new process is the child. This relationship is what lets you read a system as a tree rather than a flat list. A web browser launching a calculator is unremarkable; a document viewer launching a command shell is the kind of parent-child pairing that makes an analyst stop and look closer.
Mental model
A clean way to carry this into an interview is to picture a kitchen. The program is a recipe written on a card; the process is the kitchen set up and stocked to actually cook it; and each thread is a cook working in that kitchen. The recipe does nothing on its own; it only comes alive once a kitchen is built around it. Several cooks can then work side by side, sharing the same counters and ingredients, the way many threads run inside one process and share its memory. The process is where the work happens; the thread is the work happening.
For lineage, think of a family tree. If one process opens another, it becomes the parent of that child, and the two stay related only while both are alive; kill the parent and the relationship simply ends. Windows tags every process with a Process Identifier, a PID, the way each person in a building gets a badge number, so you can point to exactly one process when you need to inspect or stop it. There is also a deeper floor to the building you rarely visit directly: kernel mode, where trusted operating-system code talks to the hardware. Almost everything you will analyze lives upstairs in user mode.
Common misunderstandings
- Confusing a process with a program. A program is a file of instructions sitting on disk; a process is what exists in memory once that program is running. The same program can be running as several separate processes at the same time, each with its own PID and its own context.
- Thinking a process and a thread are the same thing. A process is the container; a thread is the activity inside it. One process can hold many threads. This distinction matters later because techniques like process injection target a process's memory but run inside a thread.
- Assuming the parent-child relationship is permanent. Parent and child are related only while both are alive. Some legitimate processes deliberately exit right after launching a child, which leaves that child with no living parent, a normal pattern, not evidence of tampering.
- Treating every unusual process tree as malicious. Parent-child lineage is a starting point for investigation, not a verdict. The skill is knowing which pairings are expected on a healthy system, so the genuinely odd ones stand out.
Real-world context
On a live Windows machine, hundreds of processes run at once, and most of them are ordinary system housekeeping. Defenders learn the normal shape of the process tree so anomalies jump out: a known system process running from the wrong folder, an office application spawning a scripting engine, or a child process whose parent makes no sense. The everyday tools for this are simple, tasklist lists running processes with their PIDs, and taskkill ends one by PID or by name, and the same information appears in Task Manager and Sysinternals' Process Explorer.
C:\>tasklist
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
System 4 Services 0 136 K
smss.exe 428 Services 0 1,200 K
csrss.exe 628 Services 0 5,576 K
winlogon.exe 888 Console 1 12,120 K
lsass.exe 968 Services 0 22,064 KWhen you explain a finding to a client, this vocabulary is what makes the story land. Saying "the malware ran" is vague; saying "a malicious document spawned a child PowerShell process, which then launched a network connection" gives a stakeholder a concrete, defensible picture. The clarity of your explanation depends on the clarity of your process model.
Communication
Interview answer
On Windows, a process is what a program turns into once it's loaded into memory and given resources to run (it owns the memory and the security context), and a thread is a single line of execution working inside that process. One process can run many threads at once, and they all share the process's resources. Each process gets a numeric Process Identifier, or PID, so the system can reference and manage it.
The part that matters most for security work is lineage. When one process starts another, the first is the parent and the second is the child. That relationship lets you read a machine as a process tree instead of a flat list, which is how defenders spot anomalies, like an office document spawning a command shell. Almost everything I'd later analyze, from process injection to suspicious child processes, builds directly on this model.
Follow-up questions
- What is the difference between a process and a thread, and why does that distinction matter for security analysis?
- How does the parent-child relationship between processes help a defender investigate an incident?
- Why does a PID matter, and what does it let you do that an image name alone does not?
- What is the difference between user mode and kernel mode, and why do most analyses stay in user mode?
- Why might a legitimate process have no living parent, and why is that not automatically suspicious?
