Wazuh Insider Threat and UEBA Detection

Why Insider Threats Defeat Traditional Detection

Most security tooling is built to detect outsiders: malware, exploits, intrusion. Insider threats are different because the actor already has legitimate access. There are three flavours. The malicious insider deliberately steals data, sabotages systems or abuses privilege, often before resigning or after a grievance. The negligent insider causes harm through carelessness: mishandling data, falling for phishing, misconfiguring a system. The compromised account is an outsider operating through stolen credentials, which behaves like an insider from the system's perspective.

All three share a defining property: they generate events that are individually legitimate. A finance user accessing finance records, an admin running admin commands, a developer pulling from a repository, none of these are anomalies in isolation. The signal is in the pattern: the same actions at the wrong time, in the wrong volume, from the wrong place, or in an unusual sequence. This is exactly what User and Entity Behaviour Analytics (UEBA) is designed to surface.

Wazuh does not ship a turnkey UEBA product, but it provides the telemetry, correlation rules, stateful counting and dashboards to build effective behaviour analytics. The work is in defining what normal looks like for your users and writing detection that fires on meaningful deviation rather than on every variation.

Telemetry That Powers Insider Detection

UEBA is only as good as its input data. The core sources Wazuh collects for insider detection start with authentication and access events: Windows security log logons (event IDs 4624, 4625, 4672 and related), Linux PAM and SSH logins, VPN and SSO sign-ins, and cloud identity logs from Entra ID or AWS IAM. These establish who accessed what, when and from where.

Next is activity telemetry: Sysmon and auditd process execution showing what users actually ran, file integrity monitoring and file access auditing showing what data was touched, and database audit logs showing queries against sensitive tables. For data-centric insider threats, the combination of file access volume and database query patterns is decisive.

Finally, privilege and configuration telemetry: group membership changes, sudo and runas usage, new account creation, permission grants and changes to security settings. An insider escalating privilege or a compromised account provisioning persistence shows up here. Wazuh normalises all of this through decoders so a single rule set can reason across the whole picture.

Baselining Normal User Behaviour

UEBA detection compares current behaviour against a baseline, so the first step is establishing what normal is. In Wazuh this is partly automatic and partly engineered. Over an observation period you characterise, per user or per role, the typical working hours, the systems and applications normally accessed, the usual source locations and devices, and the normal volume of data access. This baseline is often expressed as role-based expectations rather than per-individual statistics, which is more robust and easier to maintain.

Wazuh supports this through stateful rules that count events over time windows (the frequency and timeframe attributes), allowing detection such as more than N file accesses in M minutes, or first-time access to a sensitive system by a given user. Combined with lists (CDB lists) of expected behaviours such as approved admin accounts, sensitive servers and normal working-hours windows, you turn a static baseline into active detection.

The discipline that makes this work is scoping. Trying to baseline every micro-behaviour of every user produces noise. Effective UEBA focuses on a defined set of high-value behaviours around sensitive data and privileged access, where a deviation genuinely matters, and accepts that low-risk variation does not need an alert.

Privileged Account Monitoring

Privileged accounts (domain admins, root, database administrators, service accounts and cloud admin roles) deserve dedicated, tighter monitoring because their misuse causes the most damage and because their normal behaviour is more predictable, making deviation easier to spot. Every privileged action should be attributable to a named human through a check-out or just-in-time access process, and Wazuh should alert when a privileged account is used outside that process.

Specific privileged-account detections that pay off: use of a service account interactively (service accounts should never log in at a keyboard), admin login from a non-administrative workstation, privileged account active outside change windows, creation of new privileged accounts, and group membership additions to high-privilege groups. Each of these is a strong signal because privileged accounts have so little legitimate variability.

Service accounts deserve special attention because they are a favourite attacker target: they often have broad permissions, weak password rotation and no MFA. Wazuh baselines each service account's normal source hosts and behaviours, then alerts on any interactive login, source-host change or new behaviour, which frequently catches both credential theft and lateral movement.

Practical Insider Detection Patterns

These are the behavioural patterns that consistently surface real insider and account-compromise activity. They are deliberately concrete so they can be implemented as Wazuh rules.

• After-hours access: sensitive system or data access well outside the user's normal hours, especially right before or after resignation.
• Abnormal data volume: a user accessing or downloading far more records, files or query results than their role baseline.
• Dormant account reactivation: an account inactive for weeks suddenly authenticating, a classic compromised-credential signal.
• Privilege escalation: a standard user gaining admin rights, being added to privileged groups, or running sudo for the first time.
• Impossible travel: sign-ins from geographically distant locations within an impossible timeframe, indicating credential sharing or theft.
• Mass file access or deletion: large-scale file reads, copies or deletions detected through file integrity monitoring, a hallmark of exfiltration and sabotage.
• Access outside role scope: a user touching systems or data unrelated to their job function for the first time.

Running an Insider Threat Programme on Wazuh

Insider detection is as much process as technology. The technical detections above need to plug into a response process that respects the sensitivity of accusing an employee. False positives in this domain carry HR and legal consequences, so Codesecure designs insider workflows that route alerts to a small, trusted group, require corroboration before any action, and document the evidence chain. The goal is a defensible investigation, not an automated accusation.

Tuning is critical because behavioural detection is inherently noisier than signature detection. The first weeks involve heavy baseline refinement: identifying the legitimate after-hours workers, the batch jobs that look like mass file access, and the admins whose role genuinely spans many systems. Investing in this tuning is what makes the surviving alerts trustworthy.

Operationally, insider detection benefits enormously from integration. In the Codesecure stack a behavioural alert opens a TheHive case, Cortex enriches the user and host context, and an analyst reviews against HR and access-management context before deciding. This keeps a human in the loop for every sensitive judgement while still giving the speed and coverage that manual review could never achieve. We deliver this as a managed service or as a detection engineering engagement with handover.