User behavior analytics tools have become standard in enterprise security stacks. They analyze login patterns, application usage, and access requests to build behavioral baselines. When someone in finance suddenly accesses HR systems at 3am, UEBA flags it.
But UEBA operates at the wrong layer to catch a significant class of threats. It sees what users do in applications. It doesn't see what's happening on the machines those users control.
The Application Log Ceiling
UEBA systems ingest data from SaaS applications, identity providers, VPNs, and cloud APIs. Okta tells you when someone logged in. Salesforce tells you which records they viewed. AWS CloudTrail shows which S3 buckets they accessed.
This works well for detecting account compromise that manifests in application behavior. Someone in sales suddenly downloading the entire customer database. An employee accessing sensitive documents outside business hours. A contractor trying to escalate privileges in your cloud console.
But attackers who've compromised an endpoint don't need to generate suspicious application logs. They can run reconnaissance tools, exfiltrate files through raw network sockets, establish persistence mechanisms, or move laterally using SSH keys, all without touching your SaaS stack.
Your UEBA baseline knows that Alice usually logs into GitHub between 9am and 6pm EST. It doesn't know that at 2:47am, something executed curl | bash under her user context and installed a backdoor that phones home every six hours.
Process Execution Lives Below the Waterline
When an attacker drops a binary on a compromised system and executes it, that process runs with the privileges of whichever user account they've compromised. The binary might be a memory scraper, a network scanner, a credential dumper, or a privilege escalation exploit.
None of this generates application logs. The user's Okta session looks normal. Their Slack activity looks normal. Their email patterns look normal. UEBA systems that rely on application-layer data sources have no mechanism to detect process anomalies.
Even EDR tools that do monitor process execution typically operate in user space. They see process creation events through Windows APIs or by parsing /proc on Linux. This works until an attacker uses techniques that bypass user-space monitoring: direct syscalls, kernel exploits, or process injection that manipulates memory without spawning new processes.
The Network Visibility Gap
UEBA tools often incorporate network behavior analytics. They track which internal systems a user typically accesses, what protocols they use, and how much data they transfer. Deviations trigger alerts.
But this network visibility operates at the connection level, not the syscall level. Your UEBA system might notice that a database administrator's laptop is suddenly transferring 40GB to an external IP. It doesn't see the specific syscall sequence that initiated that transfer, what process made it, or what file descriptor was involved.
Modern data exfiltration doesn't always look like bulk transfers. Attackers use slow drip techniques, chunking data across many small connections over extended periods. They use protocols that look legitimate at the network layer. They leverage existing application tunnels.
At the syscall boundary, these patterns become visible. A process that's never touched the network suddenly opening sockets. Read operations on sensitive files immediately followed by network write operations. DNS queries generated by processes that have no business doing DNS lookups.
UEBA systems working from NetFlow or firewall logs can't correlate file access with network activity at this granularity. The gap between "user Alice downloaded a file" and "process X read file Y then wrote to socket Z" is where user behavior analytics limitations become operational risks.
File Operations and Data Access Patterns
Application logs tell you which documents a user opened in SharePoint or Google Drive. They don't tell you that a process running under that user's context just read 47 configuration files in /etc/, copied the entire contents of ~/.ssh/, or accessed the local password manager database.
File system operations happen continuously on every system. Most are benign. A text editor creating swap files. A browser writing cache. Background services reading config files. But buried in this noise are patterns that indicate compromise: systematic enumeration of directory structures, mass file access outside normal working hours, reads of credential stores by unexpected processes.
UEBA tools don't have visibility into these local file operations. They operate too high in the stack. By the time file access generates an application log (if it generates one at all), the context is gone. You know someone accessed a file. You don't know what else they accessed immediately before and after. You don't know which process performed the access.
Behavioral Baselines Need Three Dimensions
Effective behavioral analytics requires baselines across multiple axes: users, roles, and infrastructure. UEBA typically handles the first two. It knows what Alice does and what people in Alice's role typically do.
It doesn't handle the third. Infrastructure baselines answer questions like: what does normal look like on production database servers versus developer workstations? Which processes typically run on Kubernetes pods handling payment processing versus those serving static content?
An attacker who compromises Alice's account and starts running crypto miners on her laptop creates a user-level anomaly that might get flagged. But if they compromise a service account and run the same miner on 30 application servers, that's an infrastructure-level anomaly that won't show up in user behavior analytics.
Kernel-level visibility allows correlation across all three axes simultaneously. The system sees that user Alice (dimension one), who has a developer role (dimension two), just executed a process on a production database server (dimension three) that no developer has ever run on that infrastructure type. All three dimensions deviate from baseline. The detection confidence goes up accordingly.
Without kernel visibility, you're limited to two-dimensional baselines at best. You catch the obvious cases. You miss the sophisticated ones.
Where Kernel Telemetry Fills the Gap
Process execution, file operations, and network activity at the syscall boundary provide context that application logs can't. This isn't a replacement for UEBA. It's the complement.
eBPF-based monitoring sits at the kernel layer before any user-space manipulation. It captures syscall-level events with minimal overhead (typically 0.1% CPU impact at high throughput). It sees every process execution, every file open, every socket operation, regardless of whether those events generate application logs.
The detection latency matters. Catching a process anomaly 98 milliseconds after execution means you can terminate it before it establishes persistence or exfiltrates data. Waiting until suspicious activity shows up in application logs hours or days later means you're analyzing an incident, not preventing one.
False positive rates drop as baselines mature. At seven days of baseline data, anomaly detection sits around 0.69% false positive rate. At 180 days, it's 0.18%. This isn't noisy. It's precise enough for automated response.
The integration point is straightforward: kernel telemetry feeds the same SIEM or security data lake that consumes application logs. Analysts see both layers. When UEBA flags suspicious SharePoint access, kernel data shows whether that user also executed unusual processes or accessed unexpected files. The correlation closes the visibility gap.
Your UEBA investment isn't wasted. It's just incomplete. User behavior analytics limitations aren't a product failure. They're an architectural constraint. Application logs show what they show. Everything below that layer requires different instrumentation.