CLI Investigation: Build a Reproducible Evidence Trail

A terminal session becomes valuable when another person can understand what you did.

If your notes say only:

I checked the logs and found something weird.

then the investigation cannot be reviewed.

A stronger record shows:

• where you started
• which commands you used
• what output mattered
• what you concluded
• what remained uncertain

That is the goal of this lab.

Scenario

A teacher provides a fictional Linux lab environment for a robotics club workstation.

The team reports three symptoms:

1. several failed login events appeared overnight
2. a new file appeared in a shared project directory
3. one background process is unfamiliar to the team

You are authorized to inspect only the supplied classroom VM or embedded terminal and the files provided with the exercise.

You are not authorized to scan external systems, test credentials, or interact with real accounts.

Warm-up: practice the command model here

Before working in a teacher-provided VM, use the bounded terminal below to practice location, listing, navigation, reading a supplied file, and creating a harmless notes file.

Garden State Cyber Linux simulation
Ghostty renders the terminal. No host filesystem, school device, or unrestricted shell is connected.
Type 'help' for the supported command set.

$ pwd
/home/student

$ ls
README.txt  evidence/

$ cd evidence

$ pwd
/home/student/evidence

$ ls -la
-rw-r--r-- 1 student student 184 login-summary.txt

$ cat login-summary.txt
09:01 SUCCESS user=alex
09:02 FAILED user=guest
09:04 FAILED user=guest
09:06 SUCCESS user=maria

$ touch notes.txt

The terminal is a simulation. Its purpose is to let you practice the command/evidence relationship without relying on a local Linux installation or touching a school system.

Phase 1: establish your location

Record the prompt and run:

pwd

Then list the top-level lab files:

ls -l

Before opening anything, write a two-sentence description of the environment.

Example:

The shell is operating as the student user in /home/student/lab. The directory contains an evidence folder, a projects folder, and a teacher-provided process snapshot.

This establishes context.

Phase 2: inspect the login evidence

Navigate to the supplied evidence directory.

Use read-only commands such as:

head login-events.txt
tail login-events.txt
grep "FAILED" login-events.txt

Record:

• total pattern matches provided by the lab workflow
• usernames shown in failed events
• timestamps
• whether successful logins also appear

Then answer:

Does the presence of failed logins prove an attack?

No.

Failed logins can come from forgotten passwords, old saved credentials, mistyped usernames, automated processes, or malicious guessing.

The log is evidence of failed authentication attempts. The cause still needs context.

Phase 3: inspect the unfamiliar file

List the shared project directory:

ls -l projects

The fictional output shows:

-rw-r--r-- 1 student team  218 Sep 10 08:41 robot-status.txt
-rw-r--r-- 1 guest   team  104 Sep 11 01:18 update-note.txt

Do not edit or delete either file.

Ask:

• Which metadata is unusual?
• Is the timestamp relevant?
• Does ownership prove who created the file?
• What would you need to know before calling it malicious?

Then read only the teacher-approved sample file.

Your goal is to distinguish unusual from malicious.

Phase 4: inspect the process evidence

Use the teacher-provided process snapshot or approved process-inspection command.

A sample might include:

student  1204 bash
student  1277 python3 status_monitor.py
root      611 sshd
guest    1442 sync-helper

Create a table:

Do not terminate anything.

A process name alone is not sufficient evidence of malware.

Phase 5: correlate instead of guessing

Now compare the three evidence sources.

Look for relationships:

• Does the guest username appear in failed-login events?
• Does the file timestamp line up with any supplied login event?
• Does the process snapshot include the same account shown as the file owner?

Correlation can strengthen a hypothesis, but it still does not prove causation.

For example:

The guest account appears in failed-login events and owns the new file.

That is stronger than either observation alone.

But it still does not prove that the failed login attempts created the file.

Build a command transcript

Your transcript should look like a reproducible investigation, not a command dump.

Use this structure:

Goal: establish location
Command: pwd
Result: /home/student/lab
Interpretation: confirms the authorized lab path

Goal: identify failed authentication events
Command: grep "FAILED" evidence/login-events.txt
Result: [summarize supplied output]
Interpretation: failed attempts exist; cause not yet established

Include at least eight commands or evidence actions.

Write a defensible conclusion

Use this structure:

Claim

State the strongest conclusion supported by the supplied evidence.

Evidence

Cite at least three observations.

Alternative explanation

Name one plausible non-malicious explanation that has not been ruled out.

Limitation

State what the current evidence cannot prove.

Next authorized step

Request one additional piece of evidence.

Possible examples:

• fuller authentication log
• file version history
• known account list
• approved process details

Do not request "scan everything."

Explain every command

Choose three commands from your transcript and explain:

• what the command does
• why it was appropriate for the investigation
• what state it changed, if any
• what mistake a beginner could make with it

This is how you turn memorized commands into operational understanding.

Evidence for Lesson 3

Submit:

• command transcript
• process table
• evidence-correlation notes
• final defensible conclusion
• three command explanations

Finish with:

The strongest clue in the lab was ________, but it still did not prove ________.

A terminal can give you a lot of information quickly. Your job is to keep the speed of the tool from outrunning the quality of your reasoning.