At 14:32:18Z on 2026-10-12, the Ubuntu server ir-lab-ubuntu24 accepted an unexpected login for the account ops. The attacker did not need to alter a program or break encryption if ops already had access to files that should have belonged only to socalyst or root. Our defender question is concrete: which filesystem paths let an account read, change, or enter something it should not?
Every later observation uses the same case facts. The analyst account is socalyst, the suspicious account is ops, and the incident window runs from 2026-10-12 14:10:00Z through 15:10:00Z. Linux stores the server name in /etc/hostname, local account records in /etc/passwd, protected password hashes in /etc/shadow, and each account’s files under paths such as /home/socalyst and /home/ops. A path is not merely a location. Its ownership and permissions decide who may use the object at that location. The case host and its evidence paths establish the boundaries we will inspect:
This diagram shows that identity records, host configuration, home directories, and authentication evidence live in separate paths. A finding about /home/ops does not automatically prove that /etc/shadow changed, so we keep each claim tied to the artifact that supports it.
The unexpected ops login makes permissions the next boundary to check, because Linux evaluates access before a process can read a file, alter a file, or enter a directory. A user is an account such as socalyst or ops. A group is a named collection of accounts that can share access, such as the shadow group used to limit access to password-hash records.
Each filesystem object has an owner, a group, and three permission sets. The owner permissions apply to the owning account, group permissions apply to members of the assigned group, and other permissions apply to everyone else. The bits are r for reading content, w for changing content, and x for executing a program or entering a directory. For /home/ops, the directory permission x controls whether another account can traverse the path into that directory.
The contrast between /etc/hostname and /etc/shadow makes the security decision visible. Processes need to read the hostname so /etc/hostname is normally readable by all accounts, while only privileged system components should read the password hashes in /etc/shadow. World-writable access, meaning the other set includes w, would let any local account change a protected object. A world-readable /etc/shadow would expose password hashes for offline guessing. The expected shapes for the case paths make suspicious deviations easier to recognize:
This table shows that permission settings depend on the path’s purpose. Publicly readable identity and hostname information can support normal system operation, but writable access remains restricted because changed identity records or host settings can mislead later investigation.
Permission rule Treat a permission mode as evidence of allowed access, not evidence that access occurred. Logs and timestamps are needed to support a claim about an action.
Because permissions describe current access rather than intent, we first preserve observable facts about ir-lab-ubuntu24. The commands hostnamectl, id, ls -l, stat, and readlink -f answer different questions without modifying the examined files. hostnamectl reports the configured host identity. id ops and id socalyst resolve each account’s numeric identity and group membership. Those numeric identities matter because Linux stores ownership as user and group IDs even when command output renders familiar names.
For the paths /etc/hostname, /etc/passwd, and /etc/shadow, ls -l gives a compact view of permission bits, owner, group, size, and a displayed timestamp. stat reports more exact metadata, including the numeric mode and modification time. readlink -f resolves a path to its final target, which prevents a symbolic link, a filesystem object that points elsewhere, from disguising the location we actually inspected. The following session records the case facts without asserting why any timestamp or permission exists: