Log Dejargonizer

Linux Audit Framework · Event ADD_USER

auditd ADD_USER: an account was created

A user account was added. Like the other user-management record types, auditd writes it with no rules configured — so on a machine where nobody set up auditing, this is still one of the few high-value events you will find in the log.

Also written as type=ADD_USERauditd ADD_USERop=adding user audituseradd audit record

What it means for you

On a personal computer

A new user account was created on this machine. If you just added one, this is that. If you did not, and this is a machine reachable from the internet, it is worth taking seriously — creating an account is one of the first things an intruder does to make sure they can get back in.

For an analyst

Cheap, high-signal, and almost never watched. Two details make it more useful than it looks: auid survives privilege changes, so it tells you which login session created the account even though the record shows uid=0; and the record type appears without any audit rules, so it is present on hosts where nobody configured auditd at all. Watch for the account name in ADD_USER never appearing again — an account created for persistence is often never used interactively, which makes it invisible to login-based detections.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
type=ADD_USER msg=audit(1757251859.266:6994): pid=17882 uid=0 auid=1000 ses=41 subj=unconfined msg='op=adding user id=1002 exe="/usr/sbin/useradd" hostname=app-01 addr=198.51.100.77 terminal=pts/1 res=success'

The fields that decide it

Everything else in the log line is context.

acct / id
The account name and UID being created. A UID of 0 on a supposedly ordinary account is the single most important thing to check — a second root-equivalent account is not a normal way to configure anything.
auid
The login user ID behind the action, preserved through su and sudo. This is what tells you who did it rather than what it ran as.
  • A real user's UIDTraceable to a person. Check whether that person had a session at that time.
  • 4294967295No login session — the action came from a daemon, a boot-time process, or something that deliberately detached from one. On an interactive-looking account creation this is worth explaining.
exe
Which binary performed it.
  • /usr/sbin/useraddThe ordinary command.
  • /usr/sbin/adduserThe Debian wrapper.
  • /usr/bin/passwd or an editorNot what you would expect here. Accounts created by editing /etc/passwd directly do not produce ADD_USER at all, which is precisely why watching the file itself matters too.
res
Whether the creation succeeded. A run of failures is somebody without the rights they thought they had.
terminal / addr / hostname
Where the action was performed from. An addr from outside your management network on an account-creation record is the finding, not context.

Ordinary reasons this happens

Most of the time it is one of these.

  • Ordinary onboarding, done by an administrator with a change ticket behind it.
  • Package installation. Many packages create a dedicated service account during install, and this is the most common source of the record on a normal server.
  • Configuration management — Ansible, Puppet, Salt — converging user state, usually in a burst across many hosts at the same minute.
  • Container and virtualisation tooling creating subordinate accounts during setup.
  • Provisioning of a new machine from an image or a cloud-init template.

When it is not ordinary

A backdoor account created for persistent access after a compromise.

What gives it awayCreation outside a change window, from an unexpected source address, with the account then added to a privileged group and rarely or never used for an interactive login afterwards.

ATT&CK T1136.001

A second UID 0 account, which is root under a name nobody looks at.

What gives it awayid=0 in the record for an account that is not root. Nothing legitimate needs this — check with `awk -F: '$3==0' /etc/passwd`.

ATT&CK T1136.001

An account named to blend in with service accounts.

What gives it awayNames close to real ones — a trailing digit, a swapped character, a plausible daemon name that no installed package owns. Compare against the package manager's view of which accounts belong to what.

ATT&CK T1036

What to do next

  1. Read the account name and the UID. A UID of 0 makes everything else secondary.
  2. Read auid, not uid. uid will be 0 because the creation ran as root; auid identifies the login session that caused it, and that is who you need to speak to.
  3. Check whether a package installation happened at the same moment: `grep -i install /var/log/dpkg.log` or `dnf history` around that timestamp. Service accounts created by packages are the ordinary case.
  4. Look at what happened immediately afterwards. ADD_USER followed by ADD_GROUP or USER_MGMT adding the account to sudo, wheel, or admin is a different event from ADD_USER alone.
  5. Check the account's shell and home directory: `getent passwd <name>`. A service account with an interactive shell is a contradiction worth resolving.
  6. Verify whether the account has ever logged in — `lastlog -u <name>` — and whether it has an SSH authorized_keys file. An account that never logs in but holds a key is a persistence mechanism, not a user.
  7. Remember that editing /etc/passwd directly bypasses this record entirely. If you rely on ADD_USER, also watch the file with a file rule: `auditctl -w /etc/passwd -p wa -k identity`.

Queries to run

grep All account and group management this month. On most servers this should be a short list you can read in full. 
ausearch -m ADD_USER,ADD_GROUP,USER_MGMT -ts this-month -i
grep auditd's built-in account modification report, which is faster than assembling one yourself. 
aureport -m -i
grep Every UID 0 account on the machine. The answer should be exactly 'root'. 
awk -F: '$3==0 {print $1}' /etc/passwd
grep Adds file watches so that direct edits to the account files are recorded too, since those produce no ADD_USER record at all. 
auditctl -w /etc/passwd -p wa -k identity; auditctl -w /etc/shadow -p wa -k identity

Common questions

Do I need audit rules configured to see ADD_USER records?

No, and that is what makes it valuable. The user-management record types are written by the account tools themselves through the audit system, so they appear even on machines where nobody has written a single audit rule. On a host with no auditing configured, ADD_USER, USER_AUTH and their relatives are often the only meaningful records in the log.

What is the difference between uid and auid in an ADD_USER record?

uid is the account the process was running as at the time, which will be 0 because creating a user requires root. auid is the login user ID — the account that originally logged in — and Linux preserves it through su and sudo. So uid tells you the action ran as root and auid tells you which person's session was behind it. auid is the one to read.

Can someone create an account without generating an ADD_USER record?

Yes. The record is produced by the account management tools, so writing a line into /etc/passwd and /etc/shadow with an editor creates a working account and produces nothing here. That is why file watches matter alongside it: `auditctl -w /etc/passwd -p wa -k identity` records writes to the file regardless of what made them.

What should I check first after an unexpected account creation?

The UID. If it is 0, the new account is root under another name and nothing legitimate does that. After that, read auid to identify the session responsible, check whether the account was added to a privileged group in the following seconds, look at its shell and home directory, and check for an SSH authorized_keys file — an account that never logs in but holds a key exists purely to let someone back in.

Read next

Vendor documentation

Last reviewed 7 September 2026