Known-Good Processes — Baselines for Windows, Linux & macOS

Because malware routinely masquerades as legitimate system processes — naming itself svchost.exe, hiding as a bracketed kernel thread, or impersonating a Spotlight worker — and signature detection misses novel samples. What it can't easily fake is the full context: the right name, in the right path, with the right parent, as the right user, in the right count, behaving correctly. So detection becomes anomaly-against-baseline: a process called svchost.exe running from %TEMP%, lacking the -k flag, or parented by Word instead of services.exe is obviously wrong even if I've never seen that specific malware. You can't spot the impostor without knowing what the real one looks like, which is why "know normal, find evil" is the foundation of triage and hunting.

On a healthy Windows host there is exactly one lsass.exe, it lives in System32, it's parented by wininit.exe, it runs as SYSTEM, and critically it spawns no child processes. lsass holds credential material in memory, so it's a prime target. Multiple lsass processes usually means something is masquerading as it — often a credential dumper or malware using the trusted name. lsass spawning a child like cmd.exe or rundll32 is a strong sign of code execution within or injection into lsass, again typically credential theft. And a near-miss spelling like lsas.exe or lsass1.exe, or an lsass running from a non-System32 path, is the same masquerade. Any of these is high-severity because they cluster around credential access.

Real kernel threads have three signatures: their name appears in square brackets in ps like [kworker/0:1], their parent is kthreadd at PID 2, and they have no on-disk executable and essentially no user memory because they live in kernel space. Malware sometimes names itself like a kernel thread to blend into ps output. I expose it by checking those invariants: is its parent actually PID 2, and does /proc//exe point to a real binary? A bracketed name whose parent isn't kthreadd, or that has a real executable — often in /tmp or marked (deleted) — and nonzero resident memory is malware wearing a costume. So the tell is a kernel-thread name with a userland reality.

I verify the six baseline attributes. The path must be C:\Windows\System32\svchost.exe — not a user-writable folder. Its parent must be services.exe; svchost spawned by Office, a browser, or PowerShell is malware. Its command line should include the -k flag naming a service group — legitimate svchost is always launched with -k, so a bare svchost.exe with no -k is a red flag. It should run as SYSTEM, NETWORK SERVICE, or LOCAL SERVICE, not a regular user. The name spelling must be exact, since scvhost or svhost are typosquats. And I'd check its children and network connections for anything out of character, and verify the Authenticode signature. Process Explorer shows the parent, path, command line, and signature together, which makes this a quick check.

Windows has a rigid boot tree, so a lot of detection is verifying the expected parent-child relationships — lsass under wininit, svchost under services. macOS is much flatter: essentially everything descends from launchd at PID 1, so parent-child lineage tells you less. Instead the tells shift to code signature, path, and the launch configuration. System daemons are code-signed and notarized by Apple and live under /System/Library, so I lean on codesign and spctl to check whether a binary is properly signed or unsigned/ad-hoc, and on whether it's running from a user-writable location like /tmp or /Users/Shared. And because persistence on macOS is via LaunchAgents and LaunchDaemons plists, I inspect those plists and launchctl to see what launched a suspicious process. The common masquerade is naming malware after a Spotlight worker like mdworker but running it unsigned from the wrong path.

Because the masquerade hides in a flat list but is exposed by relationships. A process called lsass.exe or svchost.exe looks perfectly normal in a list of names — the malicious context only appears when you see who its parent is and what children it spawned. lsass.exe is fine until you see it was launched by cmd.exe, or that it launched powershell; svchost is fine until you see its parent is winword.exe. The parent-child edge is the actual evidence, which is exactly why endpoint detection is built on process lineage and why I always pull the tree with ps auxf, pstree, or Process Explorer rather than reading a name list. The relationship turns an innocent-looking name into a smoking gun.