- Nationwide Digital Forensic & Cyber Investigation Services
Business breaches involving a web server, application host, or Linux based infrastructure leave a distinctive artifact trail that differs sharply from a Windows workstation investigation. This page covers the authentication logs, persistence mechanisms, and web application artifacts examiners rely on to reconstruct a Linux server intrusion.
| Question | One line answer |
|---|---|
| Where are Linux login attempts recorded? | /var/log/auth.log on Debian based systems, /var/log/secure on Red Hat based systems. |
| How do examiners see past logins? | The wtmp, btmp, and lastlog binary files, read with utilities such as last, lastb, and lastlog. |
| Where do attackers hide persistence? | Cron jobs, systemd timers and services, shell profile files, and SSH authorized_keys. |
| What is a web shell? | A malicious script placed in a web server directory that gives an attacker remote command execution through HTTP requests. |
| Do containers complicate the investigation? | Yes. Ephemeral containers can vanish on restart, so image, orchestration, and host level audit logs become essential. |
| Are Linux file timestamps as precise as Windows? | No. Common filesystems such as ext4 have more limited timestamp semantics than NTFS, which affects timeline precision. |
| Term | What it means |
|---|---|
| auth.log / secure | The primary authentication log files on Debian based and Red Hat based Linux distributions respectively, recording login attempts and privilege escalation. |
| wtmp / btmp / lastlog | Binary log files recording successful logins, failed login attempts, and the most recent login per user, readable with standard utilities. |
| Cron | The traditional Linux job scheduler, commonly abused by attackers to establish scheduled persistence. |
| systemd timer | A modern scheduling mechanism, functionally similar to cron, increasingly used for persistence on systemd based distributions. |
| Web shell | A script uploaded to a web server webroot that provides an attacker with remote command execution through ordinary web requests. |
| authorized_keys | The SSH file listing public keys permitted to authenticate as a user without a password, a common target for attacker persistence. |
The authentication log is usually the first artifact examined on a suspected Linux compromise, since it records both successful and failed login attempts along with sudo and privilege escalation activity.
Shell history is one of the most useful and most easily destroyed artifacts on a Linux host. Sophisticated attackers routinely unset the HISTFILE variable, symlink history files to /dev/null, or clear history on logout, so its absence is itself a notable finding rather than a dead end.
Once initial access is established, an attacker on a Linux server typically pursues one or more of a small set of well known persistence techniques, and web application compromises frequently involve a planted web shell for ongoing access.
| Persistence mechanism | What examiners check |
|---|---|
| Cron jobs | System crontab, per user crontabs, and /etc/cron.d entries for unfamiliar scheduled commands. |
| systemd services and timers | Unit files in /etc/systemd/system and /lib/systemd/system for unauthorized services set to run at boot. |
| Shell profile files | .bashrc, .profile, and /etc/profile.d scripts that execute on every login. |
| SSH authorized_keys | Unexpected public keys added to a user authorized_keys file, granting passwordless attacker access. |
| Web shells | Recently modified or unusually named files in the webroot, often disguised as legitimate application files. |
| Package manager history | APT or YUM logs showing unauthorized software installation used to establish tooling or persistence. |
Common Linux filesystems such as ext4 record access, modify, and change timestamps with more limited semantics than NTFS, and depending on mount options, access time updates may be disabled entirely. Examiners account for this by relying more heavily on log correlation and less on file timestamp inference alone.
We handle acquisition and analysis of Linux servers, web applications, and containerized workloads for business breach cases.
Containerized environments add a layer of complexity because the compromised process may run in an ephemeral container that no longer exists by the time an examiner is engaged.
A container that has been restarted or replaced loses its writable layer, so any evidence not captured before restart may be permanently lost.
Examiners review the base image and build pipeline to determine whether compromise occurred at build time or at runtime.
Kubernetes or similar orchestration platforms log pod creation, scaling events, and API access that can reveal attacker activity.
The Linux audit daemon, when enabled, records system calls and file access at the host level, surviving even if an individual container is destroyed.
Where the audit daemon and centralized container logging were not enabled before the incident, examiners work with whatever host and orchestration platform logs survived, and the resulting report will note the resulting evidentiary limitations honestly.
A defensible Linux server timeline correlates authentication events, persistence artifacts, and web application logs into a single sequence.
Disk imaging is just as important on Linux; the artifact locations differ but the need for a forensically sound copy does not.
History is one artifact among many; authentication logs, web server logs, and file timestamps often independently corroborate activity.
Cloud snapshots and provider level logging generally allow a sound forensic acquisition, though the process differs from physical hardware.
It makes it harder, not impossible, especially when host level audit logging and orchestration logs were enabled before the incident.
We investigate Linux server, web application, and containerized workload compromises for businesses, counsel, and insurers. Our examiners perform sound acquisition of physical, virtual, and cloud hosted Linux systems and produce findings that hold up to scrutiny from opposing experts, regulators, and courts.
Forensically sound acquisition of physical, virtual, and cloud hosted Linux systems with documented chain of custody.
Identification and timeline reconstruction of web shell deployment and use against web server access logs.
Systematic review of cron, systemd, shell profiles, and SSH configuration for attacker established persistence.
Investigation of containerized workload compromise using surviving host, image, and orchestration platform evidence.
A defensible determination of initial access and attacker duration on the system, written for non technical stakeholders.
Court qualified examiners able to explain Linux forensic methodology and findings under cross examination.
Consultations are confidential. We work directly with affected businesses, with outside counsel, and with cyber insurance carriers and brokers nationwide.
Elite Digital Forensics is an independent digital forensics firm serving businesses, attorneys, and insurers nationwide. Our examiners include former law enforcement forensic examiners who have testified as court qualified expert witnesses in state and federal proceedings. We do not sell security software and we do not manage client networks, so our findings carry no conflict of interest when the question is whether an environment was adequately secured.
Every engagement follows documented chain of custody, defensible acquisition methods, and reporting written for attorney review, insurer submission, regulator response, or courtroom use. Work performed at the direction of counsel is generally treated as attorney work product prepared in anticipation of litigation. Call (833) 292-3733 or request a confidential consultation.
Typically the authentication log, either auth.log or secure depending on the distribution family, since it records login attempts, sudo use, and often the earliest sign of unauthorized access.
They can significantly complicate an investigation by clearing shell history or log files, but authentication logs, web server logs, file system artifacts, and network evidence frequently survive and corroborate activity independently.
By reviewing recently modified or unusually named files in the webroot, comparing file hashes against known clean application code, and correlating suspicious file creation times with web server access log entries showing the file being requested.
No, but ephemeral containers can lose evidence on restart. Host level audit logging, container image analysis, and orchestration platform logs allow a meaningful investigation even when an individual container no longer exists.
Both schedule commands to run automatically, but systemd timers are the modern mechanism on systemd based distributions and are sometimes overlooked by examiners focused only on traditional cron locations.
They are useful but more limited than Windows NTFS timestamps in some configurations. Examiners corroborate file timestamps with log data rather than relying on them in isolation.
This content is for educational and informational purposes only and does not constitute legal advice. Elite Digital Forensics provides independent digital forensic services and expert witness testimony; we do not provide legal representation. Every case is fact specific; outcomes depend on the evidence, jurisdiction, and counsel. Retain qualified legal counsel for advice about your matter.
Elite Digital Forensics Assistant
By submitting this form, you consent to be contacted by email, text, or phone. Your information is kept secure and confidential. Reply Stop to opt out at anytime.
IMPORTANT: Please remember to check your spam or junk folder