Forensics · Lesson 10
Processes, Services & Startup Evidence
Learn how running processes, service configuration, startup mechanisms, parent-child relationships, executable paths, user context, and network activity work together to explain what is running and how it started.
Current-state evidence can disappear as soon as you stop a process or service. Preserve the process identity, service configuration, startup source, and related logs before making defensive changes.
Lesson Snapshot
Learning objectives
Connect running state to launch mechanism and evidence
Explain how running processes, services, startup mechanisms, and executable paths support forensic reasoning.
Distinguish process identity from filename, display name, service name, and user account.
Recognize evidence that connects a running process to a service, startup item, scheduled mechanism, or user session.
Use Windows and Linux tools to inspect process ownership, executable paths, parent relationships, service state, and startup configuration.
Preserve relevant process and service evidence before stopping, disabling, or deleting anything.
Correlate process and service evidence with logs, files, accounts, scheduled tasks, and network activity.
Core idea
A running process is only one moment in a larger chain
To explain a process, connect its executable, account, parent, start time, service or startup source, logs, and network activity.
Competition caution
Do not kill the evidence before recording it
Stopping a process or service can erase current state. Record the PID, path, command line, user, parent, service configuration, startup mechanism, and related network evidence first.
Process principles
Use identity and context, not names alone
A name is not an identity
Two different executables can share the same process name, and legitimate software can be copied or renamed. Path, hash, owner, and parent context matter.
Processes are temporary
A running process can disappear quickly. Record PID, path, account, parent, command line, start time, and network state before stopping it.
Services add persistence and privilege context
A service can start automatically, run under a specific account, and launch an executable without an interactive user.
Startup location changes meaning
A program started from Program Files or /usr may be expected, while a similar binary in AppData, Temp, /tmp, or a user autostart folder may require more review.
Parent-child relationships help explain sequence
The parent process can show whether a program was launched by a shell, service manager, scheduled task, browser, script host, or another application.
Preserve before hardening
Stopping a process or disabling a service can erase current-state evidence and create new log entries that complicate the timeline.
Process evidence
Fields worth preserving
Process name
Useful label, but not enough to identify the executable.
PID
Identifies the process instance at that moment.
Executable path
Connects the process to a specific file and location.
Command line
Can reveal arguments, scripts, configuration files, or launched targets.
User / account
Shows which security context the process is running under.
Parent process
Adds launch context and can explain how the process started.
Start time
Places the process in the timeline.
Hash
Provides strong content identity for the executable file.
Network activity
Connects the process to listening ports or remote connections.
Service evidence
Fields worth preserving
Service name
Stable identifier used by the operating system.
Display name
Human-readable label that can differ from the service name.
Executable / unit command
Shows what program or script actually starts.
Startup type
Shows whether the service starts automatically, manually, or is disabled.
Run-as account
Explains privilege and security context.
Current state
Running, stopped, failed, inactive, or another state.
Dependencies
Helps explain why a service starts, stops, or fails.
Related logs
Supports installation, startup, stop, restart, or failure timing.
Windows processes
Inspect running state safely
List processes
Get-Process
Shows running Windows processes and their PIDs.
Process details
Get-Process -Id 1234 | Format-List *
Shows detailed properties for one process instance when permissions allow.
Executable path and command line
Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, ExecutablePath, CommandLine
Provides process identity, parent PID, path, and command line.
Current process owner
Get-CimInstance Win32_Process -Filter "ProcessId=1234" | Invoke-CimMethod -MethodName GetOwner
Returns the user context for a selected process.
Hash the executable
Get-FileHash "C:\ProgramData\Example\helper.exe" -Algorithm SHA256
Adds strong content identity for the executable file.
Windows services
Inspect service configuration
List services
Get-Service
Shows service names, display names, and current state.
Detailed service configuration
Get-CimInstance Win32_Service | Select-Object Name, DisplayName, State, StartMode, StartName, PathName
Shows state, startup mode, account, and executable path.
Inspect one service
Get-CimInstance Win32_Service -Filter "Name='ExampleService'" | Format-List *
Shows detailed configuration for one service.
Classic service configuration
sc.exe qc ExampleService
Displays service type, start mode, account, and binary path.
Classic service status
sc.exe query ExampleService
Shows current service state.
Windows startup
Common automatic-start evidence sources
Startup folders
Per-user and all-users startup shortcuts and files.
Preserve
Target path, arguments, user scope, timestamps, and linked executable.
Run / RunOnce registry locations
Common Windows auto-start configuration points.
Preserve
Value name, command, path, user/system scope, and related file metadata.
Scheduled Tasks
Can trigger at logon, startup, time intervals, or events.
Preserve
Task name, trigger, action, arguments, run-as account, enabled state, and history.
Services
Can launch at boot and run without user interaction.
Preserve
Service name, binary path, account, start mode, state, and installation/start logs.
Shell extensions and application startup
Some applications configure their own login-time or startup behavior.
Preserve
Application configuration, startup path, user profile context, and process evidence.
Linux processes
Inspect process identity and ancestry
Process snapshot
ps aux
Shows users, PIDs, resource use, and command information.
Custom process view
ps -eo pid,ppid,user,lstart,cmd
Shows PID, parent PID, user, start time, and full command.
Process tree
pstree -ap
Displays parent-child process relationships with PIDs and arguments where available.
Executable path
readlink -f /proc/1234/exe
Resolves the executable used by a running process.
Command line
tr ' ' ' ' < /proc/1234/cmdline
Reads the command line for a selected process.
Process owner
ps -o user= -p 1234
Shows the user account associated with one process.
Linux services
Inspect systemd units
Running services
systemctl --type=service --state=running
Lists currently running systemd services.
Service status
systemctl status ssh
Shows current state, recent logs, main PID, and unit information for a service.
Unit definition
systemctl cat ssh
Displays the unit file and drop-in configuration used by systemd.
Enablement state
systemctl is-enabled ssh
Shows whether the service is configured to start automatically.
Service properties
systemctl show ssh -p FragmentPath -p User -p ExecStart -p MainPID -p ActiveState
Shows useful forensic properties in a compact form.
Linux startup
Common automatic and scheduled execution sources
systemd system units
/etc/systemd/system and vendor-managed unit locations.
Preserve
Unit file, ExecStart, User, enablement, timestamps, package source, and journal records.
systemd user units
~/.config/systemd/user
Preserve
Per-user service and timer definitions.
Cron
User crontabs, /etc/crontab, and /etc/cron.* directories.
Preserve
Schedule, command, user, file timestamps, ownership, and execution logs.
Desktop autostart
~/.config/autostart and system-wide autostart locations.
Preserve
Desktop entry, Exec command, user scope, timestamps, and launched process.
Shell startup files
~/.profile, ~/.bashrc, ~/.bash_profile, and related files.
Preserve
Commands that may run during login or shell startup depending on shell behavior.
Process reasoning
Separate observation from conclusion
Process name is chrome.exe
Supported
A process with that name is running.
Not supported
It is definitely the legitimate browser binary.
Executable path is C:\Program Files\Vendor\app.exe
Supported
That process instance points to the executable at that path.
Not supported
The executable is trustworthy solely because it is under Program Files.
Process runs as SYSTEM
Supported
The process has a highly privileged Windows security context.
Not supported
The process is malicious or unauthorized.
Linux process runs as root
Supported
The process has root privileges.
Not supported
The process was started by a human administrator.
Parent process is powershell.exe
Supported
The selected process was launched by a PowerShell process.
Not supported
The launch was malicious.
Process owns a listening port
Supported
That process is bound to the port at the time of observation.
Not supported
The service is unauthorized without scenario and application context.
Service reasoning
Use service configuration to explain persistence and privilege
Automatic service points to C:\Users\student\AppData\Local\helper.exe
The service will attempt to launch a user-profile executable automatically.
Next evidence
Preserve service configuration, file hash, account, install event, process state, and scenario context.
Linux systemd service ExecStart points to /opt/vendor/bin/agent
The service manager launches that executable when the unit starts.
Next evidence
Check package/source context, unit file ownership, enablement, logs, process, and required functionality.
Service is disabled but running
The current process exists even though future automatic startup may be disabled.
Next evidence
Separate current state from startup policy.
Service is enabled but inactive
It is configured for startup conditions but is not currently running.
Next evidence
Check triggers, failure logs, dependencies, and whether it is required.
Service runs under a dedicated low-privilege account
The software uses an isolated service identity.
Next evidence
Do not remove the account before confirming the service requirement.
Service installed minutes after a package install
The package may have created the service.
Next evidence
Correlate package logs, unit/service file creation, and installation source.
Parent-child relationships
Understand launch context
Parent
explorer.exe
Child
document-viewer.exe
Could reflect a user launching an application from the desktop shell.
Parent
taskeng.exe / Task Scheduler
Child
script-host process
Could reflect scheduled execution.
Parent
services.exe
Child
service executable
Consistent with Windows Service Control Manager launching a service process.
Parent
systemd
Child
daemon process
Consistent with systemd starting a service.
Parent
bash
Child
python script
Could reflect an interactive or scripted shell launch.
Parent
browser process
Child
download helper / viewer
Could reflect browser-triggered application activity.
Startup questions
Use the right evidence for the right persistence question
Why does this program run after reboot?
Service start mode, scheduled task trigger, Run key, startup folder, systemd enablement, cron, or autostart configuration.
Which user context launches it?
Service account, task run-as user, process owner, unit User= directive, or user startup location.
What executable actually runs?
Service PathName, task action, ExecStart, startup shortcut target, or registry value.
When was startup configured?
Service/task logs, file timestamps, registry change context, package logs, or unit metadata.
Did it run successfully?
Process state, service state, task history, journal, Event Viewer, exit status, and application logs.
Is it required?
Scenario requirements, application dependencies, business purpose, and service documentation.
Preserve before action
Capture the state that stopping or disabling could erase
Running process
PID, name, executable path, command line, user, parent PID, start time, hash, open files where relevant, and network connections.
Windows service
Service name, display name, state, startup type, run-as account, binary path, dependencies, install/start events, and file hash.
Linux service
Unit name, state, enablement, ExecStart, User, FragmentPath, main PID, journal records, file metadata, and package/source context.
Startup entry
Location, value or shortcut target, arguments, user scope, timestamps, ownership, hash, and linked process evidence.
Scheduled mechanism
Task or cron/timer name, trigger, command, user, enabled state, timestamps, execution logs, and related process.
Windows networking
Map sockets to processes
Connections with PID
Get-NetTCPConnection | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess
Maps TCP connections and listeners to process IDs.
Resolve PID
Get-Process -Id 4312
Maps a selected PID to a process name.
Linux networking
Map sockets to processes
Listeners and processes
sudo ss -lntup
Shows listening TCP/UDP sockets and process information where permissions allow.
Active connections
sudo ss -ntup
Shows current TCP connections and associated processes where available.
Process-network correlation
Build the connection from port to executable to service
PID 4312 owns TCP port 8080
Supported conclusion
Process 4312 is listening on TCP port 8080 at the time of observation.
PID 4312 path is C:\ProgramData\Demo\server.exe
Supported conclusion
The listener maps to that executable path.
Service DemoServer has PathName pointing to the same executable
Supported conclusion
The service and network listener likely belong to the same running component.
System event shows DemoServer started at 10:02
Supported conclusion
The service-start event supports the process timeline.
File hash is recorded before service disablement
Supported conclusion
The executable content can still be identified after the process is stopped.
Log correlation
Connect process state with launch events
7045 service install at 09:10 + 7036 running at 09:11 + process start at 09:11
Supported conclusion
The installed service likely launched the observed process.
systemd unit enabled at 10:00 + journal shows start at 10:01 + daemon PID exists
Supported conclusion
The service was configured for startup and then entered a running state.
Task trigger at 11:30 + PowerShell parent + child executable at 11:30
Supported conclusion
The scheduled task may explain the process launch chain.
Cron record at 12:00 + shell script process + outbound connection at 12:00
Supported conclusion
The scheduled Linux job may explain the process and network activity.
RDP session at 13:05 + explorer parent + user application at 13:07
Supported conclusion
The process started during the remote interactive user session.
Package install at 14:10 + service unit appears + daemon starts at 14:12
Supported conclusion
The package installation likely introduced and started the service.
Common mistakes
Process and service mistakes that destroy useful evidence
Stopping the process first
You can lose PID, command line, parent, network, and current-state evidence.
Trusting process names
Names can be duplicated or misleading. Verify executable path and hash.
Ignoring the run-as account
User, SYSTEM, root, and dedicated service accounts have very different privilege implications.
Ignoring parent process
Parent-child relationships can explain whether a process came from a shell, service, task, browser, or automation mechanism.
Confusing enabled with running
Startup policy and current state are different facts.
Removing a service before checking dependencies
Required applications can break if the service supports an expected function.
Assuming root or SYSTEM means malicious
Many legitimate system services require high privilege.
Ignoring your own defensive changes
Stopping or disabling services creates new logs and state changes that must be documented.
Fictional process & service lab
Reconstruct a service from installation to network activity
Service DemoSync is installed with binary C:\ProgramData\DemoSync\sync.exe.
DemoSync enters the running state under LocalSystem.
sync.exe is running as PID 4312 with parent services.exe.
PID 4312 listens on fictional lab port TCP 8088.
sync.exe SHA-256 and file metadata are recorded before any defensive change.
Team disables and stops DemoSync after confirming it is not required by the fictional scenario.
Task 01
Which evidence most directly identifies the executable path?
The service-install record and service configuration showing C:\ProgramData\DemoSync\sync.exe.
Task 02
What connects the running process to the service?
The matching executable name/path, parent services.exe, service state, and aligned start time.
Task 03
What does the network evidence establish?
PID 4312 was listening on TCP port 8088 at the time of observation.
Task 04
Why record the hash before stopping the service?
The hash preserves exact executable-content identity after the process is no longer running.
Task 05
Does LocalSystem execution prove the service is malicious?
No. It establishes a highly privileged service context, but legitimacy depends on scenario, source, software purpose, and corroborating evidence.
Task 06
Why keep the change-log entry at 10:08?
It separates the team's defensive action from the original system state and prevents later timeline confusion.
Lesson checklist
Before moving on
I record process name, PID, path, user, parent, command line, and start time.
I use hashes when executable identity matters.
I record service name, start mode, account, path, state, and related logs.
I distinguish startup configuration from current running state.
I check parent-child relationships before concluding how a process started.
I correlate processes with network connections when relevant.
I inspect scheduled tasks, cron, systemd timers, startup folders, and autostart only when the question points there.
I preserve evidence before stopping or disabling anything.
I confirm required functionality before removing services or startup items.
I keep a change log for my own defensive actions.
I do not treat SYSTEM or root context as proof of maliciousness.
I correlate process and service evidence with files, logs, accounts, and scenario requirements.
Reflection
Check your process and service reasoning
Question 1
Why is executable path stronger evidence than process name alone?
Question 2
What can a parent process tell you about how a program started?
Question 3
Why does a running service differ from an enabled service?
Question 4
What evidence should you preserve before stopping a suspicious process?
Question 5
Why can a process running as SYSTEM or root still be legitimate?
Question 6
How would you connect a listening network port to a specific service?
Carry this forward
Record the process before it disappears, identify the actual executable and account, connect it to its launch mechanism, correlate with logs and network state, and only then make defensive changes.