Linux tee Command: The SOC Trick That Saves Evidence Before It's Gone

Linux tee Command for SOC Analysts: Never Lose Command Output Mid-Investigation

Quick Answer: The Linux tee command splits a command's output so it appears on screen and is saved to a file at the same time — critical for preserving command-line evidence during incident response instead of re-running commands and risking data loss.

Last verified: September 24, 2026

An analyst is three hours into triaging a suspected lateral-movement incident. The process list on a compromised jump host shows something odd — a reverse shell disguised as a cron helper — and it's about to scroll off screen. There's no time to second-guess the terminal buffer. If that ps aux output isn't captured right now, in the exact state it's in, it's gone the moment the process dies or the host gets isolated. This is the exact situation tee was built for: see it and save it, in one pass, with zero risk of re-running a command against a system that may have already changed.

tee is one of the oldest utilities in Unix, but it quietly does something SOC analysts, incident responders, and penetration testers rely on constantly: it lets you observe live output in real time while writing an unaltered copy to disk for later review, reporting, or SIEM ingestion — all without breaking the pipeline you're already working in.

Table of Contents

• What tee Actually Does
• Why tee Matters for Incident Response and Log Preservation
• tee Command Reference for SOC Workflows
• Real-World Scenario: Capturing Evidence During Active Triage
• Detection & Prevention Considerations
• Expert Tips
• FAQ
• Conclusion

What tee Actually Does

tee reads from standard input and writes that same stream to standard output and to one or more files simultaneously. The name comes from a plumbing T-fitting — it splits a single stream into two directions without altering it. That's the key property for a security analyst: tee doesn't transform or filter the data, it duplicates it exactly, which matters when the output itself may become part of an incident timeline or a report attached to a ticket.

This is different from simple output redirection with >, which sends output only to a file and hides it from the terminal. In active SOC analyst command line logging work, that's rarely what you want — you need to see results as you triage while still keeping a durable copy.

Why tee Matters for Incident Response and Log Preservation

Security teams that rely on ad hoc terminal work often lose the exact command output that justified a decision — a process was killed, an account was disabled, a host was isolated — but nobody saved the evidence that triggered the action. Formal incident response evidence collection practice treats this as a real gap: preservation discipline is part of the control objective, not an afterthought bolted on after the report is written, and weak evidence handling usually only surfaces once a team has to explain an incident to an assessor or a customer.

tee won't build you a forensic chain of custody on its own — that still needs documented collection steps, timestamps, and ideally hashing of the resulting files — but it removes the single biggest practical failure mode: re-running a command later and assuming the output is the same as what you originally saw. On a live, compromised, or volatile host, it usually isn't.

tee Command Reference for SOC Workflows

Basic capture: screen and file together

command | tee file.txt

Displays output on screen and simultaneously saves it to file.txt, overwriting the file if it already exists. This is the default pattern for capturing evidence on the fly.

Append mode: build a running log

command | tee -a file.txt

Displays output and appends it to file.txt without overwriting existing content. Use this when you're logging multiple commands into the same investigation file over the course of a shift.

Write to multiple files at once

command | tee file1.txt file2.txt

Writes the same output to more than one destination — for example, a local scratch copy and a second copy on a mounted evidence share.

Write to a protected file with sudo

echo "data" | sudo tee /etc/config

Warning: writing to protected system paths can affect service behavior. A common mistake is running sudo command | tee file and expecting the redirect to be privileged — it's actually tee that needs sudo, since it's the process doing the write. Never run this pattern against a live production config without a verified backup and change-control approval.

Save full output while filtering for what matters

ls -l | tee list.txt | grep ".txt"

Saves the complete, unfiltered output to list.txt — your evidence copy — while passing the stream on to grep for immediate triage. This pattern (capture everything, filter only the view) is the core habit worth building for digital forensics log preservation: never let filtering destroy the raw data.

Capture network and host state

ip addr | tee network.txt
uname -a | tee system-info.txt
df -h | tee disk-usage.txt
ps aux | tee processes.txt
ls -la | tee directory-list.txt

Each of these is a quick, standalone triage capture: network interfaces and addressing, kernel and OS version, disk utilization, running processes, and a detailed directory listing. On a host you suspect is compromised, running this small set at the start of triage — before anything is remediated — gives you a snapshot to reference later.

Append to an ongoing log file

echo "New log entry" | tee -a application.log
history | tee -a command-history.txt
date | tee -a log1.txt log2.txt

Useful for building a running investigation log, appending a reviewed command history to your case notes, or timestamping multiple log files at once during a multi-host response.

Chain tee with analysis commands

ps aux | tee processes.txt | grep ssh
cat file.txt | tee copy.txt | wc -l
cat names.txt | tee backup.txt | sort
ls | tee output.txt | wc -l

These patterns save a complete, untouched copy of the data before it's filtered, counted, or sorted — so if your grep pattern was wrong or you need to reprocess the data differently later, the original capture is still sitting on disk.

Capture standard error along with output

command 2>&1 | tee errors.log

Merges stderr into the same stream as stdout before tee sees it, so both normal output and error messages land in errors.log. This matters during script or tool failures, where the error text is often the most diagnostically useful part of the output.

Log a script's output for later review

./script.sh | tee script-output.log

Displays a script's output live while saving a copy — useful when running a custom triage or enumeration script against a host and you want a record independent of your terminal scrollback.

Write multiple lines or overwrite multiple destinations

printf "Line 1\nLine 2\n" | tee file.txt
echo "Hello" | tee file1.txt file2.txt file3.txt

Standard patterns for writing formatted multi-line content, or pushing the same short message to several files at once.

Real-World Scenario: Capturing Evidence During Active Triage

Picture a mid-size SOC investigating unusual outbound connections from a Linux web server flagged by the EDR agent. The analyst SSHes in and needs to move fast, but also needs every command's output preserved for the incident ticket and, potentially, for legal or compliance review later.

Instead of running commands and manually copy-pasting terminal output afterward — which is slow and error-prone — the analyst pipes every triage command through tee -a into a single running case file:

ps aux | tee -a case-4471.log
ip addr | tee -a case-4471.log
ss -tulnp | tee -a case-4471.log | grep ESTAB

Each command's raw output is appended to case-4471.log as it happens, in order, with nothing lost between steps — while the analyst still sees exactly what's on screen to make real-time decisions about containment. By the time the host is isolated, there's already a timestamped, sequential record of what the system looked like before remediation began — the single artifact that later gets attached to the incident report and, if hashed and stored properly, can support a defensible chain of custody.

Detection & Prevention Considerations

tee itself isn't something you "detect" — it's a legitimate coreutils binary present on virtually every Linux system. The security angle cuts both ways:

• Defensive use: Standardize on tee-based logging in incident response runbooks so evidence capture is consistent and repeatable across analysts, rather than depending on individual habits.
• Adversarial use: Attackers can also use tee as part of a pipeline to write output to unexpected locations, including staging data for exfiltration or persisting content to disk under a legitimate-looking filename. SOC teams should treat unusual tee invocations writing to unexpected paths (temp directories, web-accessible folders, or files that resemble legitimate system files) as worth reviewing in EDR command-line telemetry, the same way they'd review any unfamiliar pipeline of built-in tools.
• Integrity: For anything that may become evidence, calculate a hash (for example with sha256sum) of the resulting log file immediately after capture, and store that hash separately from the file itself.

Expert Tips

• Suppress duplicate terminal output when you only need the file written, by redirecting tee's own stdout to /dev/null: command | tee file.log >/dev/null.
• Check which tee implementation you're on before relying on newer flags — GNU coreutils, uutils coreutils, and BusyBox all support slightly different option sets, and minimal or embedded systems may lack flags like -i or --output-error.
• Standardize a naming convention for case log files (host, ticket number, date) so appended tee -a logs from a multi-host incident stay organized and easy to correlate later.
• Remember tee preserves data exactly as received — it does not sanitize, redact, or filter. Review captured files before sharing them outside the response team if they may contain sensitive data.

Related Cybersecurity Topics You Should Explore

• Linux wc Command Tutorial: Count Log Lines Like a SOC Pro
  
• Linux cmp Command Explained: Every Flag SOC Teams Actually Use
  
• Linux diff Command Tutorial: Detect Config Drift Like a SOC Analyst
  
• Linux uniq Command: 6 Log Analysis Tricks SOC Analysts Use
  
• Brevo Hack Exposed 100,000+ Sites to ClickFix: Check Now
  
• Linux sort Command Guide: Rank Attacker IPs in Seconds

FAQ

Does tee overwrite files by default?

Yes. Without the -a flag, tee truncates and overwrites the destination file each time it runs. Use -a to append instead.

Why does sudo need to go before tee, not before the whole pipeline?

Because each command in a pipeline runs as the user that started it, unless that specific command is elevated. echo "data" | sudo tee /etc/config elevates only tee, which is the part actually writing to the protected file — the standard reason sudo command > file often fails against root-owned paths.

Can tee corrupt or alter the data it captures?

tee writes the byte stream it receives without transformation, so it's generally considered a faithful copy for evidentiary purposes — though for anything going into a formal investigation, pair it with a hash check rather than relying on tee alone as proof of integrity.

Is tee available on minimal or containerized Linux images?

Usually, since it's part of GNU coreutils or an equivalent (uutils, BusyBox), but very stripped-down container images sometimes omit it. Check with command -v tee before building it into an automated script.

What's the difference between tee and simple output redirection?

command > file sends output only to the file and shows nothing on screen. tee does both at once, which is why it's preferred whenever an analyst needs to watch output live while still preserving it.

Conclusion

tee is a small, unglamorous command, but it solves a real and recurring problem in security operations: the gap between what an analyst saw on screen and what actually got preserved. Building it into standard incident response habits — capture first, filter second, hash what matters — costs almost nothing and removes one of the most common, avoidable gaps in command-line evidence handling.

Analysis based on SOC monitoring and public threat intelligence review.