Proxmox and Adversaries

Introduction

❗take the time to read the bottom of this page.

Proxmox is a virtualisation technology stack that is quickly becoming the go to product solution for organisations looking to heal the wounds left by Broadcoms acquisition of VMWARE. This post aims to equip detection engineers with the knowledge to identify adversary behaviour and implement their own detection logic. This post explores Proxmox deployments on Linux hosts only

The content shared in this article is also a demo of Sonny's (puppy) (https://detection.wiki/labs/) initiative to promote more comprehensive sharing of artefacts and audit logs in threat research posts. This initiative aims to provide every reader with the raw logs for each item addressed in the research and the tools to easily upload and test those logs in a kusto cluster without any friction or manually parsing.

Explore the systems that make sharing logs with each other important here: https://detection.wiki/blog/triaging-a-threat-report/

ℹ️ Blogger supports artefact sharing poorly so all the key details are kept here: https://connectedlucy.github.io/proxmox/2026/06/13/proxmox_death.html

Skip to the above link for the most interesting parts of the post.



Adversary techniques

Proxmox's non appliance nature means that most deployment instances are directly compatible with old and well tested adversary playbooks for linux compromises. Generic Linux detections are plentiful and highly relevant to proxmox installations. This post focuses on unique complexity introduced by the proxmox installation and will only mention genetic Linux detections were the matching behaviour is exceptionally common.

Initial Access

Authentication is managed through realms that are configured individually in the Proxmox GUI interface. By default Proxmox provides two realms PVE and PAM. The PAM realm utilises the host based user management controls exposing the root account for the host into the Proxmox GUI experience. In addition to the default realms LDAP is also configurable. 

All configured realms are easily enumerated by making an unauthenticated GET request to /api2/json/access/domains/. Once successfully authenticated a list of assigned permissions is sent along with the granted ticket. Later in the deep dive section I explore how to detect adversaries exploring the API endpoints and brute forcing valid accounts.

Living off the land

After gaining access to a PVE node adversaries are afforded a wealth of native binaries that allow further compromise without the need for additional capability staging. 'pvesh' is the powerful utility available affording its users the ability to enumerate, change and destroy most the resources in a Proxmox environment. As such it should be closely monitored for abuse. 

Using the pvesh utility an adversary can enumerate and destroy Guest VMs with commands as simple as:

Guest VM details :: pvesh get /nodes/pve/qemu/707/status/current/

Destroy Guest VM :: pvesh delete /nodes/pve/qemu/707


Extensive effort should undertaken to model the usage of the Proxmox CLI tools in your environment. Use of tools like pvesh are not logged in the pveproxy audit trail and can only be observed via process execution and journald event streams.

In my experience system administrators rarely call pve cli tools from a direct SSH session and instead choose to utilise a shell spawned from the GUI interface inside which they execute commands.

🌟 Model PVE CLI usage using the following parameters:

  • SSH session relationship
  • Diversity of pve cli usage
  • Directory cli tool invoked from

ℹ️ List of other Proxmox tools can be found here https://pve.proxmox.com/pve-docs/#_proxmox_ve_manual_pages


In addition to the native pve binaries Proxmox utilises a number of local config files that adversaries can abuse to maintain persistence and evict responders trying to contain a threat. 

In particular adversaries can append IP addresses using IP sets in the host file /etc/pve/firewall/cluster.fw. IP sets allow for control of the firewall without the need for configuring all the typical syntax a rule might need like destination, port and interface. Using the IP set '[IPSET blacklist]' adversaries can define a list of administrative subnets and block all remote access attempts.

These config files are assigned READ - WRITE for the root account only but should be monitored using the AuditD configuration detailed below.


Logs Overview

To ensure appropriate coverage of audit activity collected from the proxmox product, supplementary host system activity must also be collected to provide detection coverage into techniques that jeopardize the integrity of the systems at the host level.

AuditD

Host system visibility can primarily be achieved through auditd. Auditd is a well supported third party package that can collect telemetry for a wide range operating system features. Telemetry collection is defined in a configuration file stored locally on each PVE node.

Through the collection of the host based telemetry we can aim to generate extended coverage such as:

  • Security control evasion
    • log collector tampering
    • local account changes
    • firewall changes
    • log file tampering
  • Remote access monitoring
    • SSH
  • File system monitoring
    • executable files in sensitive directories
    • direct modification of the PVE installation folder
  • Process execution
    • pve cli usage
    • system enumeration
    • remote connections
🌟 If you choose to utilise a common public auditd configuration such as those provided by app armour or Florian. Ensure you append the following lines to the config file:


## Proxmox VE
# configuration files
-w /etc/pve/ -p wa -k pve_config_changes

# management tools
-w /usr/sbin/qm -p x -k pve_qm_exec
-w /usr/sbin/pct -p x -k pve_pct_exec
-w /usr/bin/pvecm -p x -k pve_cluster_exec
-w /usr/sbin/pvesm -p x -k pve_storage_exec
-w /usr/bin/pveum -p x -k pve_user_exec
-w /usr/bin/pvesh -p x -k pve_shell_exec

# Proxmox daemon
-w /usr/bin/pvedaemon -p x -k pve_daemon_exec
-w /usr/bin/pveproxy -p x -k pve_proxy_exec

# Perl Libraries.
-w /usr/share/perl5/PVE/ -p wa -k pve_core_perl_changes




Proxmox Environment Logs

Interactions directly in the proxmox GUI experience are stored in the log file /var/log/pveproxy/access.log. This log file contains API requests handled by the ‘pveproxy' system service. Once received the requests are then sent to 'pvedaemon’ and executed. Interactions are generally categorised through the corresponding HTTP request type where deleting a resource or configuration will generate a log with the DELETE request type and modifying configuration items will generate a POST or PATCH request type.

JournalD

The proxmox environment registers its own records directly to JournalD by default. These logs are a simplified abstraction of the ‘pveproxy’ logs mentioned above and extend into node or cluster tasks (jobs) that were not routed through the proxy. Importantly not all actions are logged into journal in particular items like user creation and modification or cluster changes must be captured through the other log sources detailed in this post.

Example: Event generated from deletion of virtual machine

<root@pam> delete snapshot VM 3411: blueturtle

To ensure appropriate log coverage the following unit files tracked by journalD must be collected:

  • pvedaemon.service
  • pve-cluster.service
  • pveproxy.service
  • pvefw-logger.service
  • proxmox-firewall.service
  • pvesh.service
  • pve-guests.service
  • pvescheduler.service
  • ssh.service
  • cron.service

Deep dive into analytics 

In the sister post at the link below you can find full log samples for you to upload into your own SIEM

ℹ️ This post continues in the resource 

Don't use AI

Often people think that delegating tasks to AI tools will free up time to do other more worthwhile things. This is the first mistake, the labour involved in a task is important even if the reason why your doing it is not.

Often people think that the world's adoption of AI tools is much like the adoption of the calculator or mobile phones. This is the second mistake. AI tools have torn from our world it's most valuable possessions and so born from the dark pits of soulless executives with dollar signs gleaming in their eyes they emerged and they do work. They work too well. It's creators have developed a medium from which humans can pour out unconstrained thoughts. Thoughts that carry no beauty or deliberateness.

The modern computer took away things from us too but in doing so it pushed the boundaries of what can be done into new areas never before perceived. This exchange seems to of been worthwhile. AI tools do not offer a similar exchange, their ability to act as a surface without rough edges or muddy reflections means there's no room left for us. No way to abstract the information further pressing it's users against a ceiling of higher order thinking that is in no way nourishing.

Researching adversary behaviour and building systems necessitates you doing the hard parts. If your new to the work you need the depth lost in AI tools to fall in love and if your already committed to the work your knowledge needs to stretch across as much complexity as possible to keep your wisdom turning into ramblings. Using AI tools writing detections will make you worse at detecting adversary behaviour.

All energy is only borrowed and one day you have to give it back. Don't waste yours on AI.

Popular

Brilliance in the Basics

Investigate

Endpoint on Adrenaline : One

Endpoint on Adrenaline 3

Endpoint on Adrenaline Two

Investigate Three

Investigate Two

Writing detections when stuck with EDR

Standardized Note Taking Format For Analysts