Loading...

VONDS ©

Lab 29: Monitor User Activity

Back to Lab Index

Investigate a suspicious after-hours login using core user activity tools and simple log filtering. Identify who is on the system, review historical sessions, validate privilege scope, confirm failed login patterns, then mitigate by locking the account.

security core users

Scenario

An overnight access review flagged an unapproved login. A user account that should have been inactive was observed logging in after hours from an unfamiliar IP. Your task is to determine who accessed the system, assess privilege risk, confirm the activity pattern, then decide whether the account should be disabled immediately.

Operator context

This is the kind of triage you do before escalating to SOC, collecting forensics, or changing network controls.

Objective

  • Identify who is currently logged in.
  • Inspect current activity and session context.
  • Review login history for after-hours sessions.
  • Validate group membership and sudo authorization.
  • Confirm suspicious activity and failed login attempts.
  • Mitigate by locking the user account.

Concepts

  • Current sessions come from terminal records, not guesswork. Start with who, then use w for context.
  • Historical sessions come from wtmp. last gives the fastest timeline of logins and sources.
  • Privilege risk is not just root logins. You check group membership, sudo authorization patterns, and any admin groups.
  • Failed login patterns around a successful session can indicate credential guessing or compromise, even if the account is not in sudo.
  • Locking an account preserves evidence while preventing continued access. It is a safe first mitigation while you escalate.

Walkthrough

Step 1 : Display current users logged in.
Command 
who

who gives a clean list of active logins and the remote source addresses, which is often the first signal during triage. 

devstudent  pts/0        2025-07-18 08:13 (192.168.1.25)
sysmon      pts/1        2025-07-18 08:15 (192.168.1.23)
analyst     pts/2        2025-07-18 08:21 (192.168.1.12)
Step 2 : View what those users are doing right now.
Command 
w

w is useful when you need session context fast: how long they have been logged in, idle time, and what is running. 

08:30:01 up 2 days,  4:56,  3 users,  load average: 0.45, 0.42, 0.36
USER       TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
devstudent pts/0    192.168.1.25      08:13    3.00s  0.10s  0.00s bash
sysmon     pts/1    192.168.1.23      08:15    7.00s  0.20s  0.01s top
analyst    pts/2    192.168.1.12      08:21    1:15   0.30s  0.03s vim
Step 3 : Review login history for late-night activity.
Command 
last

last reads login history and is your quickest way to confirm whether an account was active after hours, and from where. 

analyst    pts/2        192.168.1.12    Fri Jul 19 08:21   still logged in
sysmon     pts/1        192.168.1.23    Fri Jul 19 08:15   still logged in
devstudent pts/0        192.168.1.25    Fri Jul 19 08:13   still logged in
intern     pts/3        192.168.1.30    Thu Jul 18 23:59 - 00:15  (00:16)
tester     pts/4        192.168.1.55    Thu Jul 18 23:00 - 23:55  (00:55)
backup     pts/6        127.0.0.1       Thu Jul 18 02:00 - 02:30  (00:30)
root       pts/7        192.168.1.10    Thu Jul 18 01:00 - 01:45  (00:45)
Triage note

The account tester logged in from 192.168.1.55 at 23:00, which is outside normal work hours in this scenario.

Step 4 : Check whether tester has elevated roles.
Command 
id tester

id shows UID/GID and group memberships. This tells you whether the account has obvious privilege paths through admin groups. 

uid=1012(tester) gid=1012(tester) groups=1012(tester)
Step 5 : Confirm who is authorized for sudo.
Command 
getent group sudo

This checks membership in the sudo group. On some hosts, the admin group is wheel, or authorization is controlled through sudoers includes, but group membership is still a fast first pass. 

sudo:x:27:admin,analyst
Step 6 : Filter historical activity for the suspicious account.
Command 
last | grep tester

This isolates the activity to one account so you can confirm time window, duration, and source address. 

tester    pts/4        192.168.1.55    Thu Jul 18 23:00 - 23:55  (00:55)
Step 7 : Check for failed logins around the same time.
Command 
grep 'Failed password' /var/log/auth.log

Failed authentication attempts can confirm probing before a successful session. On many RHEL-based systems, this is commonly logged in /var/log/secure. 

Jul 18 23:02:11 server01 sshd[19112]: Failed password for tester from 192.168.1.55 port 44662
Jul 18 23:02:15 server01 sshd[19113]: Failed password for tester from 192.168.1.55 port 44663
Signal

Multiple failed attempts followed by a successful session is a strong indicator of compromise or credential abuse.

Step 8 : Lock the account to prevent future login.
Command 
passwd -l tester

Account locking is fast mitigation while you investigate further. It preserves the account and artifacts while preventing authentication. 

passwd: password expiry information changed.

Breakpoints

No entries from last

If last returns nothing, the wtmp file may be missing or rotated. Verify the host logs login sessions and that wtmp exists.

Auth log path differs

On some systems the SSH auth log is not in auth.log. If you do not see failed password entries, check the platform’s auth log location.

Group check is not definitive

Sudo access can be controlled in sudoers includes even if the user is not in a sudo group. Group membership is a fast first pass, not a final authorization report.

Cleanup checklist

  • Confirm the account is locked.
  • Capture the relevant session lines for escalation if needed.
Commands 
passwd -S tester
last | grep tester

Reference

  • who: List users currently logged in.
  • w: Show logged-in users and what they are doing.
  • last: Show login history.
  • id: Show UID, GID, and group memberships.
  • getent: Query system databases.
  • getent group sudo: Show members of the sudo group.
  • grep: Search text using patterns.
  • passwd -l: Lock a user account.
  • passwd -S: Show account status and password state.
  • /var/log/auth.log: Authentication log location on many Debian-family systems.