Detecting Cryptojacking Containers Using eBPF-Based Security Runtime and Machine Learning

Abstract

As the use of containers has become mainstream in the cloud environment, various security threats targeting containers have also been increasing. Among them, a notable malicious activity is a cryptojacking attack that steals resources without the consent of an instance owner to mine cryptocurrency. However, detecting such anomalies in a containerized environment is more complex because containers share the host kernel, making it challenging to pinpoint resource usage and anomalies at the container granularity without introducing significant overhead. To this end, this study proposes a runtime detection framework for identifying malicious mining behaviors in the cloud-native environment. By leveraging Tetragon, a runtime security tool based on the extended Berkeley Packet Filter (eBPF), we capture system call traces and flow-level information of cryptojacking containers to extract rich feature representations for training and evaluating various machine learning models. As a result of the experiment, our framework delivers up to 99.75% classification accuracy with moderate runtime monitoring overhead.

1. Introduction

A recent innovation in cloud-native technology with the use of containers enables automated, flexible deployment and scalable management of microservices. Container technologies offer a lightweight virtualization by leveraging the host operating system (OS) and minimizing deployment overhead, making them an optimal solution for latency-sensitive cloud applications to ensure quality of service (QoS). With the emergence of representative container-based technologies, i.e., Kubernetes and Docker, enterprises are migrating their services from traditional environments based on virtual machines (VMs) to containerized environments. Kubernetes is a system that provides automation for deploying, scaling, and managing Docker containerized applications. Accordingly, major cloud service providers (CSPs) are offering container-based Kubernetes platforms, such as the Amazon Elastic Kubernetes Service (EKS) and Azure Kubernetes Service (AKS).

However, the widespread use of containers also incurs a rise in security threats targeting these environments. In particular, cryptojacking has become one of the most severe threats, as it stealthily hijacks victims’ computing resources of consolidated servers for cryptocurrency mining. According to Google Cloud’s research, 86% of attacks in container environments stem from cryptojacking activities [1]. In addition, the 2022 Cloud Native Security and Usage Report by Sysdig reveals that the most frequently discovered malicious container images are cryptojacking images, occurring at more than twice the rate of the second-highest malicious image [2]. Such unauthorized activities not only increase resource usage costs for the instance owner but also degrade performance by abusing container resources and interfering with the resource usage of benign containers.

In contrast to conventional host-based cryptojacking malware, attackers can easily distribute malicious containers through container image registries (e.g., Docker Hub) in the cloud-native environment. Basically, cryptojacking attacks involve embedding mining scripts into websites or distributing binary malware to hijack the computing power of various devices, such as servers and Internet of Things (IoT) devices [3]. However, due to the nature of the container ecosystem, anyone can upload and download images to public repositories. In other words, attackers can control numerous cryptojacking containers by exploiting widely deployed container images, leveraging the scale and flexibility of cloud-native environments to conduct extensive cryptojacking operations. Worse yet, since containers share the host kernel, attacks originating from one container can adversely affect neighboring containers, potentially compromising the entire host system and other co-located services [4,5].

Previous research primarily focused on detecting cryptojacking activities in the form of browser-based or binaries [6,7,8,9,10]. For example, it utilizes performance-relevant metrics, such as processor time and interrupts, to achieve the signature of browser-based cryptojacking attacks [9,10]. While these metrics can detect abnormal resource usage patterns indicative of malicious activities like cryptojacking, they can result in false positives for legitimate CPU- and memory-intensive workloads. In addition, performance monitoring in container environments is more complex than in native environments, posing challenges in utilizing these metrics effectively. Container processes are isolated and virtualized with namespaces and control groups (cgroups). Still, because containers share the host kernel, it is difficult to accurately separate and measure multiplexed metrics like interrupts and memory pages for each container. This complicates the monitoring process, making it challenging to pinpoint resource usage and anomalies at the granularity needed to detect cryptojacking activities within individual containers effectively.

To address these challenges, recent studies utilize machine learning (ML) models by constructing the feature sets derived from the container-level system information [11,12]. However, these studies rely on datasets obtained from legitimate mining workloads (e.g., Bitcoin and Ethereum miners) and blockchain network management workloads to mimic cryptojacking containers, labeling them as mining bots. Furthermore, the continuous extraction of system-level information in a Kubernetes environment for training or inference data acquisition may lead to substantial runtime overhead, particularly as the number of instantiated containers increases.

To this end, we propose a cryptojacking container detection framework that extracts system call sequences from benign and cryptojacking containers. To monitor and capture the call trace along with flow-level information, we leverage Tetragon [13], an eBPF-based cloud-native security solution, enabling security event tracking for containers deployed in the Kubernetes cluster. extended Berkeley Packet Filter (eBPF) is a technology that allows user-defined programs, such as tracking network activities and process executions, to run in the kernel at runtime without modifying the kernel code while minimizing performance overhead as it runs in kernel space [14]. By utilizing it, our framework integrates container behavior monitoring with ML-based cryptojacking detection, enabling runtime security analysis in Kubernetes environments. To evaluate the versatility and efficiency of the proposed framework, we empirically explored the optimized n-gram system call sequences extracted from two cryptojacking containers and four benign containers and utilized them for model training. The experimental results demonstrate that the proposed framework ensures scalability and runtime monitoring in cloud-native environments while achieving a classification accuracy of 99.75% with moderate runtime overhead.

The rest of this paper is organized as follows. Section 2 introduces anomaly detection in containerized environments and describes Tetragon, an eBPF-based tool. Section 3 discusses the structure and operational mechanism of the proposed cryptojacking container attack detection framework. Section 4 presents the results of the detection performance evaluation and performance overhead analysis of the proposed framework. In Section 5, an analysis of cryptojacking workloads is provided from the perspectives of system calls and network traffic. Finally, Section 6 concludes the paper by summarizing the findings and suggesting directions for future research.

2. Background and Literature Review

2.1. Container Anomaly Detection

Recent containerized workloads run on multi-tenant cloud environments, sharing the host kernel and underlying computational resources with other containers. Due to the loose isolation guarantee compared to VMs, a malicious container might inhibit the execution of neighboring containers. To mitigate threats, CSPs monitor the behavior of containers to detect anomalies and protect benign containers and the host kernel. However, conventional security solutions (e.g., intrusion detection systems) only provide limited functionalities to detect anomalies in cloud-native environments. Specifically, they have limitations in meticulously tracking the internal activities of each container in an environment where multiple services coexist on a single host, thereby necessitating anomaly detection measures suitable for container environments.

To address this, researchers have proposed methodologies for detecting the malicious behavior of containers by analyzing system information (e.g., resource utilization) and system call traces [11,12,15,16]. One conventional approach involves acquiring the signature of workloads by extracting system call sequences, as these are essential for accessing host resources such as the file system, memory, and network or for utilizing functionalities that require OS privileges. Similarly, container applications can be characterized by monitoring these traces. They are run as a single process from the host kernel’s perspective, so it is possible to perform anomaly detection without direct access to resources within the container.

A prior study used system calls acquired by executing various types of cryptocurrency docker images, such as Bitcoin, Ethereum, and Dash, as training data [12]. However, because Bitcoin and Ethereum require special hardware devices (e.g., graphics processing unit (GPU) and application-specific integrated circuit (ASIC)), mining on containers with lightweight resources is not appropriate. In addition, the docker image used contains images used to manage transactions by participating in the network rather than performing cryptocurrency mining, which is not suitable for the purpose of an attacker who aims to steal resources and mine. In contrast, this study targets malicious cryptojacking that performs mining operations. The cryptocurrency we selected is Monero (XMR), which ensures strong anonymity and can be mined using general computing resources without special equipment such as GPU or ASIC. Therefore, mining is possible with fewer resource requirements and recently, Monero mining attacks in container environments have occurred [17].

2.2. Tetragon

Tetragon [13] is a part of the Cloud Native Computing Foundation (CNCF) open-source project, providing eBPF-based observability and enhanced runtime security for a containerized environment. It detects system activities, such as the process lifecycle, file access, and host system changes, with minimal runtime overhead. These metrics are essential for security monitoring, and previous studies [18,19] have demonstrated effective anomaly detection in Kubernetes and containerized environments by using runtime security monitoring tools (e.g., Falco and Sysdig) to monitor anomaly events such as program execution and file updates. Tetragon is also a readily deployable and compatible tool with Kubernetes, Docker Engine, and general Linux systems. In particular, since it is aware of Kubernetes concepts, it can apply security by recognizing pods, namespaces, and labels. Therefore, using the Tracing Policy, it is easy to implement and manage security rules for the entire Kubernetes cluster, enabling policy-based control. Figure 1 shows the architecture of Tetragon deployed in Kubernetes. Basically, Tetragon runs an agent pod on each worker node in the form of DaemonSet, and the Operator monitors the tracing policy. This allows for consistent security across all nodes in a Kubernetes cluster. Tetragon manages eBPF-based tracing through the tracing policy YAML files and utilizes various hook points such as tracepoints, kprobes, and uprobes. It also provides the capability to perform eBPF filtering within the kernel using selectors and take necessary actions on matching events. Finally, the agent pod deployed on each node dumps tracking events into stdout, allowing the log collector to collect them. Note that we deployed Tetragon in Kubernetes to trace runtime system calls and flow-level information (see Section 3.1 for the details).

3. Cryptojacking Container Attack Detection Framework

This section describes the overall architecture and the workflow of the proposed cryptojacking container attack detection framework. Figure 2 illustrates the two main modules of the framework: (1) system call tracing module and (2) ML-based attack detection module. The system call tracing module utilizes Tetragon to trace the system calls of containers. Tetragon loads the eBPF program into the kernel to monitor the running pods (a set of containers) at runtime. The system calls collected by the tracing module are used as input to the ML-based attack detection module. The detection module extracts features from raw system call sequences of cryptojacking containers and benign containers. These features are then labeled and converted into a dataset for model training. Algorithm 1 describes the overall workflow of the proposed framework.

Algorithm 1 Cryptojacking detection workflow.

Input: System Call Sequence $S_n$ Output: Best Performing Model $M_{best}$ 1: Initialization: 2: Deploy eBPF-based system call tracing (Tetragon) in Kubernetes. 3: Attach eBPF hooks to monitor system call events in real-time. 4: Feature Extraction: 5: Capture system call sequences from monitored containers. 6: Convert system call logs into n-gram feature vectors. 7: Label system call sequences as cryptojacking or benign. 8: Model Training: 9: Split dataset into 70% training, 30% testing. 10: Further divide the training data: 80% for training, 20% for validation. 11: Define a set of candidate models: $M=\{SVM,KNN,DT,MLP,RNN\}$ 12: for each model $M_i\in M$ do 13:     Train model $M_i$ using the training set. 14:     Optimize model hyperparameters. 15:     Validate model $M_i$ using the validation set. 16:     Evaluate model $M_i$ on test data using Accuracy, Precision, Recall and F1-Score. 17: end for 18: Model Selection: 19: Select the best-performing model $M_{best}$ based on overall performance metrics. 20: Return:$M_{best}$

3.1. System Call Tracing Module

To reduce systematic overhead when tracing system calls, we utilize Tetragon, an eBPF-based tool that offers several advantages. Basically, conventional Linux system monitoring toolchains (e.g., strace, ptrace, and perf) introduce unignorable runtime overhead, as each call requires the process to be interrupted twice [20]. This overhead can severely impact overall system performance, particularly in large-scale Kubernetes environments where multiple containers are running concurrently. Additionally, monitoring requires a unique identifier to distinguish running containers. Since containers share the host OS, they can be differentiated at the host level by details such as process ID (PID), thread ID (TID), user ID (UID), and cgroup classes. However, continuously tracking and mapping this information in complex architectures with numerous containers can be inefficient. The eBPF program attaches to various hooks (tracepoints, kprobes, and uprobes) within the kernel space to capture a wide range of system events. When a process calls system calls, the sys_enter event is raised in the kernel, and by hooking into this point, you can retrieve the system call number. Therefore, Tetragon’s Tracing Policy is designed to hook into the sys_enter event triggered within the raw_syscalls subsystem when a system call enters the kernel. The system call number is located in the fifth field (index 4) of the sys_enter event output format. Therefore, the args field is defined with index 4. This Tetragon Tracing Policy code is shown in Figure 1.

eBPF programs are just-in-time (JIT) compiled and executed in kernel mode, allowing for immediate tracking of events as they occur. The collected runtime events are transmitted to user space via eBPF maps. Collecting logs in the kernel space prevents performance degradation caused by context switches, and because the kernel continuously collects logs even when they are periodically retrieved in user space, there is no loss of log data. This enables accurate periodic inspections for container attack detection in user space with minimal overhead.

Additionally, Tetragon is Kubernetes-aware, enabling it to automatically track containers using Kubernetes metadata (such as pod names) without the need to manually track information like cgroup classes, UID, PID, or container IDs for each pod. Therefore, in this study, we utilized Tetragon to hook into the sys_enter event for system calls monitoring, streamlining the container tracking and mapping processes and enhancing the efficiency of the Kubernetes-integrated detection framework.

To detect cryptojacking containers, we implement an ML-based attack detection system that trains on system call datasets obtained from the system call tracing module. In the data processing stage, system call numbers (long_arg) are extracted from the JSON log files generated by the tracing module, resulting in system call sequences in the format, e.g., {186, 14, 14, 3, 13, 59, 158, 218, 12, 12, …}. Then, the system call sequences are converted into feature vectors for input into the ML models. The proposed framework adopts the n-gram method, which can maintain high detection accuracy while reducing the complexity of feature transformation. Existing studies have explored ML-based anomaly detection using system calls and natural language processing (NLP) techniques are used to convert system call sequences into features for learning. Representative NLP methods used for feature representation include frequency-based [21], embedding-based [11,22], and n-gram-based techniques [12,23,24,25,26]. Specifically, [11] used a methodology that converts the system call sequences into a graph and extracts features using anonymous word embeddings. However, this requires significant computational resources for the complex feature extraction process and is time-consuming when processing system call sequences in a large container environment, potentially causing delays in runtime detection. Therefore, we aim for near-runtime detection using a low-complexity method by vectorizing the system call sequences structure into n-gram frames.

N-gram is the most commonly used method to represent system call sequences information while preserving the contextual information of sentences. In n-gram, ’n’ indicates the number of system calls, and a sequence of system calls is extracted from the system call trace in fixed window sizes of n. Figure 3 illustrates an example of a 5-gram frame transformation corresponding to system call sequence S. When sliding the system call sequences into windows of n, it can be configured as overlapping n-grams or non-overlapping n-grams. Considering the system call sequence {186, 14, 14, 3, 13, 59, 158, 218, 12, 12} as an example with a 5-gram approach, the overlapping n-grams are transformed into sequences such as {186, 14, 14, 3, 13} and {14, 14, 3, 13, 59}, while the non-overlapping n-grams are converted into {186, 14, 14, 3, 13} and {59, 158, 218, 12, 12}. Thus, our framework preprocesses system call logs extracted from containers and converts them into overlapping and non-overlapping n-grams for feature extraction. The choice of n is critical in both configurations as it determines how well the contextual information of the system call sequences is captured. Hence, selecting the appropriate n value is crucial depending on the model and the nature of the data. We conduct empirical analyses on various patterns of system call sequences and compare the performance of classification models through experiments. In our experiments, we vary the n values from 5 to 50 to evaluate their impact on model performance.

As a final step, the framework splits the acquired n-gram-based frame sets into training and test data for model construction. This study evaluates the effectiveness of various classification techniques for cryptojacking detection by analyzing the detection performance of five representative machine learning classifiers: support vector machines (SVM), K-nearest neighbors (KNN), decision trees (DT), multi-layer perceptron (MLP), and recurrent neural network (RNN). The objective is to compare the model utility of traditional machine learning and deep learning models to identify the most appropriate model for cryptojacking detection in a cloud-native environment (see Section 4 for details).

4. Evaluation

We evaluated the proposed framework from two perspectives:

• Detection performance: Comparison of attack detection performance by ML models using overlapping and non-overlapping n-gram methods, with n ranging from 5 to 50.
• Systematic overhead: (1) The performance overhead introduced by eBPF-based syscall monitoring compared to the baseline performance under benign workloads and (2) comparison of monitoring overhead between eBPF and perf, analyzed by the number of containers.

4.1. Experimental Setup and Datasets

We set up a single-node Kubernetes cluster in an Ubuntu 20.04 environment using Minikube v1.32.0. For data collection, we deployed two types of cryptojacking containers and four types of benign containers as pods within the cluster. The experimental environment is configured, as shown in Figure 1, where a Tetragon agent pod operates within the cluster alongside the target workload pods to track data. The raw dataset collected according to the logic in Section 3 is processed and transformed into system call sequences.

Table 1. Overview of collected dataset.

Type	Workload	Number of Samples	Total
Cryptojacking	XMRig	115,611	241,043
	xmr-stak-cpu	125,432
Benign	Web-Serving	35,210	241,734
	Data-Caching	50,596
	Media-Streaming	112,003
	MariaDB	43,925

and

Table 2. Workload description.

Workload	Description
Web-Serving	The workload creates a cluster featuring a web server, database server, memcached server and clients. The web server, which operates Elgg, establishes connections with both the memcached and database servers. Meanwhile, the clients are involved in activities such as logging in, messaging, blogging and interacting with posts through comments and likes.
Data-Caching	The client performs requests to access data on the memcached data caching server, simulating the behavior of a Twitter data caching server.
Media-Streaming	The workload runs an nginx web server to host videos of various lengths and qualities. The client performs load testing on the server by requesting different videos based on httperf.
MariaDB	MariaDB is an open-source relational database management system. Using the benchmarking tool sysbench, it performs read and write operations as well as transaction processing commands.
XMRig, xmr-stak-cpu	XMRig and xmr-stak-cpu are representative open source-based Monero mining programs that support -friendly RandomX, allowing users to mine Monero efficiently.

summarize the collected dataset and workload specifications.

For the cryptojacking containers, we included the widely used XMRig [27] and xmr-stak-cpu [28], both of which perform Monero mining. Note that Monero is one of the representative privacy-enhanced cryptocurrencies commonly used on the dark web. Upon deployment, the mining container was designed to automatically start mining operations and connect to the mining pool at pool.supportxmr.com:443, actively generating mining traffic. In the experiment, we collected 115,611 samples from XMRig and 125,432 samples from xmr-stak-cpu, resulting in a total of 241,043 cryptojacking samples.

To reflect a normal cloud-native environment, we included various types of container workloads. Specifically, to monitor diverse activities, we utilized web-serving, data-caching, and media-streaming benchmarks from CloudSuite 4.0 [29]. CloudSuite 4.0 is a benchmark suite designed to measure cloud service performance based on real-world software stacks, providing realistic operational scenarios. Additionally, to evaluate a database service environment, we performed a MariaDB container [30] to perform service load benchmarking. In summary, the collected benign samples consist of 35,210 web-serving samples, 50,596 from data-caching, 112,003 from media-streaming, and 43,925 from MariaDB, totaling 241,734 benign samples.

To evaluate the classifiers, we perform multi-class classification not only to compare cryptojacking containers and benign containers but also to analyze the different behavior patterns of each application in detail. For this, the data transformed into n-gram frames are labeled from 0 to 5. We divide the labeled data into training and test data at a ratio of 70:30, with 20% of the training data further allocated for validation.

To implement SVM, KNN, MLP, and DT models, we used the scikit-learn library v1.6.1 and trained them with default parameters. The RNN model was implemented using TensorFlow 2.18.0 and Keras 3.8.0, consisting of two long short-term memory (LSTM) layers. The hyperparameters used for training each model are summarized in

Table 3. Hyperparameters used for model training.

Model	Hyperparameters	Values
SVM	Kernel Type	RBF
	Regularization (C)	1.0
	Gamma	Scale
	Kernel Coefficient	Scale (auto-adjust)
KNN	k-Neighbors	5
	Weighting	Uniform
	Distance Metric	Minkowski (p = 2)
MLP	Hidden Layer Sizes	(100,)
	Activation Function	ReLU
	Optimizer	Adam
	Learning Rate Init	0.001
DT	Criterion	Gini
	Splitter	Best
RNN	LSTM Layer 1 Units	35
	LSTM Layer 2 Units	80
	Dropout Rate	0.2
	Activation Function	ReLU
	Optimizer	Adam
	Loss Function	Categorical Crossentropy

.

We applied stratified sampling during model training to avoid dependence on specific data distributions. Furthermore, validation data were utilized, and in the RNN model, 20% dropout regularization was implemented to randomly deactivate certain neurons, thereby reducing dependency on specific units and mitigating overfitting. Note that our dataset includes diversiform benign benchmarking data to prevent model overfitting while maintaining a balanced ratio between malicious and benign data.

4.2. Performance Evaluation

To determine the most effective n (length of the n-gram), we varied the value of n from 5 to 50 and compared the performance of the five models using overlapping and non-overlapping n-gram frames.

Figure 4 shows the model accuracy for overlapping n-grams. For SVM, the accuracy steadily increased with larger n-sizes in overlapping n-grams and showed a similar trend in non-overlapping n-grams, as indicated by Figure 5. However, for KNN, the accuracy decreased as n increased in both cases. MLP showed accuracies ranging from 95.92% to 97.52% in overlapping n-grams, but its performance decreased with larger n values in non-overlapping n-grams, reaching an accuracy of 69.95% at n = 50. The rule-based DT maintained high accuracy above 99.59% for all n values in overlapping n-grams, with slight fluctuations. In non-overlapping n-grams, DT showed the highest accuracy of 99.24% at n = 5, but the accuracy slightly decreased as the n-gram size increased.

In the overall detection performance, the RNN achieved the highest accuracy of 99.75% in overlapping n-grams at n = 40, while the DT model attained the highest accuracy of 99.24% in non-overlapping n-grams at n = 5. Figure 6 and Figure 7 present the corresponding confusion matrix results, where (0 = XMRig, 1 = xmr-stak-cpu, 2 = Media-Streaming, 3 = Data-Caching, 4 = Web-Serving, and 5 = MariaDB).

The DT model achieved high detection performance through a rule-based decision-making approach, forming clear classification paths to distinguish cryptojacking workloads from benign system call sequences. While this enhances interpretability, its reliance on static feature selection limits its ability to capture temporal behavioral patterns.

In contrast, the RNN exhibited the highest overall performance by effectively learning temporal dependencies within system call sequences. Unlike traditional ML models that rely on predefined feature extraction, RNNs inherently capture long-range dependencies and sequential structures in the data. As analyzed in Section 5.1, cryptojacking malware typically exhibits repetitive and structured system call patterns, such as sustained high CPU and memory usage and persistent network communication with mining pools. These recurring patterns establish strong temporal correlations, which RNNs effectively model to achieve high detection accuracy. Although the RNN’s accuracy slightly declined in the non-overlapping n-gram configuration, it consistently outperformed other models, demonstrating its robustness in detecting cryptojacking activities.

We then compared our results with the reported accuracy of the previous studies in containerized cloud environments. While we acknowledge that differences in datasets and experimental setups limit direct reproducibility, we performed an indirect comparison using the reported statistics. The results achieved 99.67% accuracy with DT and 99.75% accuracy with RNN, demonstrating superior performance than the prior research [12], and reported cryptomining detection accuracy ranging from 78.9% to 97.1%. We also highlighted that our study differs from [12] in terms of data collection efficiency. The previous approach relied on the Linux perf utility to gather system call data, which imposes high complexity and significant runtime overhead in cloud-native Kubernetes environments, making it less practical for large-scale deployment. In contrast, our proposed framework utilized eBPF-based runtime system call monitoring, allowing for efficient and lightweight data collection while reducing performance overhead.

Table 4. Best model performance in overlapping n-grams.

n	ML Model	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
50	SVM	94.75	95.01	94.75	94.72
5	KNN	99.15	99.15	99.15	99.15
10	MLP	97.53	97.56	97.53	97.53
35	DT	99.67	99.67	99.67	99.67
40	RNN	99.75	99.75	99.75	99.75

Note: The bold values indicate the best-performing model in overlapping n-grams.

and

Table 5. Best model performance in non-overlapping n-grams.

n	ML Model	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
35	SVM	90.65	90.82	90.82	90.26
5	KNN	98.05	98.05	98.05	98.04
5	MLP	95.00	94.97	95.00	94.87
5	DT	99.24	99.24	99.24	99.24
40	RNN	98.12	98.18	98.12	98.14

Note: The bold values indicate the best-performing model in non-overlapping n-grams.

show the best performance of each model in overlapping and non-overlapping n-grams, respectively, indicating that all models generally performed better with overlapping n-grams. The result can be interpreted as overlapping n-grams capturing sequential features more effectively by overlapping sequences and providing more information for model training, although this increases computational costs as training data increases. Also, many duplicate frames can be generated if specific system calls have high call rates. If these identical frames are biased towards a particular class, it can cause the model to overfit that class’s patterns.

On the other hand, non-overlapping n-grams, which reflect features without overlapping sequences, allow for more efficient training with relatively less data but may not sufficiently capture continuous contextual information. The optimal n value also varies between models due to how each model learns the contextual information from the data. Overall, the 5-gram demonstrated decent performance across multiple models.

4.3. Systematic Overhead Characterization

Using eBPF enables runtime monitoring of system calls at the kernel level. However, The additional resource usage introduced by monitoring has the potential to interfere with the execution of application tasks, possibly leading to increased latency. To evaluate this impact, latency measurements were compared under identical workloads, both with and without system call monitoring enabled. Each experiment was repeated 10 times for each workload, with the average latency used as the baseline performance. The results of the overhead analysis are shown in

Table 6. Latency overhead in system call monitoring.

Workload	Latency (ms)		Overhead
	Without Monitoring	With Monitoring
Web-Serving (BrowsetoElgg)	406.636	434.058	1.07×
Web-Serving (AccessHomePage)	344.916	370.972	1.08×
Web-Serving (SendMessage)	153.971	181.111	1.18×
MariaDB	19.263	29.24	1.52×
Data-Caching	3.783	11.29	2.98×

.

In our experiments, the latency overhead varied depending on the characteristics of the workload. For network-intensive tasks such as web-serving, including interactions with web services or back-end databases, the overhead was relatively low, ranging from 1.07× to 1.18×. However, for memory and I/O-intensive tasks such as data-caching, the overhead increased to 2.98×. These results suggest that system calls monitoring in memory-centric tasks can incur significant resource costs. To optimize this overhead, adjusting the system call monitoring frequency according to the characteristics of the workload, especially for I/O-intensive tasks, can help minimize the overhead while maintaining detection performance.

Additionally, as the number of containers to be monitored increases, we evaluated the impact of eBPF-based monitoring and perf-based monitoring, a commonly used Linux monitoring tool on containers. The experiment was performed on the MariaDB container, and latency was measured for 1, 3, 5, 7, and 10 concurrent monitoring instances. The experimental results are shown in Figure 8, and the values in parentheses represent the ratio of latency increase compared to baseline performance without monitoring.

In the case of eBPF, in the case of one monitoring instance, the latency increased to 1.52× compared to the baseline, but in the case of 10 monitoring instances, the latency tended to decrease to 1.28×. This indicates that eBPF can maintain relatively stable performance even as the number of containers increases by processing data directly within the kernel and minimizing user space operations. On the other hand, perf-based monitoring showed a latency of 2.15× under a single monitoring instance, which further escalated to 4.04× as the number of monitoring instances increased to 10. This result demonstrates a structural limitation of perf, where the overhead increases linearly with the number of monitored containers due to the frequent context switching between user space and kernel space required during the data collection process. In conclusion, eBPF showed that it is suitable in terms of scalability while maintaining low latency even as the number of monitored containers increases.

Despite the performance overhead, it is important to highlight the important role of eBPF-based system call monitoring in detecting cryptocurrency mining. Cryptojacking is a significant threat that covertly consumes memory resources, degrading system performance and potentially causing severe system failures. Therefore, considering the benefits of cryptojacking detection, the overhead introduced by eBPF monitoring is a reasonable cost to ensure early detection and mitigation of cryptojacking activities before excessive resource consumption occurs.

5. Discussion

5.1. System Calls Analysis for Cryptojacking Workloads

Finally, we conduct statistical analysis on collected system call sequences to characterize the unique system call pattern of cryptojacking containers. Figure 9 illustrates the top five most frequent 5-gram overlapping frames for six different containers. As shown in the figure, the cryptojacking containers XMRig and xmr-stak-cpu system call patterns significantly differ from the benign containers. Mining programs primarily perform repetitive tasks such as sending and receiving network-based operations and calculating hash values. For example, they periodically perform computational tasks, submit the results via the network and receive new tasks, forming specific system call patterns.

In particular, in the case of XMRig and xmr-stak-cpu, the frames {281, 281, 281, 281, 281} and {24, 24, 24, 24, 24}, respectively, appear with high frequency. sys_epoll_pwait (281) is used to efficiently handle network I/O operations related to poll communication, maximizing the utilization of system resources. Similarly, sys_sched_yield (24) returns the allocated time of a specific thread to the scheduler, enhancing the overall efficiency of the program. As such, mining programs frequently generate system calls that optimize resource usage due to the large volume of computational tasks they perform.

In contrast, media-streaming primarily focuses on continuous network communication and media file access, with frequent occurrences of sys_recvfrom (45), sys_setsockopt (54), and sys_writev (20), which handle data reception, socket configuration, and media buffering, respectively. Additionally, sys_gettid (186) plays a crucial role in thread management, supporting concurrent user streaming. The data-caching exhibits an optimized pattern for fast data retrieval and transmission, with predominant occurrences of sys_read (0), sys_sendmsg (46), and sys_epoll_ctl (233). Specifically, sys_read (0) facilitates memory access, sys_sendmsg (46) transmits cached responses, and sys_epoll_ctl (233) reflects an event-driven model for efficiently handling concurrent requests. Similarly, web-serving frequently invokes sys_read (0), sys_newfstatat (262), and sys_access (21) for webpage loading and file access verification. Additionally, sys_sendto (44) and sys_recvfrom (45) play a critical role in handling client requests and responses, facilitating fast network processing and dynamic user interactions. Finally, the MariaDB revolves around database transactions and network-based data exchange, with sys_sendto (44) and sys_recvfrom (45) frequently invoked for managing data transmission between clients. Additionally, sys_poll (7) ensures efficient handling of multiple simultaneous requests, supporting stable and responsive database operations.

These distinct system call patterns across different workloads contrast with the CPU-intensive computations and persistent network polling observed in cryptojacking workloads. The observed variations highlight the effectiveness of system call-based analysis for cryptojacking detection, providing essential features that can be leveraged in machine learning-based anomaly detection models.

While the proposed method effectively detects typical cryptojacking behaviors, it may struggle against advanced malware variants. While the proposed method effectively detects cryptojacking behaviors based on system call sequences, it might fail to discriminate between benign containers and sophisticated malware variants that attempt to evade detection by mimicking benign workloads (e.g., intentionally inserting dummy system calls). To counter such evasion techniques, integrating eBPF-based runtime security policies through Tetragon can provide an additional layer of protection.

Tetragon enables fine-grained monitoring and enforcement at the kernel level, supporting context-aware tracking of process behavior, privilege escalation attempts, and cross-container interactions. Thus, instead of relying solely on sequence pattern analysis in traditional system call monitoring, it correlates system call behaviors with runtime execution context, enhancing resilience against simple obfuscation techniques. Additionally, by enforcing runtime security policies, unauthorized network access can be blocked, and anomalous privilege escalation attempts can be detected and mitigated, thereby improving cryptojacking detection beyond conventional system call sequence analysis. We leave this integration as a future study.

5.2. Flow-Based Analysis

While analyzing system calls offers critical insights into containers’ internal behavior, analyzing network traffic provides additional visibility into how containers interact with external systems. In this study, as discussed in Section 5.1, we observed cryptojacking containers communicating with mining pools, sending and receiving tasks through system calls related to networking (e.g., send and recv). This behavior can also manifest as distinct communication patterns in network traffic, indicating mining activity from a network perspective.

Miners typically form mining pools to collaborate, thereby increasing their chances of successfully computing hashes and sharing the rewards. This allows mining activities to be detected by utilizing the IP addresses or domain information of known mining pools. However, miners can evade detection by connecting to unknown servers or using a domain name system (DNS) over transport layer security (TLS). Therefore, learning the recurring network communication patterns of mining workloads and applying ML techniques can enable more effective detection [31,32,33].

Tools such as packet analyzers like Wireshark or traffic flow monitoring protocols like NetFlow/IPFIX can be used for data collection, but these tools have limitations when analyzing network traffic in large-scale Kubernetes cluster environments. In Kubernetes, network traffic is distributed across Pods, forming complex mesh network patterns and making it difficult to monitor traffic from a single location. Additionally, monitoring at the host interface can result in the loss of association with the original pod, making it challenging to accurately trace the source of traffic. Deploying traditional network monitoring tools to all Pods is also complex and inefficient.

Similarly, eBPF can be used to effectively monitor network traffic in containerized environments, solving this problem. eBPF programs can be attached to traffic control (TC) hooks in the network stack to monitor traffic. In virtualized environments, it is particularly important to monitor the container’s veth interface before network encapsulation in order to track the container’s IP address and port. In this study, we utilized an eBPF-based network flow monitoring tool, bpfFlowMon, to capture network traffic flows of cryptojacking workloads in a Kubernetes environment. The tool was packaged into a Docker image and deployed across the cluster as a DaemonSet, allowing for the capture and analysis of pod-level network activity on each node.

Figure 10 presents the relationship between Out_Bytes and In_Bytes, as well as Out_Pkts and In_Pkts, based on the extracted network traffic data. Cryptojacking traffic (red) exhibits distinct characteristics compared to various benign service traffic (blue). Notably, cryptojacking traffic shows significantly higher In_Bytes and In_Pkts values relative to Out_Bytes and Out_Pkts. This pattern arises from cryptojacking programs continuously receiving computational tasks from a mining pool, processing them, and subsequently transmitting the results back to the server. This behavior differs from normal applications, which typically follow a structured request-response pattern.

While system call analysis provides detailed insights into computational and resource utilization patterns within a container, network traffic monitoring complements detection by analyzing external communication flows to identify cryptojacking activities. Therefore, integrating these two analytical approaches enables more precise detection. This hybrid approach enhances detection accuracy, reduces false positives, and strengthens resilience against evasion techniques employed by attackers.

6. Conclusions

In this paper, we proposed a framework that combines eBPF-based system call tracing with ML-based attack detection to analyze the state of containers in runtime and effectively detect anomalous behavior in a Kubernetes environment. eBPF enables precise monitoring by tracking system calls at the kernel level while minimizing performance degradation, allowing for runtime analysis of container activities. By applying the n-gram technique to convert system call sequences into feature vectors and evaluating various ML models, we found that the RNN model achieved the highest performance with an accuracy of 99.75%. Additionally, we observed that the performance overhead caused by system call monitoring varied depending on the workload, with higher overhead occurring in memory I/O-intensive tasks. To mitigate this, adjusting the monitoring frequency of system calls in such tasks could be considered. In an experiment comparing the monitoring overhead based on eBPF and perf, as the number of containers increases, eBPF was shown to be more suitable in terms of scalability than perf, maintaining lower latency even when the number of monitoring targets increases.

In addition, we suggest that leveraging eBPF’s network traffic monitoring capabilities to analyze mining activities and combining network traffic-based features with system call patterns can enhance cryptojacking detection performance. Moreover, the proposed framework can be applied not only to cryptojacking detection but also to other types of attack detection. Future research will focus on introducing additional feature extraction techniques to more precisely analyze network activity and process behavior, thereby evaluating the performance under more complex threat scenarios.