1. Introduction

The persistent and increasingly sophisticated nature of malware poses a significant threat across the digital landscape.

Understanding the behavior of malicious software is paramount for developing effective security strategies and mitigation techniques.

Traditional methods of malware analysis, often involving virtual machines or isolated sandbox environments, can present challenges in terms of resource intensity and the potential, albeit minimized, for escape or host compromise.

Secure container technologies have emerged as a promising alternative, offering enhanced isolation capabilities that can facilitate safer and more efficient malware analysis. These technologies, including gVisor, Kata Containers, and ZeroVM, employ distinct architectural approaches to create robust execution environments for potentially harmful code. This report will delve into the capabilities of these secure container technologies, specifically in the context of malware analysis and the monitoring of system calls. The primary objectives are to compare their suitability for this use case, recommend the most appropriate option based on the need for comprehensive syscall monitoring and robust security, and provide practical guidance on setting up a secure analysis environment using Dockerfiles and essential security measures. This includes preventing privilege escalation, network access, and volume mounts, while also exploring methods to identify the endpoints and folders the malware attempts to interact with during its execution.

2. Deep Dive into Secure Container Technologies

2.1. gVisor

gVisor is presented as a platform designed to enhance container security by providing an open-source, Linux-compatible sandbox that integrates seamlessly with existing container tooling. Its architecture centers around the Sentry, a user-space kernel that intercepts and manages system calls made by the containerized application, and the Gofer, a separate user-space process responsible for handling interactions with the host filesystem.

This design aims to isolate the host operating system from the container, enabling the secure execution of untrusted code and adding a critical layer of defense against container escapes and privilege escalation vulnerabilities. The Sentry is implemented in Go, a memory-safe language, which contributes to the overall security posture. This layered approach, where the Sentry intercepts application system calls and gVisor itself is sandboxed from the host using Linux’s isolation features, significantly complicates any attempts by malware to compromise the underlying system. Furthermore, gVisor explicitly enumerates and controls the host system’s interface exposed to the Sentry, restricting the Sentry from performing many sensitive host operations, such as opening new files or creating new sockets. This significantly reduces the potential attack surface even if the Sentry were to be compromised.

When a containerized application within gVisor makes a system call, the Sentry intercepts it before it reaches the host kernel. The Sentry then determines whether to permit, deny, or emulate the call within its user space environment.

This filtering and emulation process is vital in preventing malicious or unsafe system calls from directly interacting with the host kernel, thereby establishing a secure sandbox for the container. A fundamental design principle of gVisor is that no system call is passed directly to the host; each supported call has an independent implementation within the Sentry.

This independent implementation aims to prevent identical vulnerabilities present in the host kernel from being exploitable through the gVisor sandbox, creating a distinct security boundary. While gVisor offers robust kernel isolation and a defense-in-depth architecture that makes host escape challenging, along with runtime monitoring capabilities that can integrate with threat detection tools, it does have limitations for malware analysis.

Notably, it can introduce performance overhead, especially for input/output (I/O) intensive workloads due to the Gofer process and system call emulation. Additionally, gVisor does not implement the entire Linux system call surface, which might affect the execution and analysis of some malware samples. The performance overhead associated with gVisor, particularly in file I/O and system call latency, could potentially alter the behavior and analysis of malware that heavily relies on these operations. Researchers must be aware of this potential skewing of observed behavior when using gVisor for malware analysis.

2.2. Kata Containers

Kata Containers adopts a different strategy by running each container within a lightweight Virtual Machine (VM).

This is achieved through hardware virtualization technologies such as Intel VT-x or AMD SVM, establishing a strong isolation boundary at the hypervisor level. Each Kata Container effectively boots its own minimal guest operating system kernel, separate from the host kernel, providing enhanced workload isolation and security.

The Kata runtime acts as the intermediary between the container ecosystem (e.g., Docker, Kubernetes) and the underlying hypervisor, managing the lifecycle of these lightweight VMs. The use of a dedicated guest kernel for each container in Kata Containers offers a significant security advantage against kernel-level exploits that might target the host kernel in traditional container environments. This drastically reduces the attack surface from the perspective of the containerized malware. Furthermore, Kata Containers’ adherence to industry standards like the Open Container Initiative (OCI) container format and the Kubernetes Container Runtime Interface (CRI) ensures seamless integration with existing container management tools and workflows. This makes it easier to adopt for malware analysis without requiring significant infrastructure modifications. By leveraging hardware virtualization, Kata Containers provides strong isolation of network, I/O, and memory for each container. This ensures that even if malware manages to gain elevated privileges within its container, it remains confined within the boundaries of the lightweight VM and cannot directly access or interfere with the host system or other containers running on the same host. The hardware-enforced isolation in Kata Containers offers a more robust security boundary compared to the software-based isolation mechanisms found in traditional containers and even gVisor. This makes it a particularly appealing option for analyzing high-risk or sophisticated malware. Kata Containers’ strengths for malware analysis include its robust workload isolation, enhanced security due to virtualization, and broad compatibility with container ecosystems and tools. It allows for the execution of standard container images with minimal modifications. Limitations include a potentially higher resource overhead compared to standard containers and gVisor, as each container necessitates its own VM and kernel. There might also be some performance overhead for network-intensive workloads due to the virtualization layer. The slightly higher resource overhead of Kata Containers might impact the density of analysis environments that can be run on a single host. Researchers need to consider the available resources when planning their malware analysis infrastructure.

2.3. ZeroVM

ZeroVM employs a distinct architecture based on Software Fault Isolation (SFI) technology derived from the Google Native Client (NaCl) project. It establishes a secure and isolated execution environment, termed a “cell,” capable of running a single thread or application. Unlike conventional virtualization approaches, ZeroVM isolates individual processes without providing a complete operating system or kernel. Its primary emphasis is on secure computation and minimizing data movement by enabling data-local computing. Security in ZeroVM is enforced through static binary validation and a highly restricted system call API. ZeroVM’s reliance on static binary validation, which occurs before execution, allows for the detection and prevention of code containing unsafe instructions without incurring runtime performance overhead for continuous monitoring. However, this also implies that the malware must be in a format that can be validated by the ZeroVM validator. The extremely limited system call API in ZeroVM, comprising only six calls (pread, pwrite, jail, unjail, fork, exit), drastically reduces the attack surface available to malware. However, this also means that any malware relying on other, unsupported system calls will likely not function correctly within the ZeroVM environment. The stark contrast between ZeroVM’s six system calls and the hundreds available in a standard Linux environment highlights its extreme focus on security through restriction. While this highly restricted API provides strong security, it significantly limits the scope of malware that can be effectively analyzed. Many common malware behaviors rely on a much broader set of system calls for file system operations, networking, and process manipulation. ZeroVM’s strengths for malware analysis lie in its very strong isolation due to SFI and the extremely limited system call API, its lightweight nature with fast startup times, and its embeddability. However, it has significant limitations for general malware analysis, including the highly restrictive system call API, the requirement for applications to be cross-compiled to NaCl using a specific toolchain, and limited language support (primarily C/C++, with some support for older versions of Python and Lua). Furthermore, the project appears to have significantly reduced activity in recent years, raising concerns about ongoing support and security updates. The requirement for cross-compilation to NaCl using a specific toolchain makes ZeroVM impractical for analyzing pre-compiled malware binaries obtained in the wild. Researchers would need the source code of the malware and the ability to compile it for the ZeroVM environment, which is rarely the case. The apparent lack of recent development and community activity around ZeroVM suggests that it might not be a reliable or actively supported platform for long-term malware analysis efforts. Security vulnerabilities discovered in the future might not be addressed promptly.

3. Comparative Analysis for Malware Testing

3.1. Evaluation of Isolation Capabilities

All three technologies provide enhanced isolation compared to standard containers. gVisor achieves strong isolation by running a user-space kernel that intercepts and emulates system calls, creating a significant barrier against host kernel exploitation. Kata Containers offers the most robust isolation by running each container within a lightweight VM with its own dedicated kernel, leveraging hardware virtualization for a strong security boundary. ZeroVM provides strong isolation through Software Fault Isolation and a highly restrictive system call API, effectively limiting the actions malware can undertake. Kata Containers’ utilization of hardware virtualization generally offers the strongest and most comprehensive isolation, making it the most resilient against potential escape attempts by sophisticated malware. Hardware-level separation provides a more fundamental security boundary than software-based techniques alone, and the dedicated kernel in each Kata Container further minimizes the risk of host kernel vulnerabilities being exploited.

3.2. Assessment of Performance Impact

The performance characteristics of each technology must be considered in relation to the type of malware being analyzed. gVisor can introduce performance overhead, particularly for I/O-intensive and syscall-heavy workloads, which might affect the real-time behavior of some malware. Kata Containers has a higher initial resource footprint due to the VMs, but once the VM is running, performance for many operations can be near-native, although network I/O might experience some overhead. ZeroVM is designed to be very lightweight with fast startup times, but its limited syscall API might prevent accurate performance analysis of malware relying on unsupported calls. For malware that is sensitive to timing or relies heavily on I/O, gVisor’s overhead might be a concern. Kata Containers offers a good balance of performance and strong isolation for a wider range of malware. ZeroVM’s limitations make it less suitable for comprehensive performance analysis. The goal is to observe the malware’s behavior as accurately as possible, and significant performance differences introduced by the isolation technology could skew the analysis results.

3.3. Ease of Monitoring Syscalls and System Activity

Kata Containers and gVisor provide relatively good options for monitoring system calls. gVisor integrates well with runtime security tools like Falco for monitoring application behavior and system calls within the sandbox. Standard Linux tools might also be usable, although the output might reflect the Sentry’s syscall handling. Kata Containers allows the use of standard Linux monitoring tools like trace and sysdig within the guest VM to observe the malware’s system call activity. ZeroVM’s highly limited syscall API simplifies monitoring to the few available calls, but traditional Linux syscall monitoring tools are not directly applicable due to its SFI nature. Kata Containers offers the most straightforward integration with standard Linux syscall monitoring tools like trace and sysdig by allowing their direct use within the isolated guest VM. This provides researchers with familiar tools for in-depth analysis. The ability to use well-established and understood tools simplifies the malware analysis process and reduces the learning curve associated with the isolation technology.

3.4. Integration with Syscall Monitoring Tools

gVisor should be compatible with trace and potentially sysdig as it aims for Linux API compatibility, though the output might reflect the Sentry’s syscall handling. Standard Linux tools like trace and sysdig can be readily used within the guest VM of Kata Containers to monitor the malware’s syscall activity. Due to its non-standard environment and limited syscalls, trace and sysdig as used on typical Linux systems will not function as expected within ZeroVM. Kata Containers offers the most direct and seamless integration with standard Linux syscall monitoring tools like trace and sysdig, enabling their use within the isolated guest VM. This provides researchers with familiar and powerful tools for detailed malware analysis.

Table 1: Comparison of Secure Container Technologies for Malware Analysis

| Feature | gVisor | Kata Containers | ZeroVM |
|—|—|—|—|
| Isolation Strength | Strong | Very Strong | Strong |
| Performance | Potential Overhead | Moderate Overhead | Very Low Overhead |
| Syscall Monitoring | Good | Excellent | Limited |
| Resource Usage | Low | Moderate to High | Very Low |
| Compatibility | High | High | Low |
| Community Support | Active | Active | Less Active |
| Suitability for Malware Analysis | Good | Excellent | Poor |

4. Selecting the Optimal Container Technology for Malware Analysis

Based on the comparative analysis, Kata Containers emerges as the most suitable technology for safely testing malware and monitoring all system calls. Its robust isolation provided by lightweight virtual machines, coupled with its compatibility with standard container images and the ability to use familiar Linux tools like trace and sysdig within the guest VM, offers the best balance of security, flexibility, and analytical power. Kata Containers’ ability to provide “the speed of containers, the security of VMs” makes it an ideal choice for malware analysis, offering a robust and isolated environment without sacrificing the ability to perform detailed inspection using standard Linux tools. The use of a dedicated guest kernel per container provides a significant security advantage, particularly for malware that might attempt to exploit kernel-level vulnerabilities. While gVisor provides good isolation and integrates with cloud-native security tools, its potential performance overhead and the fact that it doesn’t implement the full Linux syscall surface might hinder the analysis of certain types of malware. ZeroVM’s extreme restrictions and lack of recent activity make it impractical for general malware analysis. For malware analysis requiring comprehensive syscall monitoring with tools like trace and sysdig, Kata Containers provides a more directly compatible and robust environment.

graph LR
    subgraph HostOS
        HostKernel((Kernel))
        Hardware[Hardware]
    end

    subgraph KataContainers
        direction LR
        subgraph KataVM[Light VM]
            KataKernel((Kernel))
            KataContainer[Container]
        end
        Hypervisor[Hypervisor] -- uses --> Hardware
        HostKernel -- manages --> Hypervisor
        Hypervisor -- executes --> KataVM
        KataVM -- contains --> KataContainer
    end

    subgraph ZeroVM
        direction LR
        ZeroContainer[Container]
        ZeroLib[Isolated libraries]
        HostKernel -- executes --> ZeroContainer
        ZeroContainer -- uses --> ZeroLib
        ZeroLib -- interacts --> HostKernel
    end

    subgraph gVisor
        direction LR
        gVisorSentry[Kernel User-Space Sentry]
        gVisorContainer[Container]
        HostKernel -- executes --> gVisorSentry
        gVisorSentry -- simulates syscall --> HostKernel
        gVisorSentry -- contains --> gVisorContainer
    end

    style HostKernel fill:#f9f,stroke:#333,stroke-width:2px
    style Hardware fill:#ccf,stroke:#333,stroke-width:2px
    style Hypervisor fill:#aaf,stroke:#333,stroke-width:2px
    style KataKernel fill:#9cf,stroke:#333,stroke-width:2px
    style KataContainers fill:#cff,stroke:#333,stroke-width:2px
    style KataVM fill:#eee,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style ZeroContainer fill:#efe,stroke:#333,stroke-width:2px
    style ZeroLib fill:#aee,stroke:#333,stroke-width:2px
    style gVisorSentry fill:#faa,stroke:#333,stroke-width:2px
    style gVisorContainer fill:#fca,stroke:#333,stroke-width:2px

    HostOS -- contains --> KataContainers
    HostOS -- contains --> ZeroVM
    HostOS -- contains --> gVisor

5. Building a Secure Malware Analysis Environment

5.1. Host System Security

Ensuring the host operating system’s security is the foundational step in creating a safe malware analysis environment. The host should be hardened and kept up to date with the latest security patches to minimize vulnerabilities that malware could potentially exploit to escape the container. Minimizing the software installed on the host reduces the attack surface, limiting the number of potential entry points for malicious actors. Implementing strong access controls is crucial, including the use of strong, unique passwords and multi-factor authentication to prevent unauthorized access to the host system. Enabling a host-based firewall to restrict network access to only essential services further enhances security by limiting potential communication channels. While running the container runtime in rootless mode can add an extra layer of security by limiting the impact of a potential container escape, its compatibility with Kata Containers, which relies on virtualization, might need careful consideration. Hardening the host system provides the initial and critical layer of defense for the malware analysis environment. Even with robust container isolation, a vulnerable host could still be compromised, potentially allowing an attacker to interact with or observe the analysis environment, regardless of the container’s security.

5.2. Kata Containers Configuration

To configure Kata Containers for secure malware analysis, begin by installing the runtime following the official installation guide for your operating system. Utilizing a package manager-based installation is recommended for ease of management and updates. Consider configuring Kata Containers to use a lightweight and security-focused hypervisor like Firecracker, if your environment supports it. Firecracker is specifically designed for microVMs and prioritizes security and low overhead, making it well-suited for isolated execution environments. Next, review the configuration.toml file, typically located in /etc/kata-containers/, and adjust security-related settings according to your specific needs. Pay close attention to options concerning network configuration, storage drivers, and hypervisor parameters. For malware analysis, it is advisable to explicitly disable default network interfaces within the Kata VM if you intend to manage networking at the Docker or containerd level to ensure complete isolation. The configuration.toml file also offers options for enabling debugging, which can be valuable during the initial setup and troubleshooting phases of your analysis environment. Carefully configuring the Kata Containers runtime, particularly the selection of the hypervisor and the settings within configuration.toml, is essential for optimizing both the security and performance of the malware analysis environment. The default settings might not be ideally suited for a highly secure malware analysis setup, so reviewing and adjusting these settings allows for fine-tuning the environment to meet specific security requirements, such as minimizing the hypervisor’s attack surface or precisely controlling resource allocation.

6. Dockerfile Examples for Malware Analysis

The following Dockerfile examples provide a foundation for building secure malware analysis containers using Kata Containers. These examples emphasize using minimal base images, installing necessary monitoring tools, and running the malware as a non-privileged user.

6.1. Alpine-based Dockerfile

```Dockerfile
FROM alpine:latest

## Install necessary tools for analysis
RUN apk add --no-cache strace sysdig

# Add a non-root user for running the malware
RUN adduser -D malware_user

# Copy the malware binary into the container
COPY malware /home/malware_user/malware

# Set file permissions (make executable)
RUN chmod +x /home/malware_user/malware

# Switch to the non-root user
USER malware_user

# Set the entry point to run the malware with strace
ENTRYPOINT ["strace", "-f", "/home/malware_user/malware"]
```

This Dockerfile uses the minimal Alpine Linux image. It installs strace and sysdig for system call monitoring. A non-root user malware_user is created to run the malware, adhering to the principle of least privilege. The malware binary is copied into the container, made executable, and the container’s entry point is set to run the malware under strace for immediate syscall capture.

6.2. UBI9-mini-based Dockerfile

```Dockerfile
FROM registry.access.redhat.com/ubi9-minimal:latest

# Install necessary tools for analysis
RUN microdnf install -y strace sysdig

# Add a non-root user for running the malware
RUN useradd -m malware_user

# Copy the malware binary into the container
COPY malware /home/malware_user/malware

# Set file permissions (make executable)
RUN chmod +x /home/malware_user/malware

# Switch to the non-root user
USER malware_user

# Set the entry point to run the malware with sysdig
ENTRYPOINT ["sysdig", "syscall=*", "proc.name=malware"]
```

This example utilizes the Red Hat Universal Base Image 9 Minimal (UBI9-mini). It installs strace and sysdig using microdnf. Similar to the Alpine example, a non-root user malware_user is created, the malware is copied and made executable, and the entry point is configured to run the malware with sysdig to capture all syscalls made by the malware process.

6.3. Sysdig/Sysdig-based Dockerfile

```Dockerfile
FROM sysdig/sysdig:latest

# Add a non-root user for running the malware
RUN adduser -D malware_user

# Copy the malware binary into the container
COPY malware /home/malware_user/malware

# Set file permissions (make executable)
RUN chmod +x /home/malware_user/malware

# Switch to the non-root user
USER malware_user

# Set the entry point to run the malware
ENTRYPOINT ["/home/malware_user/malware"]
```

This Dockerfile leverages the sysdig/sysdig base image, which already includes the sysdig tool. It adds a non-root user malware_user, copies the malware binary, makes it executable, and sets the entry point to run the malware directly. You would then run this container with the Kata runtime and use sysdig on the host to monitor the container’s syscalls using filters like container.name=.
These Dockerfile examples provide a starting point for creating secure malware analysis containers. They emphasize the principles of using minimal base images, installing necessary monitoring tools, and running the malware as a non-privileged user. The Sysdig-based example offers a convenient way to integrate syscall monitoring directly into the container execution environment or to monitor from the host.

7. Implementing Security Measures within the Container

7.1. Preventing Privilege Escalation

To prevent privilege escalation within the malware analysis container, several key security measures should be implemented. Firstly, it is crucial to run the malware as a non-root user. This limits the potential damage the malware can inflict, as many system-level operations require root privileges. The Dockerfile examples provided in the previous section all incorporate this best practice by creating a dedicated non-root user for executing the malware. Secondly, unnecessary Linux capabilities should be dropped. Linux capabilities provide fine-grained control over privileged operations, and by removing those not strictly required by the malware (or the analysis tools), the attack surface is significantly reduced. This can be achieved using the –cap-drop flag when running the container. Finally, utilizing seccomp profiles to restrict the system calls the malware can make adds another critical layer of security. Seccomp (secure computing mode) allows filtering of system calls, permitting only those necessary for the application’s function. Kata Containers allows enabling seccomp within the guest VM by configuring the configuration.toml file. This ensures that the seccomp profile defined for the container is enforced within the isolated VM environment, further limiting the malware’s potential for malicious activity even if it were to gain some level of privilege. This defense-in-depth approach ensures that multiple security mechanisms are in place to prevent privilege escalation. Seccomp complements running as a non-root user and dropping capabilities by providing fine-grained control over system call usage.

7.2. Disabling Networking

Disabling networking for the malware analysis container is essential to prevent the malware from communicating externally, which could involve command-and-control activities, downloading further malicious payloads, or attempting to spread the infection. This can be achieved by configuring the container runtime to isolate network interfaces. When using Docker with the Kata runtime, networking can be explicitly disabled by using the –network none flag when running the container. This ensures that the container has no network interfaces configured within its network namespace. Kata Containers inherently provides a level of network isolation as it does not support the host network type directly. However, explicitly disabling networking at the Docker level provides an additional layer of assurance. To verify that networking is indeed disabled, tools like ip addr or ifconfig can be run within the container to confirm the absence of network interfaces beyond the loopback interface. The inherent network isolation provided by Kata Containers, combined with the explicit disabling of networking at the Docker level, ensures that the malware being analyzed cannot communicate externally, preventing command-and-control activities or the spread of infection. Isolating the network is crucial for safe malware analysis. By leveraging Kata Containers’ default network isolation and explicitly disabling it at the container runtime level, a highly controlled environment is created.

7.3. Restricting Mounted Volumes

Restricting mounted volumes is crucial to prevent the malware from accessing the host filesystem, which could lead to data exfiltration, modification of host files, or further compromise of the analysis environment. When running the malware analysis container with Kata Containers, it is essential to avoid mounting any volumes from the host system. Kata Containers by default uses a paravirtualized filesystem sharing mechanism (virtio-9p, with a move towards virtio-fs) to share container images from the host with the guest VM. However, to prevent any host filesystem access beyond the initial image, ensure that no volumes are explicitly mounted using the -v flag in Docker or similar mechanisms in other container management tools when running the container. If the malware analysis requires any form of persistent storage or the ability to read or write files, consider using temporary filesystems within the container itself. These filesystems exist only for the lifespan of the container and are isolated from the host. While Kata Containers uses filesystem sharing for images, explicitly avoiding any volume mounts for the running container is crucial to prevent the malware from interacting with the host’s persistent storage. Even though the container image itself is shared, the goal is to prevent the malware from reading or writing to any other part of the host filesystem during its execution. This is achieved by not defining any volume mounts for the container instance.

8. Monitoring Syscalls and Identifying Accessed Resources

8.1. Using trace

The trace utility is a powerful tool for capturing the system calls made by a running process. To use trace within a Kata Container, it can be included in the container image (as shown in the Alpine Dockerfile example).
When the container is run, the malware can be executed under trace using the entry point: ENTRYPOINT [“trace”, “-f”, “/home/malware_user/malware”]. The -f flag instructs trace to follow child processes, which is crucial as malware often spawns multiple processes. The output from trace will list each system call made by the malware, along with its arguments and return values. Analyzing this output can reveal the malware’s attempts to interact with the file system (e.g., open, read, write, unlink), network (e.g., socket, connect, sendto, recvfrom), and other system resources.

8.2. Using sysdig

sysdig is another excellent tool for monitoring system activity in Linux containers. It provides a more structured and filterable output compared to trace. sysdig can be installed within the container (as shown in the UBI9-mini Dockerfile example) or run on the host to monitor the Kata Container. To monitor all syscalls made by a specific process named malware within the container, the following command can be used as the entry point in the Dockerfile: ENTRYPOINT [“sysdig”, “syscall=*”, “proc.name=malware”].
Alternatively, if running sysdig on the host, you can filter by the container name: sysdig container.name= syscall=*. sysdig allows for powerful filtering based on various criteria, including process name, syscall type, arguments, and more. This makes it easier to focus on specific activities of interest. Sysdig offers powerful filtering capabilities based on process names, event types, and file/network descriptors. These filters can be used to specifically look for syscalls related to network connections (even if they fail due to networking being disabled) and file/directory access attempts. Sysdig Inspect can then be used for more in-depth post-capture analysis.

8.3. Analyzing Syscall Output 

Analyzing the potentially large output from trace or sysdig requires careful examination. Look for syscalls related to file operations (e.g., open, stat, mkdir, chmod), which can indicate the folders the malware is trying to reach or modify. Network-related syscalls (e.g., socket, connect, bind, sendto, recvfrom) can reveal the endpoints the malware is attempting to connect to, even if the network is disabled and the connections fail. Pay attention to the arguments of these syscalls, as they often contain the specific file paths or IP addresses and port numbers being targeted. Tools like grep can be invaluable for filtering the output to focus on specific syscalls or patterns of interest.8.4. Identifying Accessed Endpoints and Folders

To specifically identify the endpoints and folders the process in the container is trying to reach, focus on the network-related syscalls and file operation syscalls in the trace or sysdig output.
For network activity, the `connect` syscall is particularly informative as its arguments typically include the destination IP address and port number. Even if the connection fails due to networking being disabled, the attempt will still be logged.
Similarly, for folder access, the `open, stat, mkdir`, and related syscalls will contain the file paths the malware is interacting with. By filtering the syscall output for these specific calls and examining their arguments, a clear picture of the malware’s intended targets can be obtained. Sysdig’s rich filtering language allows for targeted monitoring of the malware’s behavior, even in the absence of successful network connections. Researchers can focus on the syscalls that indicate an attempt to reach specific endpoints or access particular files and folders. Even if network traffic is blocked, the malware will still likely make syscalls attempting to connect to specific IP addresses or domain names. Sysdig can capture these attempts, providing valuable intelligence about the malware’s targets. Similarly, file access attempts, even to non-existent paths, can reveal the malware’s intended actions.

9. Conclusion and Recommendations

In conclusion, secure container technologies offer a significant advancement in the ability to safely analyze malware. Among the options explored, Kata Containers stands out as the most suitable choice for this task due to its robust isolation provided by lightweight virtual machines, its compatibility with standard container images, and its seamless integration with familiar Linux system call monitoring tools like trace and sysdig. While gVisor offers a strong security model, its potential performance overhead and incomplete syscall coverage might limit its effectiveness for certain types of malware analysis.

ZeroVM, with its extreme restrictions and limited ecosystem, is not well-suited for general-purpose malware analysis.

For safely testing malware in secure containers, the following best practices should be adhered to:

• Harden the host system: Ensure the host OS is up-to-date, has minimal software installed, and is protected by strong access controls and a firewall.
• Use Kata Containers with a lightweight hypervisor: Configure Kata Containers to utilize a security-focused hypervisor like Firecracker for enhanced isolation.
• Build minimal container images: Use minimal base images and install only the necessary tools for analysis.
• Run as a non-root user: Always execute the malware under a non-privileged user account within the container.
• Drop unnecessary capabilities: Remove any Linux capabilities that are not strictly required for the malware or analysis tools to function.
• Utilize seccomp profiles: Implement seccomp profiles to restrict the system calls the malware can make.
• Disable networking: Isolate the container from any network connectivity to prevent external communication.
• Restrict volume mounts: Avoid mounting any host volumes into the container to prevent access to the host filesystem.
• Monitor syscalls: Employ tools like trace or sysdig to capture and analyze the system calls made by the malware.
• Analyze syscall output: Carefully examine the syscall output to identify file and network activity, revealing the endpoints and folders the malware attempts to reach.

For further research and security enhancements, consider exploring the integration of additional sandboxing tools within the Kata Container’s guest VM for an extra layer of analysis and control. Investigating the use of memory analysis tools within the isolated VM could provide deeper insights into the malware’s behavior.

Developing automated scripts or tools to parse and analyze the potentially large output from trace and sysdig would greatly enhance the efficiency of the analysis process.
Staying updated on the latest security best practices and configuration options for Kata Containers and the chosen hypervisor is also crucial for maintaining a secure and effective malware analysis environment.

Finally, contributing to open-source malware analysis projects or sharing findings with the security community can help to strengthen collective defenses against evolving threats.