In modern IT infrastructure, virtualization technology has become a core element maximizing resource efficiency and flexibility. However, security in virtualized environments presents complex challenges different from traditional physical server environments. Monitoring activities within a Virtual Machine (Guest) is particularly crucial for security and compliance. Traditional agent-based monitoring methods require installing additional software inside the Guest OS, creating a possibility for attackers to disable or bypass the agent. Furthermore, the separated trust domains between the Guest OS and the hypervisor make it difficult to detect stealthy threats originating within the Guest OS.
This awareness highlights the importance of Virtual Machine Introspection (VMI) technology. VMI is a technique that observes and analyzes the internal state of a Guest OS externally at the hypervisor level, allowing monitoring of processes, memory, and file system activities without installing an agent on the Guest OS. This provides an independent security observation point even if the Guest OS is compromised, helping to effectively detect stealthy threats like rootkits or malware. From a customer's perspective, VMI transforms into an essential technology for eliminating blind spots in existing security solutions, strengthening resilience against attacks, and fulfilling regulatory compliance requirements.
Understanding Virtual Machine Introspection (VMI) and libvmi
VMI is a technique where the hypervisor or virtualization management tools directly inspect the Guest OS's memory, CPU registers, storage devices, and more to ascertain its internal state. This makes it a powerful security monitoring tool because it can bypass the Guest OS's attempts to protect or hide itself, extracting information at the hypervisor level. A key advantage of VMI is its transparency to the Guest OS. This means that everything happening inside the Guest OS can be fully understood externally, making it difficult for attackers to evade detection mechanisms even if they compromise the Guest OS.
libvmi is an open-source library that helps in easily utilizing these VMI capabilities. It integrates with various hypervisors such as KVM, Xen, and VMware, providing an API to efficiently access and analyze the Guest OS's memory address space, process lists, kernel data structures, and more. libvmi uses the Guest OS's kernel symbol information to identify the location and meaning of specific data structures, thereby providing an abstraction layer that allows user-level interpretation of complex internal Guest OS information. From a decision-maker's perspective, libvmi provides a cost-effective foundation for building a powerful security monitoring system without directly dealing with complex hypervisor internal mechanisms.
Environment Setup and Prerequisites
The process for building and installing libvmi is as follows. The example is based on Ubuntu 22.04 LTS.
Prerequisites
- Host OS: Linux distribution (Ubuntu 20.04 LTS or later, or CentOS 7/8 or later)
- Virtualization Platform: KVM/QEMU must be installed and enabled. (Can be checked with the
virsh list --allcommand) - libvmi Dependencies: Libraries required for building and running, such as GCC, make, flex, bison, libvirt-dev, python3-dev, json-c-dev.
- Guest OS: Linux-based virtual machine to be monitored (Ubuntu or CentOS recommended)
- Guest OS Kernel Debug Information: Kernel headers and debug symbol packages corresponding to the Guest OS must be installed. This is essential for libvmi to accurately identify the Guest OS's kernel data structures.
- Basic Knowledge: Understanding of C programming language, Linux commands, and virtualization concepts is required.
Environment Setup
libvmi를 빌드하고 설치하는 과정은 다음과 같습니다. 예시는 Ubuntu 22.04 LTS를 기준으로 작성되었습니다.
1. Install required dependency packages:
sudo apt update
sudo apt install -y build-essential automake libtool flex bison libjson-c-dev
libvirt-dev python3-dev pkg-config cmake git
# KVM/QEMU 관련 패키지 설치 확인
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst virt-manager2. Download and build libvmi source code:
git clone https://github.com/libvmi/libvmi.git
cd libvmi
./autogen.sh
./configure --enable-python --enable-xen --enable-kvm --enable-coredump # 필요한 하이퍼바이저 및 기능 활성화
make
sudo make install
sudo ldconfig # 라이브러리 경로 갱신3. Create libvmi configuration file (/etc/libvmi.conf):
You must set up a profile that matches the Guest OS name and kernel version. The following is an example for an Ubuntu 22.04 LTS Guest VM. You must accurately check and modify the Guest VM's name and kernel version.
# /etc/libvmi.conf 예시
<vmi name="ubuntu2204_guest">
<connection type="kvm" name="/var/run/libvirt/libvirt-sock"/>
<domain name="ubuntu2204"/>
<os type="Linux"/>
<dtb addr="0x0"/>
<efi addr="0x0"/>
<profile type="rekall" url="file:///usr/local/share/libvmi/rekall/vmlinux-ubuntu-22.04.profile"/>
<!-- 또는 Volatility 3 프로파일 경로를 지정합니다. -->
</vmi>4. Prepare Guest OS kernel debug information:
You must extract the vmlinux file corresponding to the kernel version running on the Guest OS or generate a Rekall/Volatility3 profile. This is essential for libvmi to correctly interpret the Guest OS's internal data structures. For example, if using a Rekall profile, you can prepare it as follows. You must check the actual kernel version of the Guest OS and create a corresponding profile.
# Guest OS에서 vmlinux 추출 및 rekall 프로파일 생성 (혹은 pre-built 프로파일 사용)
# 실제 Guest OS의 커널 버전에 따라 과정이 달라질 수 있습니다.
# 예시: Ubuntu 22.04 (5.15.0-XX-generic) 커널에 대한 프로파일
sudo apt install -y dwarves linux-headers-$(uname -r) # Guest OS에서 실행
# Host OS에서 rekall 또는 Volatility 3를 이용하여 프로파일 생성하거나,
# libvmi github 릴리즈에서 제공하는 pre-built 프로파일을 다운로드합니다.
# 예시: vmlinux-5.15.0-xx-generic.zip을 다운로드하여 /usr/local/share/libvmi/rekall/ 에 압축 해제Step-by-Step Guide to Guest Monitoring using libvmi
Now, let's look at the steps to write a C language program that monitors the processes and memory of a Guest VM using the libvmi library. This example demonstrates the basic method of retrieving the process list of a specific Guest VM and reading a particular memory region for each process.
Step 1: libvmi Initialization and Guest VM Connection
First, you need to initialize the libvmi library and connect to a specific Guest VM defined in /etc/libvmi.conf. The vmi_init() function finds the VMI instance in the configuration file and returns a handle.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <libvmi/libvmi.h>
int main(int argc, char **argv) {
vmi_instance_t vmi = NULL;
const char *vm_name = "ubuntu2204_guest"; // /etc/libvmi.conf 에 정의된 VMI 이름
if (vmi_init(&vmi, VMI_AUTO | VMI_INIT_DOMAIN_NAME, vm_name) == VMI_FAILURE) {
fprintf(stderr, "Failed to init libvmi for VM: %s
", vm_name);
return 1;
}
fprintf(stdout, "Successfully initialized libvmi for VM: %s
", vm_name);
// 이후 모니터링 로직
vmi_destroy(vmi);
return 0;
}This code attempts to connect to a Guest VM named ubuntu2204_guest. If successful, you will obtain a VMI instance handle. If the connection fails, you should verify that the /etc/libvmi.conf file is correctly configured and that the Guest VM is running.
Step 2: Retrieve Guest VM Process List
Retrieving a list of all currently running processes within the Guest OS is a basic monitoring function. The vmi_get_proc_list() function can be used to obtain a linked list containing process information. Each vmi_process_t structure includes important information such as the process name, PID, and CR3 (Page Table Base Register) address.
// ... (1단계 코드 이후)
vmi_instance_t vmi = NULL;
// ... (vmi_init 성공)
vmi_process_t *proc_list = NULL;
if (vmi_get_proc_list(vmi, &proc_list) == VMI_FAILURE) {
fprintf(stderr, "Failed to get process list.
");
vmi_destroy(vmi);
return 1;
}
fprintf(stdout, "
--- Running Processes ---
");
for (vmi_process_t *proc = proc_list; proc != NULL; proc = proc->next) {
fprintf(stdout, "PID: %d, Name: %s, CR3: 0x%lx
", proc->pid, proc->name, proc->cr3);
}
vmi_destroy_proc_list(proc_list); // 메모리 해제
// ... (vmi_destroy)
Through this code, you can check the list of processes running inside the Guest OS and their important identification information. This can be used as foundational data to detect abnormal process execution.
Step 3: Access and Compare Specific Process Memory Regions
The core of process monitoring is analyzing the memory regions used by that process. This allows for the detection of malicious activities such as code injection and data tampering. The vmi_read_va() or vmi_read_mem() functions can be used to read the contents of memory at a specific virtual or physical address. Here, we will provide an example of reading a virtual address for a specific process.
// ... (2단계 코드 이후)
// 특정 프로세스 (예: 'systemd')의 메모리 읽기 예시
const char *target_proc_name = "systemd";
size_t read_size = 64; // 읽을 메모리 크기 (바이트)
unsigned char buffer[read_size];
for (vmi_process_t *proc = proc_list; proc != NULL; proc = proc->next) {
if (strcmp(proc->name, target_proc_name) == 0) {
fprintf(stdout, "
--- Monitoring %s (PID: %d) Memory ---
", proc->name, proc->pid);
// 예시: 프로세스의 코드 섹션 시작 부분으로 추정되는 가상 주소 (0x400000는 일반적인 ELF 시작 주소)
addr_t va_to_read = 0x400000;
if (VMI_SUCCESS == vmi_read_va(vmi, va_to_read, proc->dtb, buffer, read_size)) {
fprintf(stdout, "Memory content at VA 0x%lx (first %zu bytes):
", va_to_read, read_size);
for (size_t i = 0; i < read_size; ++i) {
fprintf(stdout, "%02x ", buffer[i]);
if ((i + 1) % 16 == 0) fprintf(stdout, "
");
}
fprintf(stdout, "
");
// 메모리 비교 로직 (간단한 예시: 특정 패턴과 비교)
unsigned char known_good_pattern[read_size]; // 실제로는 안전한 상태의 메모리 스냅샷
memset(known_good_pattern, 0x00, read_size); // 예시: 모두 0으로 초기화
if (memcmp(buffer, known_good_pattern, read_size) != 0) {
fprintf(stdout, "ALERT: Memory region for %s differs from known good state!
", proc->name);
} else {
fprintf(stdout, "Memory region for %s matches known good state.
", proc->name);
}
} else {
fprintf(stderr, "Failed to read memory at VA 0x%lx for process %s.
", va_to_read, proc->name);
}
break; // 첫 번째 발견된 프로세스에 대해 작업 후 종료
}
}
// ... (vmi_destroy_proc_list, vmi_destroy)
This step includes a brief logic to read the memory region of a specific process (systemd) and compare it against a predefined 'safe' memory pattern (known_good_pattern). In a real environment, this is implemented by creating a baseline memory snapshot and periodically comparing it with the current state to check for tampering. This allows for effective detection of injected malicious code, memory tampering attacks, and other threats.
Expected Output
Following the step-by-step guide above, you can expect output similar to the following. This indicates that libvmi successfully connected to the Guest VM, retrieved the process list, and read and compared the memory content of a specific process.
Successfully initialized libvmi for VM: ubuntu2204_guest
--- Running Processes ---
PID: 1, Name: systemd, CR3: 0x123456789abc
PID: 2, Name: kthreadd, CR3: 0x123456789abc
... (Guest VM의 모든 프로세스 목록)
PID: 1234, Name: bash, CR3: 0xdeadbeef1234
--- Monitoring systemd (PID: 1) Memory ---
Memory content at VA 0x400000 (first 64 bytes):
7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
02 00 3e 00 01 00 00 00 00 01 40 00 00 00 00 00
... (읽은 메모리 내용)
Memory region for systemd differs from known good state! # 또는 matches known good state.The process list output will show all currently running processes in the Guest OS with their PID, name, and CR3 values. The memory monitoring section will display a hex dump of memory data read from a specified virtual address of the designated process, along with the comparison result against a set pattern. If an 'ALERT' message appears, it signifies that the memory region has deviated from the baseline, which can be interpreted as a signal requiring further investigation.
Troubleshooting
Common issues and solutions that may arise during libvmi-based VMI environment setup and monitoring are as follows:
Error:
Failed to init libvmi: VMI_FAILUREorFailed to find domainCause: Occurs due to configuration errors in the
/etc/libvmi.conffile, a mismatch in the Guest VM name, or when the Guest VM is not running.Solution: Verify that the
andsettings in the/etc/libvmi.conffile precisely match. Check the exact name of the Guest VM using thevirsh list --allcommand, and ensure that the VM is in arunningstate.Error:
Failed to parse profileorFailed to find kernel symbolsCause: Occurs when the Guest OS kernel debug information (
vmlinuxor Rekall/Volatility3 profile) is missing, or the path is incorrectly specified. libvmi relies on this information to interpret the Guest OS's data structures.Solution: Verify that the
vmlinuxfile or profile corresponding to the exact kernel version of the Guest OS is placed in the correct location, such as/usr/local/share/libvmi/rekall/(for Rekall). Re-examine whether thepath within the/etc/libvmi.conffile is accurate.Error:
Permission denied for /dev/kvmCause: Occurs when the current user does not have permission to access the KVM device file.
Solution: Add the user to the
kvmgroup and restart the session. Use the commandsudo usermod -a -G kvm $(whoami)and then re-login or reboot the system.Error:
Failed to read memory at VA 0x...Cause: May occur if the specified virtual address is invalid, there are no permissions to access that memory region, or the Guest OS's memory management structure has changed.
Solution: Verify that the virtual address you are trying to read is within the valid memory space of the corresponding process. It is recommended to check the memory map of that process inside the Guest OS using a debugger (e.g., GDB) to identify the accurate address range. Also, re-confirm that the Guest OS kernel version matches the profile configured in
libvmi.conf.
Advanced Use Cases and Extension Patterns
Guest monitoring using libvmi allows for various advanced applications beyond simply querying process lists or reading memory. These extension patterns contribute to reducing overall TCO and maximizing ROI.
- Real-time Event-based Monitoring: Utilizing
vmi_eventsallows for real-time detection and response to specific events occurring within the Guest OS (e.g., process creation/termination, memory access changes, system call invocations). This is highly effective for detecting zero-day attacks or rootkits. - Kernel Module and Driver Analysis: By analyzing the Guest OS's kernel memory space, you can identify loaded kernel modules, drivers, and the presence of hooking. This enables diagnosis of kernel-level malware infections and performance of integrity verification.
- Automated Memory Forensics: You can build a system that periodically scans Guest memory based on known malicious patterns (e.g., YARA rules) to automatically detect malware traces. Upon detecting anomalies, it can generate memory dumps to secure evidence for detailed analysis.
- Baseline-based Anomaly Detection: Establish baselines for normal Guest OS process memory, registry, file system, etc., and periodically compare them with the current state to detect tampering. This method provides a high detection rate for unknown threats.
- Multi-Hypervisor Support and Scalability: libvmi supports various hypervisors, including KVM, Xen, and VMware, allowing flexible adaptation to existing infrastructure environments. Furthermore, Python bindings enable easy automation and extension with scripting languages, enhancing development efficiency.
These advanced utilization methods go beyond mere technical possibilities, playing a critical role in increasing the efficiency of security operations in real enterprise environments and minimizing business losses due to potential security breaches.
Security Considerations
VMI-based monitoring using libvmi offers strong security benefits, but several important security considerations must also be addressed.
- Hypervisor Protection: VMI tools operate at the hypervisor level, making the security of the hypervisor itself extremely critical. If the hypervisor is compromised, the security of all Guest VMs can be threatened. Therefore, access control to the hypervisor must be strengthened, the latest security patches applied, and unnecessary services disabled.
- Integrity of VMI Tools: The integrity of libvmi and the monitoring applications that use it must be ensured. If an attacker tampers with VMI tools, it could lead to false positives or enable detection evasion. Integrity must be secured through code signing, hash verification, and establishing a secure deployment pipeline.
- Data Privacy and Regulatory Compliance: VMI can see all data within the Guest OS, posing a risk of exposure of sensitive information (personal data, business secrets, etc.). The scope of monitoring must be clearly defined, access privileges minimized, and measures established for securely storing and processing collected data. Thorough review of compliance with relevant regulations such as GDPR and personal information protection laws is essential.
- Minimizing Performance Impact: While VMI does not install an agent on the Guest OS, resulting in low performance overhead, excessive monitoring operations can increase the hypervisor's CPU and memory usage. Therefore, monitoring frequency, scope, and data processing methods must be optimized to minimize the impact on Guest VM service quality.
- Isolation in Multi-tenancy Environments: When using VMI in cloud or multi-tenancy environments, robust isolation mechanisms must be implemented to prevent VMI for one tenant from accessing another tenant's VM. This is crucial for clearly distinguishing between the responsibilities of the cloud service provider and the user.
By thoroughly reviewing and implementing these security considerations, the powerful benefits of libvmi-based VMI solutions can be utilized safely and effectively.
Conclusion
Virtual Machine Introspection (VMI)-based Guest VM process and memory monitoring utilizing libvmi is a critical strategy for achieving the in-depth security visibility required in modern virtualized environments. The ability to transparently observe the internal state from outside the Guest OS, without an agent, overcomes the limitations of existing agent-based solutions and provides effective detection capabilities against advanced security threats such as rootkits, memory tampering, and stealthy code injection. From a decision-maker's perspective, this goes beyond mere technology adoption, strengthening an organization's overall cyber resilience, meeting increasingly complex compliance requirements, and leading to TCO reduction in the long term.
In real-world adoption cases, VMI technology is used in industries requiring high levels of security, such as finance, telecommunications, and the public sector, to ensure the integrity of critical systems and as a key means of collecting evidence for rapid analysis and response in the event of a security breach. libvmi provides a robust foundation that allows developers to easily access and utilize these powerful capabilities. For the next learning step, it is recommended to explore ways to integrate data collected via VMI with SIEM/SOAR systems to build automated threat detection and response workflows.
Such complex VMI data collection and analysis, and the threat detection and response processes built upon them, can be further streamlined and automated when integrated with the FRIIM CNAPP solution. FRIIM CNAPP provides comprehensive security visibility and control across cloud-native environments, integrating deep Guest OS insights gained from VMI technologies like libvmi to identify potential threats and strengthen proactive security policies. This can be an optimal choice for securing virtualized environments and a definitive answer to enhancing the overall security posture of IT infrastructure.