Scripting Incident-Response Tasks: Triage Automation

Why Scripted Triage Matters

When a security analyst responds to a suspected compromise, the clock is running against them. Volatile data — information that exists only while the system is powered on — disappears the moment a machine reboots or an attacker clears their tracks. A triage script gives you a fast, repeatable, documented snapshot of a live system before that data is gone. This is a core skill tested in the CompTIA CySA+ incident-response domain and directly supports the ISC2 CC concepts of evidence preservation.

What Volatile Data Is and Why Collection Order Matters

Volatile data is any system state stored in memory or active kernel tables rather than on disk. Examples include:

• Running processes — what is executing right now
• Active network connections and listening ports — what is talking to what
• Logged-in users — who has a session open
• Recent authentication events — successful and failed logins from the last minutes or hours

Because some of this data changes faster than others, analysts follow an order-of-volatility principle. Collect the most transient data first: RAM contents (out of scope for this script but addressed in Course 7), then the process list, then network state, then on-disk log excerpts. If you collect in the wrong order you may miss a process that exited or a connection that dropped.

The Python Script Structure

You will build a single Python 3 script using three standard-library modules:

• `os` — retrieve the hostname and environment information
• `subprocess` — run shell commands and capture their output
• `datetime` — generate UTC timestamps for every section

Capturing Commands Safely

Use `subprocess.run()` with `capture_output=True` and `text=True`. Always pass commands as a list of strings rather than a single shell string — this avoids shell-injection risks, which is an important security practice even in internal tooling.

```python

result = subprocess.run(["ps", "aux"], capture_output=True, text=True)

```

Check `result.returncode` before writing output. If the command fails, write the error (`result.stderr`) to your report so you know something went wrong rather than silently missing data.

The Four Commands

| Command | What it collects |

|---|---|

| `ps aux` | All running processes with PID, user, CPU, and command line |

| `ss -tulnp` | Listening TCP/UDP sockets with process names and PIDs |

| `who` | Currently logged-in users and their login times |

| `tail -n 50 /var/log/auth.log` | Last 50 lines of authentication log |

`ss` replaces the older `netstat` on most modern Linux distributions and is the tool referenced in current CySA+ objectives.

Naming the Report File

Name the output file using the hostname and a UTC timestamp so reports from different machines or different collection runs never overwrite each other:

```

triage_webserver01_20250601T143022Z.txt

```

Generate this with `datetime.datetime.utcnow().strftime("%Y%m%dT%H%M%SZ")`.

Report Structure

Each section of the plain-text report should follow this pattern:

```

========================================

SECTION: Running Processes

Collected: 2025-06-01T14:30:22Z

========================================

<output here>

```

This structure makes the report readable by a human analyst and parseable by a SIEM or other tool later.

Safety and Ethical Boundaries

These tools are only to be run against systems you are authorized to examine. Running triage scripts against systems without written authorization may violate the Computer Fraud and Abuse Act (CFAA) and equivalent state laws. In this course you run your script only against the assigned lab VM. Never run it against shared infrastructure, cloud instances outside your lab account, or any system belonging to another person without documented approval.

From a system-safety standpoint, `subprocess` commands that write to disk should target a designated evidence directory, not system directories. Writing large files to `/` or `/var` on a compromised host could trigger disk-full conditions that interfere with other evidence or with the running system.

The Red-Team/Blue-Team Exercise

Your instructor will plant a netcat listener on the lab VM before the exercise. Netcat (`nc`) can open a listening port that an attacker uses as a backdoor or command-and-control channel. Your `ss -tulnp` output in the report will show every listening port and the process behind it. An unexpected port — especially one bound to `0.0.0.0` on a non-standard port number and owned by a process named `nc` or similar — is your indicator of compromise. Document it in your findings as you would in a real incident.

Connecting to Incident-Response Procedures

The workflow you practice here maps directly to the detection and analysis and containment phases of the NIST SP 800-61 incident-response lifecycle. CySA+ candidates are expected to understand how scripted data collection supports timely analysis, reduces analyst error, and produces defensible documentation. The report file you generate is the beginning of an incident case file.