What is privilege escalation on Linux?

Gaining more rights than you were given: from an unprivileged account to root, or from a temporary foothold to lasting access. On a server it nearly always leaves a mark in a small set of places: accounts, sudo rules, SSH keys, setuid binaries.

Does installing a package trigger false alarms?

Much less than you would expect. An account a package created is attributed to that package when the package manager can verify it, and rated low; a privileged binary replaced by an upgrade is cleared by dpkg -V or rpm -V.

Does SecAI read my password hashes?

No. It reads /etc/shadow only to tell whether an account has an empty password, and sends that yes or no.

Will it lock an account automatically?

Never. Disabling an account can be proposed and always waits for a person, in every mode.

Does it detect kernel exploits?

Not as they run. It detects what they are used for: the new account, the key, the setuid binary, the process in a temp directory, the new outbound connection.

Linux Privilege Escalation Monitoring

Privilege escalation monitoring for Linux servers

A foothold becomes a serious incident when privileges change. An intruder who arrives as the web server's user wants root, and wants to keep it: a sudo rule, a new account with uid 0, a key in root's authorized_keys, a setuid copy of a shell. Every one of those is a change to a small number of files, and every one of those also happens legitimately, every week, on a healthy server.

Where privilege is granted

Accounts: /etc/passwd, /etc/shadow, /etc/group. A new user, a uid 0 that is not root, an account that suddenly has a login shell.
Sudo: /etc/sudoers and its drop-ins. A NOPASSWD rule, a grant for a service account.
SSH keys: authorized_keys files, reported by fingerprint and comment. A new key for root is persistence and privilege in one line.
Setuid, setgid and capability binaries in the system directories. A new one, or a changed one.
Empty passwords, read from /etc/shadow as a yes or no, never as a hash.

The first report is the baseline

At enrolment the agent records what exists: the accounts, the grants, the keys, the privileged binaries. None of that is reported as a change, because on the day you install monitoring everything is new. From then on a difference is a finding. For sudoers and authorized_keys the text before and after the change travels with it, so the alert shows the rule or the key that was added, not only that the file's hash differs.

File integrity monitoring

Who did it: package, person, or nobody

The hard part of privilege monitoring is that the alarming changes and the routine ones look identical. SecAI asks two questions of every one. Did a package do it? An account declared in a sysusers.d file owned by an installed package, whose content still matches the package's own record, was made by that package and is rated low, and rated up again if it has a login shell, a home directory or a key. A privileged binary replaced during an upgrade is cleared when the package manager verifies the new file.

Did an administrator do it? A privilege change that happens inside an interactive SSH session authenticated with a key you have registered as an administrator's is attributed to that session. The anchor is which key logged in, by its fingerprint, and the platform decides, never the agent: an agent on a compromised server must not be able to call itself trusted. The attribution is deliberately narrow. A password login can never qualify, a cron or systemd job never counts as a person, and an open root session is not by itself a reason to trust a change, because an intruder who brute-forced root is by definition acting inside a root session. A change with no package and no registered key behind it is the one SecAI asks you to confirm.

Linux threat detection

What it does about it

A privilege finding is reported with its evidence and rating. Disabling an account can be proposed, and it always waits for a person: account enable and disable are gated in every mode, because locking the wrong account on a production server is its own incident. Nothing about accounts, sudo or keys is ever changed by SecAI on its own.

What waits for approval

Drift is not escalation

Escalation is an event: somebody gained privilege they did not have. Drift is a condition: privileges accumulated over years, the contractor's key, the deploy account with passwordless sudo, the group nobody remembers granting. SecAI reports both, the first as a change and the second in the weekly audit and the posture findings, where passwordless sudo rules and accounts that should not have a shell are listed with the evidence.

How to detect privilege drift

Limits

It watches where privilege is granted, not the exploit that granted it: a kernel privilege-escalation exploit is seen by what it leaves behind, not as it runs.
There is no eBPF or audit-subsystem tracing of individual system calls.
Attribution depends on the administrator keys you register; a change made with an unregistered key, or over a password login, is reported as unattributed, which errs on the noisy side by design.