Log Dejargonizer

sudo · Event COMMAND

sudo: a command was run as another user

Someone used sudo to run a command as root or another account, and the log recorded exactly which command. It is the clearest record of privileged activity on a Linux system — and one that is trivially bypassed once a user has a root shell.

Also written as sudo COMMANDsudo log entryTTY= PWD= USER=root COMMAND=sudo command log linux

What it means for you

On a personal computer

You, or a program, ran something with administrator rights. Normal when installing software or changing settings.

For an analyst

The critical limitation: once someone obtains an interactive root shell — `sudo su -` or `sudo -i` — subsequent commands are not logged by sudo at all. Alert on the commands that grant that shell as much as on individual dangerous commands, otherwise your audit trail ends exactly where it starts mattering.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Aug 28 09:44:02 web-01 sudo:  jbrooks : TTY=pts/1 ; PWD=/home/jbrooks ; USER=root ; COMMAND=/usr/bin/apt-get install nginx
Aug 28 09:45:11 web-01 sudo:  jbrooks : TTY=pts/1 ; PWD=/home/jbrooks ; USER=root ; COMMAND=/bin/su -
Aug 28 09:45:11 web-01 su: pam_unix(su-l:session): session opened for user root(uid=0) by jbrooks(uid=1000)

The fields that decide it

Everything else in the log line is context.

The invoking user
The account that ran sudo, written at the start of the line.
TTY
The terminal the command was run from.
  • pts/NA remote or terminal-emulator session.
  • unknownNo terminal — a script or automation rather than a person typing.
PWD
The working directory at the time. A command run from a temporary or user directory deserves more attention.
USER
The account the command was run as. root is the usual value.
COMMAND
The command that was run. This is the field that matters.
  • /bin/su or /bin/bash or -iObtains an interactive root shell. Everything after this is invisible to sudo logging.
  • A command editing /etc/sudoersChanging who can escalate. Rarely routine.
  • A command touching /etc/passwd or /etc/shadowAccount manipulation.
  • A package manager commandOrdinary system administration.
  • A command writing to an authorized_keys fileAdding an SSH key, a common persistence route.

Ordinary reasons this happens

Most of the time it is one of these.

  • Ordinary system administration — installing packages, editing configuration, restarting services.
  • Configuration management tooling running commands with sudo.
  • Deployment scripts performing privileged steps.
  • Monitoring agents collecting data that requires elevation.
  • Users running a small set of permitted commands granted specifically to them.

When it is not ordinary

Escalating to a root shell to avoid further logging.

What gives it awaysudo su, sudo -i, or sudo bash. Legitimate administrators do this constantly, which is exactly why it is worth knowing it ends the audit trail.

ATT&CK T1548.003

Modifying sudoers to grant persistent privilege.

What gives it awayAny command that edits /etc/sudoers or drops a file into /etc/sudoers.d.

ATT&CK T1548.003

Adding an SSH key for persistent access.

What gives it awayCommands writing to an authorized_keys file, particularly for another user or for root.

ATT&CK T1098.004

Disabling logging or security tooling.

What gives it awayCommands stopping auditd, rsyslog, or a security agent.

ATT&CK T1562.001

Reading credential material.

What gives it awayCommands reading /etc/shadow, private keys, or application configuration holding secrets.

ATT&CK T1552.001

What to do next

  1. Read the COMMAND field. It is the event.
  2. Check whether the command grants an interactive shell — if so, sudo logging stops there and you need shell history or auditd instead.
  3. Check the invoking user against who should be running that command.
  4. Read PWD. A privileged command run from a temp directory is worth a question.
  5. Check the TTY. 'unknown' means automation rather than a person.
  6. For anything touching sudoers, authorized_keys, or account files, treat it as a change requiring a record.

Queries to run

grep Most-used sudo commands. The rare entries at the tail are usually more interesting than the common ones. 
grep 'sudo:' /var/log/auth.log | grep -oP 'COMMAND=\K.*' | sort | uniq -c | sort -rn | head -30
grep Escalations to an interactive shell — the point where sudo's audit trail ends. 
grep -E 'sudo:.*COMMAND=(/bin/su|/bin/bash|/usr/bin/sudo -i|/bin/sh)' /var/log/auth.log
grep Privileged commands touching the files that control access. 
journalctl _COMM=sudo --since '7 days ago' | grep -E 'sudoers|authorized_keys|/etc/shadow|/etc/passwd'
splunk Rarest command and user combinations first. 
index=linux sourcetype=linux_secure sudo | rex "USER=(?<runas>\S+)\s+COMMAND=(?<cmd>.*)" | stats count by user runas cmd | sort count asc
elastic 
process.name:"sudo" and system.auth.sudo.command:* | stats count by user.name, system.auth.sudo.command

Common questions

Does sudo log every command a user runs as root?

No, and this is the most important thing to know about sudo logging. It logs the command passed to sudo, so `sudo apt-get install nginx` is recorded in full. But `sudo su -` or `sudo -i` gives the user an interactive root shell, and everything typed in that shell is invisible to sudo. For coverage past that point you need auditd or shell session recording.

Where are sudo commands logged on Linux?

In /var/log/auth.log on Debian and Ubuntu, and /var/log/secure on Red Hat, CentOS, and Fedora. On systemd hosts, `journalctl _COMM=sudo` works regardless of which files exist. sudo can also be configured to log to its own file or to send logs to a remote host.

How do I log all commands run by root on Linux?

sudo alone is not enough because of the interactive shell gap. Use auditd with rules on the execve syscall, which records every command execution at the kernel level regardless of how the shell was obtained. Shell history is not a substitute — it is user-writable and trivially cleared.

What does TTY=unknown mean in a sudo log entry?

There was no terminal attached, which means the command came from a script, a cron job, or automation rather than a person typing. It is entirely normal for configuration management tooling, and worth a second look when the command is one a human would usually run interactively.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026