Skip to content
Hermes Codex

Artifact Analysis: Ivanti Architecture & Versioning

1. The Offline Analysis Paradigm

Section titled “1. The Offline Analysis Paradigm”

When an Ivanti edge device is compromised, executing commands directly on the live shell is heavily restricted and forensically unsound. Threat actors frequently modify built-in binaries (like ls or ps) via rootkits to hide their presence.

The standard DFIR procedure requires acquiring a full disk image or a comprehensive file extraction (e.g., via a custom KAPE target) and mounting it on an isolated Linux forensic workstation. Throughout this guide, we assume the root file system of the compromised Ivanti appliance is mounted at /mnt/analysis/.

2. Under the Hood: Legacy vs. Modern Architecture

Section titled “2. Under the Hood: Legacy vs. Modern Architecture”

Ivanti’s software architecture has evolved. Identifying the underlying OS generation is critical, as it dictates the file paths and the attacker’s persistence capabilities.

Legacy Architecture

Targets: Ivanti Connect Secure (ICS) versions 9.x and 22.x, and most older EPMM deployments. Base: An aging Linux kernel, often heavily customized CentOS 6 or Linux 2.6. Security Posture: The root file system is mounted as Read-Only by default to prevent tampering, but crucial directories (/var, /tmp, /data) remain writable. It lacks SELinux. This environment is highly conducive to traditional Perl/CGI webshells.

Modern Architecture

Targets: Newer versions of ICS (often branded as ISA - Ivanti Secure Access) running 25.x and above. Base: A modern OS base (likely AlmaLinux or recent RHEL). Security Posture: Introduces SELinux in Enforcing mode. This fundamentally alters the attacker’s TTPs, as dropping webshells in arbitrary web directories is blocked by MAC (Mandatory Access Control) policies.

3. The Dual-Partition Trap (Active vs. Rollback)

Section titled “3. The Dual-Partition Trap (Active vs. Rollback)”

This is the most critical pitfall during offline disk analysis. To facilitate safe firmware upgrades, Ivanti appliances utilize a dual-partition system (often referred to as “Slot 1” and “Slot 2”).

  • The Active Partition: The system that was running at the time of the acquisition.
  • The Inactive (Rollback) Partition: The previous firmware version, kept as a backup.

Identifying the Active Partition Offline

Section titled “Identifying the Active Partition Offline”

To determine which partition was actively running the compromised OS, analysts must interrogate the bootloader and file system metadata from their analysis workstation.

  1. Analyze the GRUB Bootloader: Check the GRUB configuration file on the mounted boot partition to see which menu entry is set as the default. cat /mnt/analysis/boot/grub/grub.conf (or grub.cfg). Look for the default=X line.
  2. MAC Times Verification (The Failsafe): Utilize File System MAC times. Check the Last Access (atime) or Modification (mtime) timestamps on dynamic directories like /var/log across both partitions. The active partition will have timestamps correlating to the time of the incident or the forensic acquisition. The inactive partition’s timestamps will be months or years old.

4. Firmware Fingerprinting (Versioning)

Section titled “4. Firmware Fingerprinting (Versioning)”

To confirm whether the appliance was vulnerable to a specific zero-day (e.g., CVE-2026-1281), you cannot guess based on file dates. You must extract the exact build number.

get_ics_version.sh
# The reference file is usually located at the root of the configuration directory.
cat /mnt/analysis/etc/ive-version


# Expected Output Example:
# 9.1R18 (build 24603)

5. File System Targeting: Where to Hunt

Section titled “5. File System Targeting: Where to Hunt”

When analyzing the mounted file system, DFIR analysts must focus their efforts on specific virtual mount points and directories where attackers are forced to operate.

  • / (Root): Contains the core OS and binaries. Often read-only on legacy versions. Attackers rarely touch this unless deploying advanced rootkits or patching native CGI binaries.
  • /data or /var: The Hot Zone. This is the writable partition. It contains system logs, VPN configurations (/data/system/), and is the primary dumping ground for threat actor webshells (because they cannot write elsewhere). If your forensic collection (like a KAPE triage) missed the /data directory, you are flying blind.
  • /home: Often empty on ICS, but heavily utilized by administrative accounts on EPMM. Crucial for extracting SSH Artifacts (authorized_keys) and the Bash History (.bash_history) of compromised administrators.

6. The Analyst’s Starting Checklist

Section titled “6. The Analyst’s Starting Checklist”

Before executing a single grep or YARA scan against the mounted image, ensure you have completed the following:

  1. Confirm the Partition: “Am I absolutely certain this is the partition that was active during the breach window?”
  2. Record the Version: Extract the exact build number and cross-reference it immediately with Ivanti Security Advisories and CISA KEV to identify potential initial access vectors.
  3. Locate the /data Mount: Verify that the writable data partition was successfully acquired and mounted correctly within your /mnt/analysis/ tree.

References & Further Reading

Section titled “References & Further Reading”