A cloud-native environment-oriented post-penetration attack traction method and system

Abstract

The application discloses a cloud-native environment-oriented post-permeation attack traction method and system, and the steps thereof comprise: 1) taking the system call behavior of each attack method in a Kubernetes business cluster in a cloud-native environment as a sensitive behavior to obtain a sensitive behavior list; 2) running a target business cluster in a local area network isolated from the outside world and executing each sensitive behavior in the sensitive behavior list to construct a sensitive behavior baseline corresponding to the sensitive behavior and obtain a sensitive behavior baseline list; 3) desensitizing and cloning the target business cluster to obtain a honeynet cluster; 4) deploying the target business cluster and the honeynet cluster on a public network and providing services to the outside world, monitoring and recording the system call behavior in the target business cluster, and regarding a sensitive behavior i and a call chain thereof as normal business operation when the sensitive behavior i and the call chain thereof conform to the sensitive behavior baseline; otherwise, the sensitive behavior i is determined as a malicious behavior; and 5) leading an attacker of the malicious behavior to the honeynet cluster.

Description

Technical Field

[0001] This invention belongs to the fields of cloud-native security and Linux host security, specifically relating to a post-penetration attack targeting method and system for cloud-native environments. Background Technology

[0002] As the global trend of digitalization deepens, cloud computing has become a crucial digital infrastructure for the world's information development. As enterprises continue to cloudify their IT infrastructure and migrate their businesses to the cloud, their network boundaries are also expanding into the cloud. Simultaneously, due to the open, complex, and distributed nature of the cloud, the difficulty of protecting cloud security has increased dramatically.

[0003] Security protection in cloud-native environments can be divided into protection against external attacks and protection against post-penetration attacks. Post-penetration attacks refer to attacks where attackers, after gaining an initial foothold in the system through some means, conduct probing, movement, privilege escalation, etc., to find and control more valuable targets, further expanding the impact of the attack. Post-penetration attacks mean that the attacker has entered the interior of the environment and begun to compromise and damage the more vulnerable parts of the security architecture, wielding significant influence.

[0004] Compared to external attacks, post-penetration attacks have longer attack cycles and longer attack paths. In existing security defense solutions, attack redirection techniques are well-suited for defending against and luring back into the system. Attack redirection techniques, by actively or passively redirecting attacks, slow down the attacker's progress, improve system defense capabilities, and can also obtain the attacker's payload and attack routes through network and host behavior monitoring. Therefore, designing a post-penetration attack redirection framework for cloud-native environments, based on in-depth analysis, to improve system security and facilitate security personnel's analysis of attacker techniques, has become a pressing issue. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a post-penetration attack redirection method and system for cloud-native environments. By constructing sensitive behavior baselines and monitoring system calls, it identifies and redirects post-penetration attack behaviors in cloud-native environments, thereby capturing attackers.

[0006] To achieve the above objectives, the specific technical solution adopted by the present invention is as follows:

[0007] A post-penetration attack pull method for cloud-native environments, comprising the following steps:

[0008] 1) Treat the system call behavior of each attack method within the Kubernetes business cluster in the cloud-native environment as a sensitive behavior, and obtain a list of sensitive behaviors;

[0009] 2) For a target Kubernetes business cluster that requires attack-pull protection, run the target Kubernetes business cluster in a local area network isolated from the outside world; according to the execution of each sensitive behavior in the normal business of the target Kubernetes business cluster in the sensitive behavior list, construct the sensitive behavior baseline corresponding to the sensitive behavior, and obtain a sensitive behavior baseline list.

[0010] 3) De-identify and clone the target Kubernetes business cluster, and create a honeynet cluster for attracting and trapping attacks on the target Kubernetes business cluster;

[0011] 4) Deploy both the target Kubernetes business cluster and the honeynet cluster on the public network and provide services to the outside world. Monitor and record the system call behavior in the target Kubernetes business cluster. When a sensitive behavior i is detected and the call chain of the sensitive behavior i matches the sensitive behavior baseline in the sensitive behavior baseline list, it is considered a normal business operation; otherwise, the currently executed sensitive behavior i is determined to be a malicious behavior.

[0012] 5) Draw attackers with detected malicious behavior to the honeynet cluster.

[0013] Furthermore, the method for obtaining the list of sensitive behaviors is as follows:

[0014] 11) Categorize the available attack methods available to attackers within Kubernetes business clusters in cloud-native environments;

[0015] 12) Utilize automated post-exploitation tools within the Kubernetes business cluster to attack the Kubernetes business cluster and monitor the system call behavior within the Kubernetes business cluster to obtain the system call behavior of the corresponding automated attack methods;

[0016] 13) Collect relevant CVEs for the Kubernetes business cluster, reproduce each CVE in the Kubernetes business cluster, and obtain the system call behavior that occurs during the reproduction process;

[0017] 14) Select key system call behaviors from the system call behaviors obtained in steps 12) and 13) as sensitive behaviors in each attack process, obtain the sensitive behaviors corresponding to each attack method, and construct a list of sensitive behaviors.

[0018] Furthermore, the method for constructing the sensitive behavior baseline is as follows:

[0019] 21) Record the system calls that occur during a period of normal business operation in the target Kubernetes business cluster;

[0020] 22) For each system call a recorded in step 21), if system call a matches sensitive behavior j in the sensitive behavior list, then the behavior chain of sensitive behavior j is obtained by tracing back upwards according to the parent-child process call relationship of sensitive behavior j.

[0021] 23) Record the process name, parent-child process relationship, system call type, and system call parameter information in the behavior chain of each sensitive behavior as the sensitive behavior baseline for the corresponding sensitive behavior, and obtain the sensitive behavior baseline list.

[0022] Furthermore, the system call behavior in the target Kubernetes business cluster is monitored and recorded using a label propagation algorithm. The method is as follows:

[0023] 41) Create a process-tag attribute mapping table. All system calls monitored in the target Kubernetes business cluster are marked as benign. The corresponding process and tag attribute form a mapping record and are inserted into the process-tag attribute mapping table.

[0024] 42) Based on the parent process ID in the system call p monitored in step 41), check whether the label of the parent process of the process to which the system call p belongs is malicious in the process-label attribute mapping table. If it is a malicious label, mark the system call p as a malicious label and record it in the process-label attribute mapping table.

[0025] 43) Obtain the corresponding parent process name based on the parent process ID of the system call p, and search for the child process called by the parent process name in the sensitive behavior baseline list to obtain the parent process-child process call relationship; if the parent process name is not in the sensitive behavior baseline list, mark the system call p as malicious and record it in the process-tag attribute mapping table.

[0026] 44) Determine whether the system call p is a sensitive behavior. If it is a sensitive behavior, then the system call p is a malicious behavior.

[0027] Furthermore, eBPF technology is used to redirect malicious attackers to the honeynet cluster. The method is as follows:

[0028] 51) When establishing the target Kubernetes business cluster, create a corresponding fake sensitive file for each selected sensitive file. When an attacker reads a sensitive file, the system call parameters corresponding to that sensitive file are modified so that the attacker can read the corresponding fake sensitive file.

[0029] 52) Modify the parameters in the lateral movement command line to allow attackers to continue post-exploitation activities within the honeynet cluster when they connect to the database in the honeynet cluster;

[0030] 53) When using kubectl to access the API Server in the target Kubernetes business cluster and operate on the resources in the target Kubernetes business cluster, the attacker can modify the system call parameters to enable the attacker to access the API Server in the honeynet cluster and continue to operate on the resources in the honeynet cluster.

[0031] 54) When an attacker attempts to execute a reverse shell on the target Kubernetes business cluster, the system call for the reverse shell will be terminated, and the corresponding container or node in the honeynet cluster will be notified to execute a reverse shell, so that the attacker can obtain a shell in the honeynet cluster and carry out subsequent attacks.

[0032] 55) Directly block other system calls executed by the attacker against the target Kubernetes cluster.

[0033] Furthermore, secure inbound and outbound rules are set between the target Kubernetes business cluster and the honeynet cluster to achieve network isolation between the target Kubernetes business cluster and the honeynet cluster.

[0034] A post-penetration attack guidance system for cloud-native environments, characterized by comprising a behavior monitoring module, an attack guidance module, and a honeynet cluster;

[0035] The behavior monitoring module is used to treat the system call behavior of each attack method within a Kubernetes business cluster in a cloud-native environment as a sensitive behavior, thereby obtaining a list of sensitive behaviors; and for a target Kubernetes business cluster requiring attack-pull protection, the target Kubernetes business cluster is run in a local area network isolated from the outside world; based on the execution of each sensitive behavior in the list of sensitive behaviors in the normal business of the target Kubernetes business cluster, a sensitive behavior baseline is constructed for the corresponding sensitive behavior, thereby obtaining a list of sensitive behavior baselines; and when both the target Kubernetes business cluster and the honeynet cluster are deployed on the public network and provide services to the outside world, the system call behavior in the target Kubernetes business cluster is monitored and recorded. When a sensitive behavior i is monitored and the call chain of the sensitive behavior i conforms to the sensitive behavior baseline in the list of sensitive behavior baselines, it is considered a normal business operation; otherwise, the currently executed sensitive behavior i is determined to be a malicious behavior.

[0036] The attack redirection module is used to redirect attackers who have been detected engaging in malicious behavior to the honeynet cluster.

[0037] The honeynet cluster is used to lure and trap attacks on the target Kubernetes business cluster; the honeynet cluster is obtained by de-identifying and cloning the target Kubernetes business cluster.

[0038] The steps of the post-penetration attack pull method for cloud-native environments of this invention include:

[0039] 1) By summarizing and organizing the attack methods in the Kubernetes business cluster in the cloud-native environment, the attack methods are reproduced in the Kubernetes business cluster. The system call behavior during the reproduction process is observed and recorded to build a list of sensitive behaviors.

[0040] 2) For Kubernetes business clusters that provide real services to the outside world and need to be protected by attack-pushing methods, first run them in a local area network isolated from the outside world, and construct a sensitive behavior baseline for the execution of each sensitive behavior in normal business for each sensitive behavior in the sensitive behavior list.

[0041] 3) De-identify and clone the Kubernetes business cluster to create a similar honeynet cluster that will not affect normal business operations, which will be used to lure and capture subsequent attackers.

[0042] 4) Deploy both the Kubernetes business cluster and the honeynet cluster on the public network and provide services to the outside world normally. Monitor and record the system call behavior in the Kubernetes business cluster. Use the label propagation algorithm to judge the sensitive behaviors found in the monitoring. If the call chain of the sensitive behavior found in the monitoring meets the sensitive behavior baseline, it is regarded as a normal business operation; otherwise, the currently executed sensitive behavior is judged as malicious behavior.

[0043] 5) For detected malicious behavior, eBPF technology is used to modify system calls to achieve the effect of attack redirection, preventing attackers from damaging the Kubernetes business cluster and redirecting attackers to the honeynet cluster.

[0044] Furthermore, the list of sensitive behaviors is constructed through the following aspects:

[0045] 1) Based on the Kubernetes threat matrix proposed by Y. Weizman, the attack methods that attackers may use in Kubernetes business clusters in cloud-native environments are roughly classified.

[0046] 2) Conduct in-depth analysis of the functions and source code of currently popular automated post-exploitation tools within Kubernetes business clusters, and attempt to run them within Kubernetes business clusters to perform automated attacks, observe their system call behavior, and use it as the system call behavior of the corresponding automated attack methods;

[0047] 3) Attempt to collect CVEs (Common Vulnerabilities and Exposures) related to Kubernetes business clusters in recent years, reproduce each CVE in the Kubernetes business cluster, and sort out the system call behaviors that occur during the reproduction process;

[0048] 4) Summarize and organize the system call behaviors obtained above, select the key system call behaviors in each attack process as sensitive behaviors, and construct a list of sensitive behaviors.

[0049] Furthermore, a baseline of sensitive behaviors is constructed through the following steps:

[0050] 1) Record system calls that occur during a period of normal business operation;

[0051] 2) Based on the existing list of sensitive behaviors, find each sensitive behavior in the recorded system calls. Based on the parent process information in the sensitive behavior system call information, trace back upwards continuously to restore the complete behavior chain of each sensitive behavior.

[0052] 3) Record the process name, parent-child process relationship, system call type, and system call parameter information in the behavior chain;

[0053] 4) Construct a corresponding sensitive behavior baseline for each item in the sensitive behavior list in turn to obtain the sensitive behavior baseline list.

[0054] Furthermore, modifications to system calls are primarily achieved by altering system call parameters, such as changing the filename opened by the attacker or modifying database connection information specified in the command line.

[0055] The positive effects of this invention are as follows:

[0056] With the rapid development of cloud-native technologies, the difficulty of security protection in cloud-native environments has also increased, creating a need to redirect attackers to further capture and analyze their attack methods. Addressing the issue of inefficient redirection of post-exploitation attacks in cloud-native environments, this invention proposes a method combining label propagation and eBPF technologies to redirect attackers engaged in post-exploitation activities to a Kubernetes cluster honeycomb. The label propagation mechanism verifies the legitimacy of sensitive action execution paths to detect attackers' post-exploitation behaviors; the eBPF-based attack redirection technology directly modifies malicious system call behavior, achieving efficient redirection of post-exploitation activities with lower time overhead than traffic redirection and container cloning methods. Attached Figure Description

[0057] Figure 1 This is a system overall flowchart of the present invention.

[0058] Figure 2 This is a flowchart of the label propagation algorithm detection process.

[0059] Figure 3 This is a schematic diagram illustrating the specific implementation method of the attack-driving module. Detailed Implementation

[0060] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, and to make the objectives, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0061] This embodiment provides a post-penetration attack guidance system for cloud-native environments, such as... Figure 1 As shown, the specific steps include:

[0062] Step 100: De-identify sensitive data in the existing business cluster, including information within the database, containers, and nodes. After processing, clone the entire business cluster, create a honeynet cluster based on the original business cluster architecture, and set secure inbound and outbound rules to achieve network isolation between the business cluster and the honeynet cluster.

[0063] Step 200: Identify key system call behaviors that occur during the reproduction of various attack methods in the Kubernetes cluster as sensitive behaviors and construct a sensitive behavior list. Run the Kubernetes business cluster under conditions free from external interference. Based on the compiled sensitive behavior list, construct a sensitive behavior baseline during cluster operation. Record system calls during operation, identify the parent process of sensitive system calls and their associated system call operations, and record them. By continuously tracing back upwards, record the system call type, system call parameters, and process name information associated with each parent-child process pair. Construct a complete call chain baseline for each sensitive system call and add it to the sensitive behavior baseline list.

[0064] Step 300: Run a Kubernetes business cluster in a real environment and deploy a behavior monitoring module to monitor system calls in the cluster. Use a label-based propagation method, combined with parent-child process call relationships and sensitive behavior baselines, to determine label attributes and determine whether system calls are malicious based on the label attributes.

[0065] Step 400: The attack-driving module is used to process malicious and sensitive system calls discovered in the Kubernetes business cluster. By modifying the system call parameters, it induces attackers to attack the honeynet cluster.

[0066] Figure 2 The diagram shows a flowchart of monitoring and detecting system calls using the tag propagation algorithm designed in this invention. The details are as follows:

[0067] Step 310: Create a process-tag attribute mapping table. For all system calls monitored in the Kubernetes business cluster, mark them as benign, and insert a mapping record consisting of the corresponding process and tag attribute into the process-tag attribute mapping table.

[0068] Step 320: Based on the parent process ID in the obtained system call information, check whether the label of the parent process of the system call to which the system call belongs is malicious in a process-label attribute mapping table. If it is a malicious label, the system call will also be labeled as malicious and recorded in the process-label attribute mapping table.

[0069] Step 330: Based on the parent process ID in the obtained system call information, obtain the parent process name, and take the process corresponding to the current system call as the child process. Search for the parent-child process call relationship in the sensitive behavior baseline list. If the call relationship does not conform to the sensitive behavior baseline, the system call will be marked as malicious and recorded in the process-tag attribute mapping table.

[0070] Step 340: If the current system call is labeled as malicious, check if the system call is in the sensitive behavior list. If the label is malicious and it is a sensitive behavior, the system will issue an alarm and hand the system call over to the attack-driving module for processing.

[0071] Figure 3 The diagram illustrates the specific implementation method of the attack redirection module. Utilizing eBPF technology's ability to add mount points in the kernel and modify system calls, combined with honeynet technology, it modifies detected malicious system calls to achieve attack redirection or blocking, thus enticing attackers to shift their attack from the Kubernetes business cluster to the honeynet cluster. The implementation methods are as follows:

[0072] 1) Regarding the reading of sensitive files such as kubeconfig, when the Kubernetes business cluster is established, a similar fake sensitive file is created. When the attacker reads the sensitive file, the attack-driving module modifies its system call parameters, so that the attacker can read the fake sensitive file.

[0073] 2) For lateral movement operations such as connecting to the database, the attack-driving module modifies parameters in the command line, such as the database IP, to enable attackers to connect to the database in the honeynet cluster and continue post-penetration activities in the honeynet cluster.

[0074] 3) For the behavior of using kubectl to access the API Server and operate on resources in the cluster, by modifying the system call parameters and using the kubeconfig of the honeynet cluster, the attacker can access the API Server in the honeynet cluster and then operate on the resources in the honeynet cluster.

[0075] 4) In the event of a reverse shell, the attack-driving module will terminate the system call and notify the corresponding container or node in the honeynet cluster to perform a reverse shell, enabling the attacker to obtain a shell in the honeynet cluster and carry out subsequent attacks.

[0076] 5) For other system calls, the attack-driving module will directly block them, providing protection for the system.

[0077] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail using examples, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cloud-native environment-oriented post-exploitation attack traction method, comprising the following steps: 1) regarding the system call behavior of each attack method in the Kubernetes business cluster in the cloud-native environment as a sensitive behavior, to obtain a sensitive behavior list; 2) running the target Kubernetes business cluster in a local area network isolated from the outside world, and constructing a sensitive behavior baseline corresponding to each sensitive behavior in the sensitive behavior list according to the execution of the sensitive behavior in the normal business of the target Kubernetes business cluster, to obtain a sensitive behavior baseline list; 3) desensitizing and cloning the target Kubernetes business cluster to create a honeynet cluster for traction and trapping attacks on the target Kubernetes business cluster; 4) deploying the target Kubernetes business cluster and the honeynet cluster on the public network and providing services to the outside world, monitoring and recording the system call behavior in the target Kubernetes business cluster, and regarding the call chain of a sensitive behavior i as a normal business operation when the sensitive behavior i is monitored and the call chain of the sensitive behavior i conforms to the sensitive behavior baseline in the sensitive behavior baseline list; otherwise, the sensitive behavior i currently executed is determined as malicious behavior; 5) traction of the detected malicious behavior to the honeynet cluster.

2. The method of claim 1, wherein, The method for obtaining the sensitive behavior list comprises: 11) classifying the optional attack means of the attacker in the Kubernetes business cluster in the cloud-native environment; 12) using an automated post-exploitation tool in the Kubernetes business cluster to attack the Kubernetes business cluster, and monitoring the system call behavior in the Kubernetes business cluster to obtain the system call behavior corresponding to the automated attack method; 13) collecting related CVEs of the Kubernetes business cluster, and reproducing each CVE in the Kubernetes business cluster to obtain the system call behavior in the reproduction process; 14) selecting the key system call behavior in each attack process from the system call behaviors obtained in steps 12) and 13) as a sensitive behavior, to obtain the sensitive behavior corresponding to each attack method, and constructing the sensitive behavior list.

3. The method of claim 2, wherein, The method for constructing the sensitive behavior baseline comprises: 21) recording the system calls occurring in the target Kubernetes business cluster during normal business operation for a period of time; 22) for each system call a recorded in step 21), if the system call a matches a sensitive behavior j in the sensitive behavior list, the behavior chain of the sensitive behavior j is obtained by backtracking according to the parent-child process call relationship of the sensitive behavior j; 23) recording the process name, parent-child process relationship, system call type and system call parameter information in the behavior chain of each sensitive behavior as the sensitive behavior baseline corresponding to the sensitive behavior, to obtain the sensitive behavior baseline list.

4. The method according to claim 1 or 2 or 3, characterized in that, The system call behavior in the target Kubernetes business cluster is monitored and recorded using a label propagation algorithm, and the method is: 41) A process-label attribute mapping table is created, and all monitored system calls in the target Kubernetes business cluster are labeled as benign labels. The corresponding process and label attribute form a mapping record, which is inserted into the process-label attribute mapping table; 42) According to the parent process ID of the system call p monitored in step 41), the label of the parent process of the system call p is searched in the process-label attribute mapping table. If it is a malicious label, the system call p is labeled as a malicious label and recorded in the process-label attribute mapping table; 43) The corresponding parent process name is obtained according to the parent process ID of the system call p, and the child process called by the parent process name is searched in the sensitive behavior baseline list to obtain the parent-child process call relationship. If the parent process name is not in the sensitive behavior baseline list, the system call p is labeled as a malicious label and recorded in the process-label attribute mapping table; 44) Determine whether the system call p is a sensitive behavior. If it is a sensitive behavior, the system call p is a malicious behavior.

5. The method according to claim 1 or 2 or 3, characterized in that, The eBPF technology is used to lure the attacker of the malicious behavior to the honeypot cluster, and the method is: 51) When the target Kubernetes business cluster is established, a corresponding false sensitive file is created for each selected sensitive file, which is used to modify the system call parameters of the sensitive file when the attacker reads the sensitive file, so that the attacker reads the corresponding false sensitive file; 52) Modify the parameters in the horizontal movement operation command line, which is used when the attacker connects to the database in the honeypot cluster to continue the post-penetration behavior in the honeypot cluster; 53) When using kubectl to access the API Server in the target Kubernetes business cluster to operate the resources in the target Kubernetes business cluster, the system call parameters are modified to make the attacker access the API Server in the honeypot cluster to continue operating the resources in the honeypot cluster; 54) When the attacker performs a reverse shell behavior on the target Kubernetes business cluster, the system call that terminates the reverse shell behavior is notified to the corresponding container or node in the honeypot cluster to perform a reverse shell, so that the attacker obtains the shell in the honeypot cluster and performs subsequent attacks; 55) Other system calls performed by the attacker on the target Kubernetes business cluster are directly blocked.

6. The method according to claim 1 or 2 or 3, characterized in that, A secure egress rule is set between the target Kubernetes business cluster and the honeypot cluster to realize network isolation between the target Kubernetes business cluster and the honeypot cluster.

7. A cloud-native environment oriented post-exploitation attack traction system, characterized in that, It includes a behavior monitoring module, an attack luring module, and a honeypot cluster; The behavior monitoring module is configured to take the system call behavior of each attack method in a Kubernetes business cluster in a cloud native environment as a sensitive behavior, and obtain a sensitive behavior list; The target Kubernetes business cluster is run in a local area network isolated from the outside world, and a sensitive behavior baseline corresponding to each sensitive behavior in the sensitive behavior list is constructed according to the execution of the sensitive behavior in normal business of the target Kubernetes business cluster, and a sensitive behavior baseline list is obtained. When the target Kubernetes business cluster and the honeynet cluster are deployed on a public network and provide services to the outside world, the system call behavior in the target Kubernetes business cluster is monitored and recorded, and when a sensitive behavior i is monitored and the call chain of the sensitive behavior i conforms to the sensitive behavior baseline in the sensitive behavior baseline list, the sensitive behavior i is regarded as normal business operation. Otherwise, the sensitive behavior i currently executed is determined as malicious behavior. The attack traction module is configured to attract the attacker of the detected malicious behavior to the honeynet cluster. The honeynet cluster is configured to attract and trap attacks on the target Kubernetes business cluster, and the honeynet cluster is obtained by desensitizing cloning of the target Kubernetes business cluster.

Images