Context and objective
This course exercise, presented with Richard Allado, used a fictional company with a single Linux server in an isolated test environment. The scenario began with unusual SSH activity, an unexplained user account, and suspicious outbound traffic. The goal was to practice both sides of an incident: identifying weaknesses through a controlled attack and reconstructing what happened from system evidence.
Lab setup and threat model
The server exposed SSH and held sensitive account, privilege, and log files. The scenario included a weak user password, an unused but enabled account, and an overly broad sudo permission for a package-management command. Those conditions created paths from remote login to persistence and administrator access.
The defensive setup restricted SSH root login and login attempts, used UFW to limit inbound access, and configured Auditd to watch account and privilege files and executed commands. System and authentication logs supplied the other investigation records. The presentation also considered Fail2Ban as a defensive tool; the simulated SSH service lacked its brute-force protection.
Controlled attack and investigation
The lab sequence moved from network reconnaissance to repeated SSH login attempts, a successful login, creation of an unauthorized account, privilege escalation through the permissive sudo rule, and an outbound reverse shell. These steps were performed only against the lab server.
The investigation correlated authentication logs with Auditd records. The presentation records 437 failed SSH logins before the successful connection. Account-creation and command-execution events then helped reconstruct persistence and privilege escalation; outbound connection evidence completed the timeline. This cross-check made the sequence more reliable than treating any single log line as the full story.
Response and lessons
The documented immediate response blocked the attack source, removed the unauthorized account, reset the compromised credential, and revoked the unsafe sudo permission. Follow-up recommendations included SSH key authentication, outbound traffic filtering, fuller sudo auditing, and a host intrusion detection system.
The exercise showed how a weak password and excessive privileges can defeat partial hardening, while authentication and audit logs make the compromise traceable. The findings do not describe a production incident.