Quick, practical steps to extract, parse and investigate sudo events from syslog and the systemd journal. 16.11.2025 | reading time: 3 min Who ran what as root and when: that is the central question; answering it often starts in the sudo log. Read this short guide to learn concrete commands and parsing pipelines that extract user, TTY, PWD, target user and the exact COMMAND from syslog or the journal so he can triage privilege misuse quickly. Quick live example Grab the last sudo entries from a Debian-style system and from systemd in one line each and inspect them directly: `grep 'sudo:' /var/log/auth.log | tail -n 5` and `journalctl _COMM=sudo -o short-iso | tail -n 5`; example output block: ```Nov 16 12:34:56 host sudo: bob : TTY=pts/2 ; PWD=/home/bob ; USER=root ; COMMAND=/usr/bin/apt update Nov 16 12:35:01 host sudo: bob : TTY=pts/2 ; PWD=/home/bob ; USER=root ; COMMAND=/bin/journalctl -u ssh```; then parse fields into a compact table with a pipeline such as `grep 'sudo:' /var/log/auth.log | sed -E 's/.*sudo: //' | awk -F'; ' '{print $1 " | " $2 " | " $3}'` and you will see "bob : TTY=... | PWD=... | USER=..." which speeds up spotting odd targets or unexpected commands. Patterns worth hunting Look for repeated NOPASSWD runs, unusual target users, commands that spawn shells, or invocations from odd TTYs and times; check for "COMMAND=/bin/su" or editors launching shell escapes and correlate with failed auth entries. Also watch for sudoers edits and for many short-lived commands in a tight window: these are classic signs of script-driven abuse; when he spots a suspect line, collect surrounding timestamps and the invoking process via the journal or audit to build a timeline. When syslog is not enough If fields in syslog are sparse or if full session capture is required, enable sudo I/O logging in the sudoers file with `Defaults log_input,log_output` and set `iolog_dir`; then use `sudoreplay` to replay captured sessions. For low-level execution auditing enable auditd and search exec events with `ausearch` to correlate a sudo entry with the underlying `execve` calls. Other tools to tie things together Combine simple text tools and system facilities: `grep`, `awk` and `sed` are your fast filters; `journalctl` and `ausearch` provide authoritative time-ordered sources; `sudoreplay` and the sudo I/O plugin let him recover interactive evidence; finally export suspicious entries into CSV or JSON for incident reporting or further SIEM ingestion. Closing step Start with logs, then widen the net: correlate sudo entries with authentication failures, process trees and audit trails to build a confident narrative of what happened; sharpen that skill and consider formalizing knowledge with a certification such as CompTIA Linux+ or LPIC-1, and use bitsandbytes.academy for intensive exam preparation. Join Bits & Bytes Academy First class LINUX exam preparation. security utilities troubleshooting scripting
