Day 19 – Linux Bash Script Execution IR

Objective: Investigate a Linux compromise involving a malicious Bash script. Identify how the script ran and how to detect and remove it. Challenge Description: Suppose the phishing email delivered a malicious Linux shell script (evil.sh) that was executed (perhaps via a user’s action or cron). You have shell access to the affected Linux box. Your goal is to trace the execution of this script using logs and forensic artifacts. Check for persistence (e.g. a cron job) and any data exfiltration it performed. Tools: A Linux environment with access to logs. Use commands like grep, cat, less to inspect logs, and ls, ps or crontab -l to find running services. Examine files like /var/log/syslog, /var/log/auth.log, and user history (~/.bash_history). Steps to Solve: 1. Locate the script: Search the filesystem for evil.sh (e.g. find / -name evil.sh). 2. Check bash history: Look at ~/.bash_history for commands invoking the script (e.g. bash /tmp/evil.sh or sh). The Bash history file is a goldmine of user commands[15]. 3. Inspect syslog: Review /var/log/syslog (or /var/log/messages) for entries around the time the script might have executed. Look for entries about the script name or related commands[16]. 4. Check authentication logs: In /var/log/auth.log, search for any sudo or login attempts by suspicious users[17]. If evil.sh required root, it might be in sudo logs. 5. Find persistence: Determine if a cron job or startup entry was created. Check crontab -l for all users or inspect /etc/cron* and /var/spool/cron/ for new entries. 6. Analyze the script: cat /tmp/evil.sh. Identify its functionality – does it download payloads (wget, curl), install backdoors, or exfiltrate data? Note any domains or IPs contacted.

Simulated Lab: You discover /tmp/evil.sh on the server. Viewing /home/alice/.bash_history reveals the line bash /tmp/evil.sh. From /var/log/syslog you see a timestamped line: cron[1234]: (alice) CMD (bash /tmp/evil.sh). This indicates that the script was run by user alice’s cron job. Checking /var/spool/cron/crontabs/alice, you find an entry * * * * * bash /tmp/evil.sh. This confirms persistence.

Next, you open evil.sh. It contains a Base64-encoded block that, when decoded, executes a reverse shell to 203.0.113.50 (an IOC). You also find it appends output to /tmp/evil.log. You delete the cron entry (crontab -l | grep -v evil.sh | crontab -) and remove the script and log (rm /tmp/evil.sh /tmp/evil.log). Verify no such processes are running (e.g. ps aux | grep evil.sh).

Finally, double-check ~/.bash_history and /var/log/auth.log to ensure no other suspicious commands or sudo attempts were made. Log these findings (script path, cron schedule, contacted IPs) as artifacts.

Key Citations: A user’s ~/.bash_history is a crucial artifact, recording all shell commands they executed[15]. System logs (/var/log/syslog or /var/log/messages) provide timelines of script execution and cron jobs[16]. Authentication logs (e.g. /var/log/auth.log) reveal sudo use and login events[17]. Cron jobs (in /var/spool/cron/) often hold persistent malicious tasks[18].