Analyzing Imunify360 Logs for Post‑Compromise Forensics

When a web‑hosting account is compromised, the first thing you need is reliable evidence. Imunify360, the security suite offered by AtoZNode, blocks malware in real time and keeps detailed logs that can be turned into a forensic trail. This article shows how to locate, interpret, and export those logs so you can understand what happened, contain the breach, and provide solid information to your incident‑response team or legal counsel.

1. Why Imunify360 Logs Matter for Forensics

• Timestamped events – Every detection, quarantine, and remediation is recorded with a precise date and time, helping you build a timeline.
• File paths and hashes – The logs capture the full path of infected files and their SHA‑256 hashes, which are essential for verifying the exact payload.
• Source IP addresses – When a malicious request triggers a detection, Imunify360 logs the client IP, user‑agent, and request URI.
• Action taken – Whether the file was deleted, moved to quarantine, or left untouched, the log shows the exact response.

Because the logs are stored locally on the server in a structured JSON format, you can query them with standard Linux tools or feed them into a SIEM for deeper analysis.

2. Locating the Imunify360 Log Files

Imunify360 writes its logs to /var/log/imunify360. The files most useful for a compromise investigation are:

1. imunify360.log – General operational log (info, warnings, errors).
2. malware.log – Detailed records of each malware detection.
3. audit.log – Records of user‑initiated actions (e.g., manual quarantine).

All three files are plain‑text JSON lines, making them easy to parse with jq or grep.

3. Installing the Tools You’ll Need

Before you start, ensure you have the JSON processor jq and the log‑viewer less installed. The commands differ slightly between Debian‑based and RHEL‑based distributions.

Debian / Ubuntu (apt)

# Update package index
sudo apt update

# Install jq and less
sudo apt install -y jq less

AlmaLinux / Rocky Linux / RHEL (dnf)

# Refresh metadata
sudo dnf makecache

# Install jq and less
sudo dnf install -y jq less

On Windows Server, you would typically pull the log files via SFTP and use a JSON viewer such as Notepad++ with a JSON plugin.

4. Building a Timeline of the Compromise

A clear timeline helps you answer three critical questions: when did the attacker first gain access, what actions did they perform, and when did Imunify360 intervene?

Step 1 – Filter by date range

# Replace 2024-09-01 and 2024-09-07 with the period you are investigating
jq 'select(.timestamp >= "2024-09-01T00:00:00Z" and .timestamp <= "2024-09-07T23:59:59Z")' /var/log/imunify360/malware.log > /tmp/malware-sept.json

This command reads malware.log, keeps only entries whose timestamp falls within the specified window, and writes the result to a temporary file.

Step 2 – Extract key fields

jq -r '.timestamp + "\t" + .file_path + "\t" + .sha256 + "\t" + .action + "\t" + .source_ip' /tmp/malware-sept.json | less -S

The -r flag outputs raw strings, and the less -S call lets you scroll horizontally if the lines are long. The columns you’ll see are:

• Timestamp
• File path on the server
• SHA‑256 hash of the malicious payload
• Action taken by Imunify360 (e.g., quarantined, deleted)
• Source IP that triggered the detection

Step 3 – Correlate with web‑server access logs

If you run Apache or Nginx, you can match the source IPs to request logs. Here’s an example for Apache on Ubuntu/Debian:

grep -F -f <(cut -f5 /tmp/malware-sept.json) /var/log/apache2/access.log | less

For AlmaLinux/RHEL with Nginx, replace the log path accordingly:

grep -F -f <(cut -f5 /tmp/malware-sept.json) /var/log/nginx/access.log | less

This cross‑reference reveals which HTTP request delivered the malicious file, helping you pinpoint the vulnerable endpoint (e.g., an outdated plugin or an insecure upload script).

5. Exporting Evidence for External Review

When you need to share findings with a security consultant, law‑enforcement agency, or internal audit team, provide a concise CSV and a copy of the original JSON lines.

Generate a CSV file

jq -r '[.timestamp, .file_path, .sha256, .action, .source_ip] | @csv' /tmp/malware-sept.json > /tmp/malware-evidence.csv

The resulting malware-evidence.csv can be opened in spreadsheet software, and each row is a self‑contained record of an event.

Archive the raw logs

tar -czf /tmp/imunify360-logs-$(date +%F).tar.gz /var/log/imunify360/*.log

This creates a compressed archive named with today’s date, preserving the original timestamps and file permissions.

6. Hardening After the Forensic Review

Once you have identified the entry point, take the following steps to reduce the chance of a repeat incident:

• Update all CMS, plugins, and libraries to the latest stable versions.
• Restrict file‑upload locations and enforce MIME‑type checks.
• Enable Imunify360’s proactive protection (e.g., Web Application Firewall rules) if not already active.
• Rotate compromised credentials and enforce strong passwords or SSH keys.
• Review cron jobs and scheduled tasks for unexpected entries.

Document each remediation action in a separate log (e.g., /var/log/imunify360/hardening.log) so you have a complete audit trail.

Conclusion

Imunify360 does more than block malware—it creates a forensic‑ready record of every threat it encounters. By locating the JSON logs, filtering them with jq, correlating IP addresses with web‑server access logs, and exporting the data in CSV and archive formats, you can build a clear, court‑admissible timeline of an account compromise. The final hardening steps ensure that the lessons learned turn into stronger defenses for your VPS or dedicated server on AtoZNode.