Digital Forensics & Incident Response on VPS
Digital Forensics & Incident Response on VPS: Investigation and Recovery Process After Attack
When your VPS gets hacked, a fast and correct response determines the extent of the damage. Digital Forensics & Incident Response (DFIR) helps you collect evidence, identify the root cause, isolate vulnerabilities, and safely restore the system. This article provides a detailed professional guide on how to investigate and remediate after a VPS breach, focusing on reading system logs, analyzing suspicious processes, and fully patching vulnerabilities.
1. Golden Rules When Your VPS Is Hacked
Before doing anything, follow this order:
- Stay Calm: Avoid panic and do not shut down the server suddenly (you may lose critical evidence).
- Isolate the System: Disconnect network if necessary but keep the machine running for data collection.
- Do Not Alter Evidence: Use read-only tools during analysis.
- Document Everything: Record timestamps, commands executed, and results.
// Incident Response Basic Workflow
interface Incident {
incidentId: string;
detectedAt: Date;
attackType: "brute-force" | "exploit" | "malware" | "ransomware";
severity: "Low" | "Medium" | "High" | "Critical";
}
function initialResponse(incident: Incident): void {
console.log(`[DFIR] Starting handling of incident ${incident.incidentId}`);
console.log(`[Step 1] Isolate VPS - Disable unnecessary inbound firewall rules`);
console.log(`[Step 2] Create disk snapshot to preserve evidence`);
console.log(`[Step 3] Start collecting volatile data (RAM, processes)`);
}
2. Essential Tools to Prepare on Ubuntu VPS
Install these basic forensics tools immediately:
- sysdig, osquery, auditd — System monitoring
- fail2ban, logwatch, rkhunter — Rootkit detection
- volatility, autopsy — Memory analysis (advanced)
- net-tools, ss, tcpdump — Network analysis
3. Reading and Analyzing System Logs
Logs are the most important source of evidence. Focus on these files:
- /var/log/auth.log — SSH login attempts
- /var/log/syslog & kern.log — Kernel and system errors
- /var/log/nginx/access.log — Web server logs
// Simple Log Parser in TypeScript
interface LogEntry {
timestamp: string;
hostname: string;
process: string;
message: string;
ip?: string;
}
function parseAuthLog(logContent: string): LogEntry[] {
const lines = logContent.split('\n');
const suspicious: LogEntry[] = [];
lines.forEach(line => {
if (line.includes("Failed password") || line.includes("Accepted password")) {
const entry: LogEntry = {
timestamp: line.substring(0, 15),
hostname: "vps-server",
process: "sshd",
message: line,
ip: extractIP(line)
};
suspicious.push(entry);
if (line.includes("Failed password")) {
console.warn(`[ALERT] Bruteforce attempt from ${entry.ip}`);
}
}
});
return suspicious;
}
function extractIP(line: string): string {
const match = line.match(/\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b/);
return match ? match[0] : "unknown";
}
4. Detecting Suspicious Processes (Malicious Processes)
Unusual processes are often signs of malware or backdoors.
// Process Analyzer
interface ProcessInfo {
pid: number;
user: string;
cpu: number;
memory: number;
command: string;
suspicious: boolean;
}
function analyzeRunningProcesses(processList: ProcessInfo[]): ProcessInfo[] {
return processList.map(proc => {
const isSuspicious =
proc.command.includes("/tmp/") ||
(proc.user === "root" && proc.command.includes("curl")) ||
proc.command.length > 200 ||
(!proc.command.startsWith("/usr") && !proc.command.startsWith("/bin"));
if (isSuspicious) {
console.error(`[MALICIOUS] Suspicious process detected: ${proc.command} (PID: ${proc.pid})`);
}
return { ...proc, suspicious: isSuspicious };
});
}
// Example usage
const processes: ProcessInfo[] = [
{ pid: 1234, user: "www-data", cpu: 85, memory: 1240, command: "./hidden_miner", suspicious: false },
{ pid: 5678, user: "root", cpu: 12, memory: 340, command: "/usr/sbin/sshd", suspicious: false }
];
analyzeRunningProcesses(processes);
5. Analyzing Network Connections & Backdoors
Use commands like `ss -tuln`, `netstat`, or `tcpdump` to inspect suspicious connections.
// Network Forensics Simulator
interface NetworkConnection {
protocol: string;
localPort: number;
foreignAddress: string;
state: string;
process?: string;
}
function detectSuspiciousConnections(conns: NetworkConnection[]) {
conns.forEach(conn => {
if (conn.foreignAddress.includes(":4444") ||
(conn.state === "ESTABLISHED" && conn.localPort === 22 && conn.process !== "sshd")) {
console.error(`[CRITICAL] Possible reverse shell or C2 server: ${conn.foreignAddress}`);
}
});
}
6. Isolation and Vulnerability Remediation Process
- Change all passwords (root, users, database, SSH keys).
- Update the system: `apt update && apt upgrade -y`
- Disable root login via SSH.
- Set up strict Fail2Ban + UFW rules.
- Scan for malware with ClamAV and rkhunter.
- Restore from a clean backup (verify first).
7. Best Practices for Future Prevention
After recovery, apply these measures:
- Enable automatic security updates.
- Use SSH Key authentication instead of passwords.
- Install Intrusion Detection System (OSSEC or Wazuh).
- Centralize log monitoring with ELK Stack or Loki + Grafana.
- Follow the 3-2-1 backup rule.
8. Conclusion: DFIR Checklist After a Hack
Before bringing the VPS back to production, verify the following:
- Have you isolated the system and created a snapshot?
- Have you analyzed logs, processes, and network connections?
- Have you identified the attack vector (which vulnerability)?
- Have you changed all credentials and patched vulnerabilities?
- Have you implemented long-term monitoring and hardening?
- Do you have a clear backup and disaster recovery plan?
Digital Forensics & Incident Response not only helps recover from incidents but also strengthens your entire VPS infrastructure. Treat every hack as a valuable lesson to build a more secure system in 2026.
Hope this guide helps you confidently handle and investigate security incidents on your VPS!
