Incident Response and Digital Forensics: The Definitive Pillar Guide to Regain Control

A cyber attack is not a question you ask a consultant after the fact. It's an emergency you manage in minutes, not days. If you don't have a tested Incident Response plan, you're betting it won't happen to you. We, at Meteora Web, see it every day: small businesses discovering a ransomware at 8 AM and still looking for the technician's number at 10 AM. You can't afford that.

This guide is your operational manual for Incident Response (IR) and Digital Forensics (DFIR). No academic theory: processes, commands, decisions we have applied to real Linux servers, WordPress e-commerce sites, and client cloud infrastructures. Let's start from the concrete problem: you've been hit. What do you do immediately? And how do you prepare to never be caught off guard again?

1. Incident Response Framework: Phases That Save Revenue

An IR framework is not bureaucracy. It's a checklist that keeps you lucid when everything is burning. We follow the NIST SP 800-61 standard, adapted to the small business reality: Preparation, Detection & Analysis, Containment/Eradication/Recovery, Post-Incident Activity.

Preparation: 90% of Success

Preparation means having tools and runbooks ready. You don't need a million-dollar SOC. You need:

• A centralized log server (ELK, Graylog, or even just Rsyslog).
• Immutable offline backups (tested monthly).
• Secure vault for cloud provider, DNS, hosting credentials.
• A direct contact with a DFIR provider (we do that, but better to have you in our contacts).

Real example: A client e-commerce had all backups on the same AWS account as the production server. Ransomware encrypted everything, including backups. Recovery impossible. We migrated them to offline backups on S3 Glacier with an immutable retention policy. Low cost, saves the company.

Detection & Analysis: Don't Ignore Signals

An attack doesn't come with a flashing sign. You see it in small things: a login from a suspicious IP, a traffic spike, a process consuming CPU for no reason. 90% of our IR interventions come from an alert someone ignored for days.

Basic tools: Google Search Console for WordPress sites (tells us if a site is compromised), SIEM like Wazuh (open source, we install it on servers), analysis of HTTP access logs (scattered 500 errors? Read the log file).

Damage calculation: We come from accounting. When an attack stops an e-commerce for 6 hours, we're not talking reputation: we're talking lost revenue. A site generating €5,000 a day loses €1,250 in 6 hours. Add recovery cost, forensics, customer communication. An IR plan costs much less.

2. Digital Forensics: Evidence Acquisition and Chain of Custody

If the incident ends up in court (and it increasingly does), every file you touch without method becomes inadmissible. The chain of custody records who, when, how, and why interacted with the evidence.

Forensic Acquisition of a Linux Server

Never run shutdown -h now on an attacked server. You lose volatile memory. Basic procedure:

# 1. Acquire RAM with LiME or fmem
sudo insmod lime.ko "path=/mnt/forensics/ramdump.mem format=lime"

# 2. Acquire disk with dd (or ddrescue for bad blocks)
sudo dd if=/dev/sda of=/mnt/forensics/diskimage.raw bs=4M conv=noerror

# 3. SHA256 hash of every acquired file
sha256sum /mnt/forensics/*.raw >> /mnt/forensics/hashes.txt

# 4. Log everything in a timestamped document (chain of custody)

Golden rule: Never mount the original filesystem in write mode. Use hardware or software write-blocker (e.g., mount -o ro,loop).

Acquisition from E-commerce (WordPress/MySQL)

Time is critical because the site must come back online. We proceed in parallel: clone the filesystem via rsync to a forensic server, dump the database with mysqldump using --single-transaction and --hex-blob, capture web server logs and error_log. Then restore from a clean backup while analyzing the copy.

3. Malware Analysis: Sandbox, Detonation, Behavioral Analysis

Never run a suspicious malware on your work machine. Use an isolated sandbox. Free and powerful tools:

• Cuckoo Sandbox (open source, needs dedicated VM)
• Any.Run (online, interactive, good for quick analysis)
• Joe Sandbox (cloud version with detailed reports)

Real case: A client received an email with a .doc attachment that called a payload from a remote server. We uploaded the document to Any.Run, observed connections to a known C2 IP, and blocked that domain at DNS level. Without analysis, we might have cleaned the PC but left the backdoor.

Behavioral Analysis: What to Look For

Modern malware doesn't always write files to disk. It leaves traces in the registry (Windows), cron jobs (Linux), or modifies boot. Use Process Monitor (Procmon) on Windows or lsof/strace on Linux to see in real time which resources are being touched.

4. Memory Forensics: Volatility and RAM Analysis

RAM contains everything: running processes, network connections, plaintext passwords, and even malware code trying to hide. Volatility is the go-to tool. Example analysis on a Linux RAM dump:

# Identify the system profile
volatility -f ramdump.mem imageinfo

# List active processes
volatility -f ramdump.mem --profile=LinuxUbuntu1804x64 linux_pslist

# Search for hidden processes (rootkits)
volatility -f ramdump.mem linux_pstree

# Extract command line of each process
volatility -f ramdump.mem linux_cmdline

# Capture network connections at dump time
volatility -f ramdump.mem linux_netstat

Caution: Memory must be acquired while the server is on, before any operation. If the server has already been rebooted, you've lost the most important evidence.

5. Log Analysis for IR: SIEM, Correlation, and Pivot

Logs are the timeline of an attack. Without centralized logs, you're blind. We use Wazuh (open source, based on OSSEC + Elastic) to aggregate logs from servers, firewalls, applications. Example correlation rule (decoded) to detect brute force on WordPress:

  wordpress
  authentication
  ^.*POST /wp-login.php.*
  ^.*error: Incorrect password.*

Pivoting from one indicator to another: If an IP appears in access logs and also in firewall logs as a connection to a non-standard port, that's a pivot. The same IP appearing in a malware alert on one PC could be the C2 of an ongoing attack.

6. Ransomware IR: Containment, Decryption, Recovery

Ransomware is the most devastating incident for a small business. There's no backdoor: if it encrypts data, either you have clean backups or you pay (and often don't get data back). Our flow:

1. Immediate isolation: Shut down the network of the affected server, unplug the network cable, do not turn off the server (you might lose RAM with decryption keys).
2. Identify the variant: Use ID Ransomware (id-ransomware.malwarehunterteam.com) by uploading the ransom note or file extension. Often free decryptors exist.
3. Recover from backup: If you have immutable backups, restore on clean hardware. Do not trust the original server until it has been wiped and the infection vector eliminated.
4. Post-incident forensics: Acquire a forensic copy of the attacked server to understand the entry vector (often exposed RDP, phishing, plugin vulnerability).

Clear stance: We never recommend paying. If you pay, you finance the next attack. But we understand the pressure: if you have no backups, the business can collapse in 48 hours. That's why preparation means regularly tested backups.

7. Network Forensics: Wireshark and Malicious Traffic Analysis

Network traffic doesn't lie. Even if malware deletes local logs, the firewall and router recorded connections. Wireshark is the Swiss army knife.

Capturing Traffic During an Incident

# Capture on a specific interface, no memory buffering
sudo tcpdump -i eth0 -s 0 -w /mnt/forensics/traffic.pcap -C 100 -W 10

Analyzing a C2 Connection

Filter for suspicious IP, then tcp.flags.syn==1 to see outgoing connections. Malware often uses DNS queries to algorithmically generated domains (DGA): filter dns.qry.name and look for random hex strings.

Example: Analyzing a client's pcap, we noticed an HTTPS connection to a Russian IP on port 443 with a self-signed certificate. The DNS domain was registered 24 hours earlier. That was the C2. We blocked the IP at the firewall and the malware stopped communicating.

8. Timeline Analysis: Reconstructing an Attack Chronologically

Rebuilding events in temporal order is the most delicate part. Every piece of evidence (logs, file system, RAM, traffic) has a timestamp. We use Plaso (log2timeline) to extract super detailed timelines.

Practical steps:

• Collect all logs: system (auth.log, syslog, Windows Event Log), application (Apache, NGINX), firewall.
• Convert to a common format (CSV or JSON).
• Load into a spreadsheet or Timesketch (open source GUI) and sort by timestamp.
• Identify the first event: first unauthorized login, first malicious file download, first C2 connection.

Real case: A WordPress site was defaced. The timeline showed that FTP access was used 3 days earlier from a different IP than usual. The client had used the same password for FTP and email, and a phishing attack stole the email credentials. The defacement was just the tip of the iceberg: they had already lost the email account.

9. Threat Hunting: Proactive Threat Search

Don't wait for the alert. Actively seek Indicators of Compromise (IoCs) before they cause damage. We dedicate a weekly slot for each client: network log analysis, search for known hashes (VT), verification of anomalous processes.

Simple technique: Use YARA to scan the filesystem for malware patterns. Example YARA rule to detect a PHP webshell:

rule webshell_php_base64 {
    strings:
        $a = "base64_decode" nocase
        $b = "eval(" nocase
        $c = "system(" nocase
    condition:
        all of them
}

Run YARA on web directories every night. False positives decrease over time.

10. Post-Incident Review: Lessons Learned and Continuous Improvement

The incident doesn't end when the site is back online. It ends when you've written a report and updated your processes. The post-mortem must answer three questions:

• How did the attacker get in? (Root cause)
• Why didn't we detect it earlier? (Gap in controls)
• What will we do to prevent it from happening again? (Concrete actions with deadlines and owners)

Example from our work: After a ransomware on a client server, we discovered the entry vector was an outdated WooCommerce plugin. Action: enabled automatic updates for critical plugins, implemented a WAF (Wordfence), and daily offsite backups. Six months later, another exploit attempt was blocked because the plugin was already updated.

In Summary — What to Do Now

Don't wait for an incident to wake you up at 3 AM. Here are immediate actions:

1. Write an Incident Response plan even on two pages. Define roles (who calls, who isolates, who analyzes), tools (log server, backups, sandbox), and containment procedures.
2. Test your backups today. Restore an old file from immutable backup. If it doesn't work, the backup doesn't exist.
3. Centralize logs on an open source SIEM (Wazuh or Grafana Loki). At least web server errors and login logs.
4. Install a YARA agent on critical machines (web server, database) and scan periodically.
5. Run a table-top exercise: simulate a ransomware with your team. You'll discover flaws you never imagined.

We, at Meteora Web, accompany businesses through the entire DFIR journey: from preparation to emergency management to post-incident forensics. If you have doubts or if an attack is already underway, contact us immediately. Book an emergency consultation.

Useful links:

• NIST SP 800-61 Rev. 2 - Incident Response
• SANS DFIR - Digital Forensics Incident Response
• Volatility Foundation - Memory Forensics

Also read:

• AI-Powered Deception Changes the Game: Defenders Need Truth at Machine Speed
• VPN: When You Really Need It and How to Choose the Right One
• WordPress Security: The Definitive Pillar Guide