Step 13. Inside Processes and Services — Trace the Lineage of Execution

Level 0 — Understanding Computer Operation and Structure | Difficulty ★★★☆☆ | Estimated time 2–3 hours

Prerequisite: Step 12 complete. We will work in Windows PowerShell. No administrator privileges are needed, and an internet connection is required only for the search step in the mission.

• What you need: a Windows PC, PowerShell.
• Caution: every exercise today is querying and brief execution. A command that terminates a program (Stop-Process) appears once — it closes only the experiment program we just opened ourselves. Carelessly terminating other programs can destroy documents you’re working on, so don’t use it on anything beyond the targets this chapter directs you to.

Suppose you open Task Manager and find an unfamiliar program running. A security analyst’s first question is fixed: "Who launched this?" Even a harmless-looking program is suspicious if the entity that launched it is suspicious. The world of processes has family relationships — every process has a parent that launched it, and that parent has a parent of its own. Learning to trace this lineage by number is today’s topic.

1. Learning Objectives

By the end of this chapter, you will be able to:

• Explain what a PID is and why processes are identified by number rather than name
• Query parent PIDs with Get-CimInstance Win32_Process and trace a lineage to its end
• Confirm by direct experiment the rule that "the parent of a program I run is me"
• Distinguish service start types (Automatic/Manual/Disabled) and understand their security meaning
• Interpret a "broken link" (a terminated parent) encountered during tracing as a normal situation, not an error

2. Background Knowledge — Today’s Tools and Concepts

Today’s Tools at a Glance

2-1. PID — A Process’s ID Number

A computer can run many programs with the same name. Open Chrome and dozens of chrome.exe processes appear. How do we tell them apart? Each process is assigned a unique number every time it runs. This is the PID (Process ID).

Names can collide, but PIDs never do. That’s why every tool that works with the system identifies processes precisely by PID, not by name — and analysis reports record "PID 34732" style numbers. And the number attaches not to the program but to the execution instance — the same Notepad gets a new number each time you close and reopen it.

2-2. The Process Tree — Everyone Has a Parent

A process does not spring from nothing. It is always launched by another process:

System (시조)
 └─ explorer.exe (바탕 화면 관리자)
     └─ powershell.exe (내가 연 파워쉘)
         └─ mspaint.exe (파워쉘에서 연 그림판)

This tree structure is called the process tree. When you double-click an icon to open a program, explorer.exe (the process managing the desktop) is actually the one that launches it. So the parent of most normal programs is explorer.exe.

Why this matters: know the normal lineage, and the abnormal stands out. "PowerShell appeared as a child of Word (winword.exe)" — it means that opening a document made the document secretly run commands, the classic shape of a real malicious-document attack. The tracing you learn today is the technique that discovers it.

2-3. Who Is the Ancestor?

Climb the family tree to the very top, and who’s there? In Windows, System (PID 4) and its surrounding system processes play the role of primogenitor. Born first at boot, they launch the other processes in succession. In the exercises you’ll see very low numbers like PID 0 and 4 — reading a low number as "an early-born backbone of the system" is generally right.

2-4. Services Review + Start Types

In Step 5 you learned that a service is "a staff member who resides where users don’t look." Today we add when they come to work — the start type:

The security connection: if malware registers itself as an "Automatic" service, it revives itself automatically even after reboots. So alongside Step 11’s Run key, the "list of auto-start services" is one of the twin pillars of persistence investigation.

3. Follow Along

3-1. Checking PIDs

Get-Process | Select-Object Name, Id -First 12

Name                     Id
----                     --
acad                  37372
AdskAccessCore         3076
AdskAccessServiceHost  5764
AdskAccessUIHost      13772
AdskAccessUIHost      21672
AdskAccessUIHost      21708
AdskAccessUIHost      21832
AdskIdentityManager   21440
AdskLicensingAgent     1724
...

(Verified on 2026-09-09. The list and numbers on your computer will differ.)

How to read the output: the left is the process name; the right (Id) is the PID. Even in this real capture, AdskAccessUIHost appears four times under the same name — the number on the right is what tells them apart. And that number changes with every run.

3-2. Seeing the Parent PID Too — Today’s New Command

Get-Process doesn’t show parent information. So we use a deeper counter:

Get-CimInstance Win32_Process | Select-Object Name, ProcessId, ParentProcessId -First 12

Name                ProcessId ParentProcessId
----                --------- ---------------
System Idle Process         0               0
System                      4               0
Secure System             236               4
Registry                  276               4
smss.exe                  936               4
csrss.exe                1324            1116
wininit.exe             1448            1116
csrss.exe                1456            1440
winlogon.exe            1544            1440
services.exe            1564            1448
lsass.exe               1620            1448
...

(Verified on 2026-09-09.)

How to read the output:

• ProcessId — this process’s PID
• ParentProcessId — the PID of the process that launched me

Let’s read the lineage from this real table. System Idle Process (0) and System (4) are the topmost ancestors. The parent of services.exe (1564) is 1448 — the wininit.exe right above it. "The service manager was launched by wininit," proven in numbers.

A real ‘broken link’ found in the verification: the parent of csrss.exe (1324) is 1116 — but there is no 1116 in the list. Same for winlogon.exe‘s parent, 1440. The parent launched its child and then exited first — not an error, but a normal situation that happens at every Windows boot. That’s because there are "grandparent" processes that appear briefly right after boot and then vanish.

3-3. Tracing Practice — My PowerShell’s Family Tree

Let’s trace it ourselves. The PID of this very PowerShell window comes out in a single word:

$PID

30916

(The number differs with every run.)

Now view that number’s information and parent:

Get-CimInstance Win32_Process -Filter "ProcessId = $PID" | Select-Object Name, ProcessId, ParentProcessId

Name           ProcessId ParentProcessId
----           --------- ---------------
powershell.exe     30916             7600

(Verified on 2026-09-09.)

Repeat the same question with the ParentProcessId you get — the parent’s parent, the parent above that… climb a few levels and you’ll pass explorer.exe and reach the system line from Section 3-2. "Who launched whom" is traced not by guesswork but by number — that feeling is today’s core harvest.

3-4. Experiment — Becoming a Parent Myself

This time, let’s become a parent ourselves. From this PowerShell window, launch Paint:

Start-Process mspaint

Paint opens (Start-Process runs it and returns to the prompt immediately). Now verify:

Get-CimInstance Win32_Process -Filter "Name = 'mspaint.exe'" | Select-Object Name, ProcessId, ParentProcessId

Name        ProcessId ParentProcessId
----        --------- ---------------
mspaint.exe     21052           26644

(Verified on 2026-09-09. In this run, PowerShell’s PID was 26644.)

ParentProcessId 26644 = this PowerShell’s PID. The rule "the launcher becomes the parent" is confirmed in numbers.

⚠️ Windows 11 caution — Notepad and Calculator are exceptions: if you run Start-Process notepad the same way and check the parent, it will not be your PowerShell’s number (verified on 2026-09-09: Notepad.exe’s parent was a separate process, 37968, and Calculator (CalculatorApp.exe) behaved the same). That’s because Notepad and Calculator in recent Windows are Store-style apps — Windows’ app execution manager launches them on your behalf. Do the experiment with Paint (mspaint) — a classic program where the rule shows cleanly. "The parent isn’t me = something’s wrong" is not the right reading; it’s an explainable face of modern Windows — a good example of Step 11’s "unfamiliar = needs verification."

Once confirmed, close Paint. You can close it from its window, or from PowerShell:

Stop-Process -Name mspaint

3-5. Viewing the Start-Type Distribution of Services

Get-Service | Group-Object StartType | Select-Object Name, Count

Name      Count
----      -----
Manual      195
Automatic   105
Disabled     10

(Verified on 2026-09-09. Numbers differ from computer to computer.)

New command — Group-Object: "bundle the same values together." We grouped by start type and counted.

How to read it: Automatic is 105 — meaning 105 services come to work automatically at every boot. For malware to hide as a service, it must blend into this list. Knowing even roughly "what this number usually is" is baseline awareness.

Today’s wrap-up — why is this security-relevant?: malware analysis reports have a stock sentence: "The process’s parent was X, and it was registered to auto-start via the Y service." Today you personally performed both ingredients of that sentence — parent tracing and auto-start verification.

4. Missions & Exercises

Mission — Building a Lineage Trace Card

1. Launch Paint from PowerShell: Start-Process mspaint
2. Check the Paint process’s PID and parent PID
3. Follow the parents all the way up (to the system line) and draw the lineage on paper. Example: mspaint ← powershell ← explorer ← ...
4. From Get-Service, pick 3 Automatic services whose names you don’t know and investigate each one’s identity (search the name and the identity comes up — this is the real investigation method)
5. When finished, close Paint

Exercises

Question 1. When several processes share the same name, what distinguishes them — and does that number attach to the program or to the execution instance?

Question 2. You queried a process’s ParentProcessId, but no process with that number exists in the list. What situation is this, and how should you record it in a report?

Question 3. On Windows 11, the parent of Notepad launched with Start-Process notepad was not my PowerShell. Is it "contaminated by something"? Why does this happen?

Question 4. Why does malware imitate legitimate process names (like svchost.exe)? State the weakness of name-dependent investigation, and two verification items that compensate for it.

Start-Process mspaint
$PID   # 이 창의 번호를 메모
Get-CimInstance Win32_Process -Filter "Name = 'mspaint.exe'" |
  Select-Object Name, ProcessId, ParentProcessId

mspaint.exe (21052) ← powershell.exe (26644) ← explorer.exe (6700) ← (parent 5848 has exited)

6. Common Pitfalls & Fixes

Wall 1. Get-CimInstance is too slow

Symptom: the command takes several seconds or more.
Cause: Win32_Process is a heavy query that scrapes detailed information on every process. This is normal.
Fix: trim with something like -First 15, or narrow the target with -Filter as in Section 3-3, and it speeds up. The iron rule of investigation: decide "what am I looking for" before scraping everything.

Wall 2. Syntax errors in Filter

Symptom: a red error of the "query is invalid" kind.
Cause: mostly the quote combination in -Filter "Name = 'mspaint.exe'" is wrong. The rule: double quotes outside, single quotes around the inner value.
Fix: copy the form exactly and change only the name. If it still fails, pulling everything without Filter and narrowing with Where-Object also works.

Wall 3. I can’t find the owner of a ParentProcessId

Symptom: querying by the parent PID returns no such process.
Cause: the parent already exited — in the Section 3-2 verification, too, csrss.exe’s parent (1116) was absent from the list.
Fix: it’s not an error. End the trace there — record "parent exited (PID N)" in the report. An extremely common situation in real work as well.

Wall 4. "Cannot find a process" error from Stop-Process

Symptom: a red error appears (verified on 2026-09-09):

Get-Process : 이름이 "notepad"인 프로세스를 찾을 수 없습니다. 프로세스 이름을 검증하고 다시 cmdlet을 호출하십시오.

Cause: no process with that name is running — you already closed it, or you mistyped the name. Note that the name you give Stop-Process is the name without the extension (.exe) (mspaint, not mspaint.exe).
Fix: find the real name by searching a partial string, like Get-Process | Where-Object Name -match 'paint'.

Wall 5. Group-Object results aren’t what I expected

Symptom: it groups by some odd criterion instead of StartType.
Cause: a typo in the property name after Group-Object. Case doesn’t matter, but spelling must be exact.
Fix: check the property names first with Get-Service | Select-Object -First 1. The habit of "ask, and the property names reveal themselves" saves time in every PowerShell task.

7. Summary

Today’s Concepts

Today’s Commands

A Sense That Matters More Than Commands

"Who launched this?" — the first question of malware analysis, and the thing you learned to trace by number today. Know the normal lineage (explorer → legitimate program), and an abnormal lineage — a document secretly running commands — catches your eye. And a name can be faked, but lineage and path are hard to fake — that is the perspective that catches name-mimicking malware.

Remember two more things. First, you’ll have noticed that svchost.exe appears very many times in the process list — 102 were running on the verification computer. It’s a "host" process that runs Windows services on their behalf, which is why there are so many — and that very number is why malware mimics the name. Second, Microsoft’s free tool Process Explorer displays the tree you traced by numbers today as an actual tree diagram. Right now you’re learning the principles through commands; tools show their true worth once you know the principles.

From today, every time you open Task Manager, ask once: "Who launched this one?" A suspicious eye isn’t born overnight — only someone who keeps looking at the ordinary ever sees the extraordinary.

Once every box is checked, Step 13 is complete.