312-50 Question 154
Single answer▪ Clearing LogsDuring an authorized internal penetration test, you gain administrative access to a Linux web server hosting a customer portal. The engagement scope allows you to demonstrate anti-forensic techniques, but the client wants evidence that you understand the operational impact of each action. You need to show how an attacker could clear evidence of their activity while minimizing obvious signs of tampering and without disrupting the system more than necessary. Which action is the MOST appropriate to demonstrate in this scenario?
- A
Use shell history suppression for the current session and selectively remove or edit only the relevant entries from shell history and application-specific logs instead of deleting all log files
- B
Delete the entire /var/log directory and reboot the server so that fresh logs are created automatically
- C
Run chmod 000 on all log files so defenders cannot read them and assume the logs were cleared
- D
Stop the rsyslog service permanently and uninstall the logging package to prevent any future evidence from being recorded
Show answer and explanation
Correct answer: A
Explanation
The best answer is Option 1 because it demonstrates an anti-forensic technique with the least operational disruption and the lowest likelihood of immediate detection compared with blunt-force actions. In Linux environments, attackers may attempt to avoid writing shell history by manipulating environment variables such as HISTFILE, using non-interactive shells, or removing only specific commands from shell history. They may also target particular application or service logs instead of deleting all system logs. From a defender's perspective, broad deletion of log files creates an obvious forensic artifact: a gap in records. By contrast, selective tampering is harder to spot, which is why it is the more realistic technique to demonstrate in a CEH-style scenario.
Candidates should also understand that local log clearing is not the same as erasing all evidence. Modern environments commonly use centralized logging via syslog, SIEM platforms, EDR telemetry, audit frameworks such as Linux auditd, and cloud-based monitoring. Even if local files are edited or removed, forwarded copies may still exist. This reflects standard security best practices in incident detection and response: maintain remote, append-protected, or centralized logs so that local anti-forensic actions do not fully eliminate evidence. Relevant references include Linux syslog/rsyslog documentation, bash manual behavior for history handling, and common enterprise logging guidance such as centralized log retention recommendations from NIST incident response and logging best practices.
- A. Correct.
Correct. In a realistic anti-forensics demonstration, selectively suppressing shell history for the current session and targeting only relevant records is less disruptive and less obvious than mass deletion. Deleting or truncating entire logs often creates a clear gap that defenders notice immediately. A controlled demonstration that explains shell history behavior (for example, bash history only being written at session end unless explicitly flushed) and the difference between shell history and centralized/system logs better reflects how clearing logs is approached in practice. This also aligns with the client's request to minimize operational impact while demonstrating attacker tradecraft.
- B. Incorrect.
Incorrect. Deleting /var/log is highly disruptive, easy to detect, and operationally risky. Many Linux services rely on log directories and expected file paths. Rebooting may recreate some files, but the sudden absence of historical logs is itself strong evidence of tampering. This option reflects a common misconception that 'clearing logs' means deleting everything, when in practice that is noisy and often breaks forensic timelines in an obvious way.
- C. Incorrect.
Incorrect. Changing permissions does not clear logs. The log contents remain intact, and defenders with root or offline access can still recover and inspect them. It may also trigger alerts or operational issues when logging services can no longer write to files. This option confuses access restriction with anti-forensic log removal.
- D. Incorrect.
Incorrect. Permanently stopping rsyslog and uninstalling the package is both disruptive and conspicuous. It prevents future local logging but does not remove existing evidence, and it may generate service-monitoring alerts. In enterprise environments, logs may also be forwarded to centralized SIEM or syslog collectors, so disabling the local daemon does not guarantee elimination of evidence. This is not the most appropriate low-impact demonstration.