Loading...

VONDS ©

Lab 29: Monitor User Activity

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.

What You’ll Practice

  • Current session visibility with who and w.
  • Historical login review with last.
  • Identity and group verification with id.
  • Validating sudo-eligible users with getent group sudo.
  • Quick log filtering using grep.
  • Mitigation by locking an account using passwd -l.

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 “who is on the box” 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 in the foreground. 

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

“tester” logged in from 192.168.1.55 at 11 PM, 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 (common on Debian/Ubuntu). In a real environment, the admin group might be wheel or controlled in /etc/sudoers, but group checks are 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 quickly 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 brute-force probing or password guessing before a successful session. In RHEL-based systems, this would often be /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.

Reference

  • who : Lists users currently logged in (TTY, time, source).
  • w : Shows logged-in users and what they are doing.
  • last : Displays login history from wtmp.
  • id <user> : Displays UID/GID and group membership.
  • getent group sudo : Lists members of the sudo group (Debian/Ubuntu pattern).
  • grep 'Failed password' /var/log/auth.log : Filters auth logs for failed SSH password attempts (Debian/Ubuntu path).
  • passwd -l <user> : Locks a user account to prevent login.