Implementing Post-Compromise Detection using User and Entity Behavior Analytics

The traditional security paradigm-centered on hardening the perimeter and perfecting signature-based detection-is increasingly obsolete. In an era of sophisticated credential harvesting, "living-off-the-land" (LotL) attacks, and zero-day exploits, the perimeter is effectively non-existent. Modern adversaries do not "break in"; they "log in." Once an attacker secures valid credentials, they operate within the context of legitimate processes, rendering traditional EDR (Endpoint Detection and $Response$) and AV (Antivirus) signatures largely ineffective.

To counter this, security engineering must shift from detecting malware to detecting anomalous behavior. This is where User and Entity Behavior Analytics (UEBA) becomes critical. Post-compromise detection via UEBA relies on the principle that while an attacker can mimic a user's identity, they struggle to mimic the user's precise behavioral fingerprint.

The Mechanics of UEBA: Beyond Static Thresholds

At its core, UEBA is a mathematical approach to identifying deviations from a baseline. Unlike traditional SIEM (Security Information and Event Management) rules-which rely on deterministic logic like `IF login_attempts > 5 THEN alert`-UEBA utilizes probabilistic modeling to assign risk scores to entities (users, hosts, service accounts, and IP addresses).

The implementation of a functional UEBA engine follows a rigorous pipeline:

1. Data Ingestion and Normalization

UEBA is only as potent as the telemetry it consumes. Effective post-compromise detection requires high-fidelity logs from disparate sources:

• Authentication Logs: Kerberos (TGS/AS requests), NTLM, OAuth, and VPN logs.
• Endpoint Telemetry: Process creation (Sysmon Event ID 1), command-line arguments, and file integrity monitoring.
• Network Telemetry: Flow data (NetFlow/IPFIX), DNS queries, and proxy/TLS inspection logs.
• Cloud/SaaS Logs: CloudTrail, Azure AD (Entra ID) sign-in logs, and API activity.

Normalization is the process of mapping these heterogeneous logs into a unified schema (e.g., ECS or OSSEM), ensuring that a "user" in a VPN log is the same "user" in a database access log.

2. Feature Engineering: The Core of Detection

Feature engineering is the most critical and technically demanding phase. A "feature" is a measurable property of the data used as input for the model. To detect post-compromise activity, we must transform raw logs into behavioral vectors.

Examples of high-value features include:

• Temporal Features: Time-of-day distributions, frequency of authentication, and session duration.
• Relational Features: The cardinality of destination IPs accessed by a host, or the number of unique service accounts used by a specific workstation.
• Content-based Features: Entropy of process command lines (to detect obfuscated PowerShell), or the ratio of outbound to inbound data volume.

3. Profiling and Baselines

Once features are extracted, the system must build a "normal" profile for every entity. This involves calculating a baseline over a sliding window (e.g., 30 days). For a user, this might be a multi-dimensional distribution of their typical working hours, common source IPs, and frequently accessed file shares.

Practical Detection Scenarios

To understand how UEBA operationalizes post-scale detection, consider these two high-fidelity scenarios.

Scenario A: Lateral Movement via Credential Abuse

An attacker has compromised a low-privilege user's credentials. They begin performing internal reconnaissance using `net user` and `bloodhound`.

• Traditional Detection: Likely fails, as these are legitimate administrative commands.
• UEBA Detection: The engine observes a sudden spike in the cardinality of targeted hostnames for this specific user. While the user has historically interacted with 3 servers, they are suddenly querying 50. The system calculates a high Z-score (standard deviations from the mean) for "unique host connections" and triggers a high-risk alert.

Scenario B: Data Exfiltration via Cloud Storage

An attacker uses an established session to move sensitive data to a personal Dropbox account.

• Traditional Detection: Fails if the traffic is encrypted (HTTPS) and the destination is a "reputable" domain.
• UEBA Detection: The engine monitors the byte-count feature for outbound web traffic. It detects a deviation where the outbound payload volume for the "Marketing-User" entity is $5\sigma$ (five standard deviations) above their historical daily average. The anomaly is correlated with an unusual User-Agent string observed in the proxy logs, pushing the risk score above the threshold.

Implementation and Operational Considerations

Deploying UEBA is not a "set and forget" endeavor; it is a continuous engineering lifecycle.

The "Cold Start" Problem

When a new entity enters the environment (e.g., a new employee or a newly provisioned microservice), there is no historical baseline. During this "learning phase," the system is prone to high false-positive rates. Engineers must implement a "warm-up" period where alerts are suppressed or weighted lower until the baseline stabilizes.

Concept Drift

User behavior is not static. A developer moving from a backend project to a DevOps role will naturally change their behavior (new tools, new servers, new hours). This is known as concept drift. An effective UEBA implementation must use sliding window averages to allow the baseline to evolve, preventing the system from alerting on legitimate organizational changes.

###

Conclusion

As shown across "The Mechanics of UEBA: Beyond Static Thresholds", "Practical Detection Scenarios", "Implementation and Operational Considerations", a secure implementation for implementing post-compromise detection using user and entity behavior analytics depends on execution discipline as much as design.

The practical hardening path is to enforce strict token/claim validation and replay resistance, deterministic identity policy evaluation with deny-by-default semantics, and certificate lifecycle governance with strict chain/revocation checks. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track false-allow rate and time-to-revoke privileged access and mean time to detect and remediate configuration drift, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.