A cloud-native application-oriented automated penetration testing method and system

Abstract

The application discloses a kind of cloud native application-oriented automated penetration testing method and system, it is related to computer network security field.The present application is screened from two dimensions in the verification of vulnerability, so as to program to select the target of next penetration testing, overcome the problem of program autonomous decision penetration testing next plan in automated penetration testing.Through the automatic penetration testing of whole process, when moving horizontally, the business and network characteristics of cloud native orchestration system are utilized to carry out the expansion attack between containers, and after complete control, backdoor capable of long-term control application is implanted.The present application reduces the penetration testing and evaluation time of artificial cloud native application, improves penetration testing efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer network security, and specifically to an automated penetration testing method and system for cloud-native applications. Background Technology

[0002] In recent years, an increasing number of applications have begun to migrate to cloud platforms. After more than a decade of development, cloud-based applications have gradually shifted from simply migrating to the cloud to address physical hardware shortages to a cloud-native model designed and developed from the outset to suit the characteristics of the cloud. The emergence of cloud-native and microservices has prompted a shift in security leftward. However, even this has not made it easier for enterprises to cope with the security threats posed by new cloud-native systems. In fact, the emergence of cloud-native and the widespread use of related applications have increased the risks to internal business security. Furthermore, Kubernetes, the container orchestration platform that supports cloud-native containerization, also has many component security issues, making security problems related to cloud-native applications extremely challenging.

[0003] The difficulty in penetrating cloud-native applications and the challenge in timely and accurate vulnerability detection stem from the fact that while they are distributed across traditional network systems, the logic behind their support and maintenance orchestration systems differs from that of traditional networks. Traditional network endpoints and applications exist independently on physical machines or virtual machines, and their operational and management logic has remained largely unchanged for many years. In contrast, cloud-native applications operate on a microservices-based foundation, utilize containers as a platform, and employ orchestration systems like Kubernetes as their management platform. This innovative deployment and management logic of cloud-native applications renders traditional penetration testing methods ineffective in addressing their potential vulnerabilities.

[0004] Cloud-native applications widely adopt distributed, clustered deployments, making it difficult for manual testing to effectively detect and verify vulnerabilities. Security testers need to perform security checks on the kernel and system configuration files of the containers on which cloud-native applications depend, as well as monitor and scan the image repositories that these containers rely on. This significantly extends the testing cycle for security testers. Furthermore, for container orchestration systems, security testers also need to test the security of massive amounts of automated APIs. Existing tools and auxiliary automated penetration testing frameworks are ill-suited to these testing needs and have poor practicality. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes an automated penetration testing method and system for cloud-native applications, thereby resolving the problem that existing technologies and frameworks cannot automatically and effectively detect potential applications and orchestration systems within cloud-native applications.

[0006] To achieve the above objectives, the specific technical solution adopted by the present invention is as follows: An automated penetration testing method for cloud-native applications includes the following steps: 1) Identify the services running on the target cloud-native application and collect information, including service fingerprint information, port open information, and exploitable vulnerability information, to generate a usable information database; 2) Extract high-value information from the available information database and categorize it into three types: high-risk ports, sensitive page titles, and suspicious low-version service vulnerabilities; 3) Further process high-value information, screen available vulnerabilities in the service, and sort and classify the available vulnerabilities according to their severity and location; 4) Based on the identified available vulnerabilities, and using lateral movement techniques from traditional penetration testing, and targeting the network characteristics and container deployment characteristics of cloud-native orchestration systems, lateral movement is achieved between different containers on the same Node and between different Nodes. 5) Combining traditional container persistence technology and orchestration system task hijacking technology, we can achieve persistent monitoring and control of the system where cloud-native applications reside.

[0007] Furthermore, the information collection steps in step 1) include: collecting information by analyzing the differences in exposed ports between cloud-native applications and their orchestration system Kubernetes and traditional applications, as well as the differences in user login control pages of the operation and maintenance system.

[0008] Furthermore, in step 1), when analyzing the exposed ports, the primary focus is on scanning the automated API ports, whose information includes: Port 6443: The core port of the Kubernetes control component API Server, which uses the HTTPS protocol, but in some cases also uses the HTTP protocol, with the port being 8080; Port 10248: The port used by Kubernetes components to check the health status of the Kubelet; Port 10250: The HTTPS port in Kubernetes components that provides services to the API Server; Port 8001: The port where the Dashboard is located, providing a graphical management interface for Kubernetes administrators; and / or Port 2379: The port reserved by the etcd component for communication between the client and the server.

[0009] Furthermore, in step 1), when scanning ports, the discovered conventional ports are also tested. The testing steps include: Traditional ports are divided into web ports and non-web ports. Web ports include traditional CMS ports, while non-web ports are for system services. Traditional ports are scanned according to ICMP, UDP and SMB protocols. The results of the scans according to ICMP and UDP protocols are combined and then subtracted from the results of the scans according to SMB protocols. The subtracted scan result is used as the input for subsequent steps.

[0010] Furthermore, step 3) involves screening available vulnerabilities on the service by comparing the suspected vulnerability targets with the vulnerability verification POC. Vulnerabilities that are successfully verified are considered available vulnerabilities.

[0011] Furthermore, in step 3), based on the severity of the vulnerability, cloud-native security vulnerabilities include code-level vulnerabilities existing during development, configuration errors in orchestration systems and containers, and traditional privilege escalation vulnerabilities.

[0012] Furthermore, the location of the vulnerability in step 3) includes both external network locations and internal network locations.

[0013] Furthermore, in step 4), lateral movement between different containers under the same Node is achieved by accessing localhost; lateral movement between different Nodes is achieved by accessing the CIDR block.

[0014] Furthermore, in step 5), the persistence of the system where the cloud-native application resides includes persistence in the application container and control persistence in the control node. The persistence in the application container is achieved by the Linux service container in the container containing scheduled tasks that can perform periodic execution control instructions. The control persistence in the control node is achieved by the control node's high-privilege control over the cluster.

[0015] Furthermore, in step 5), a malicious third-party image is pulled and used to deploy a malicious container as a backdoor, and a malicious scheduled task is deployed in the controlled container to achieve persistent monitoring and control of the system where the cloud-native application resides.

[0016] An automated penetration testing system for cloud-native applications includes: The information collection module is used to identify the services running on the target cloud-native application and collect information, including service fingerprint information, port open information, and exploitable vulnerability information, to generate a usable information database; high-value information is extracted from the usable information database and classified into three categories: high-risk ports, sensitive page titles, and suspicious low-version service vulnerabilities; The vulnerability screening module is used to further process high-value information, screen available vulnerabilities on the service, and sort and classify available vulnerabilities according to their severity and location. The lateral movement module, built on the lateral movement techniques in traditional penetration testing, is used to exploit selected available vulnerabilities and, based on the network characteristics of cloud-native orchestration systems and the deployment characteristics of containers, to achieve lateral movement between different containers on the same Node and between different Nodes. The persistence control module combines traditional container persistence technology with task hijacking technology of orchestration systems. It pulls malicious third-party images and uses them to deploy malicious containers as backdoors, and deploys malicious scheduled tasks in the controlled containers to achieve persistent monitoring and control of the system where cloud-native applications reside.

[0017] The beneficial effects of this invention are as follows: This invention features targeted designs for target scanning and vulnerability identification and verification, significantly improving the automated identification rate of cloud-native applications. In vulnerability verification, this invention filters vulnerabilities from two dimensions to facilitate the program's selection of targets for the next penetration test, thus overcoming the challenge of autonomous program decision-making in automated penetration testing. This invention automates the entire penetration test process, specifically leveraging the business and network characteristics of cloud-native orchestration systems during lateral movement to scale attacks across containers, and implanting backdoors capable of long-term application control after achieving full control. Overall, this invention greatly reduces the time required for manual penetration testing and evaluation of cloud-native applications, improving penetration testing efficiency and saving manpower. Attached Figure Description

[0018] Figure 1 This is a flowchart of an automated penetration testing method for cloud-native applications in an embodiment of the present invention.

[0019] Figure 2 This is a data processing flowchart of the information collection module in an embodiment of the present invention.

[0020] Figure 3 This is a data processing flowchart of the vulnerability screening module in an embodiment of the present invention.

[0021] Figure 4 This is a data processing flowchart of the persistence module in an embodiment of the present invention. Detailed Implementation

[0022] To enable those skilled in the art to better understand the technical solutions of the present invention, and to make the objectives, features and advantages of the present invention more apparent and understandable, the following detailed description is provided in conjunction with the accompanying drawings and embodiments.

[0023] This embodiment provides an automated penetration testing method for cloud-native applications, such as... Figure 1 As shown, the specific steps include: Step 100: Gather information about the penetration test target. To achieve this goal, it is necessary to design an information scanning program tailored to the characteristics of cloud-native applications, identify and obtain the specific types and purposes of services running on the target, mainly including specific service fingerprint information, port open status, and exploitable vulnerability information, and generate a usable information database.

[0024] To implement the information scanning and collection process, it is necessary to analyze the differences in exposed ports between cloud-native applications and their orchestration systems and traditional applications, as well as the differences in user login control pages of the operation and maintenance system. Specifically, the automated API ports among these exposed ports are the primary scanning targets. Since there is some overlap between the target service ports on cloud-native applications and their orchestration systems and the service ports of traditional applications, and cloud-native containers also deploy some traditional applications, the scanning program needs to test the discovered traditional ports as well, classifying them into web ports and non-web ports. Most web ports are traditional CMS ports, while non-web ports are system service ports, such as OpenSSH remote login services. The scanning program focuses on probing ICMP, UDP, and SMB protocols. Since SMB service is an essential service of Windows file sharing systems and basically only exists on Windows systems, the results obtained from the first two probing protocols are combined and then subtracted from the results of the SMB protocol probing. The remaining part is then used in subsequent processes for information classification and comparison. In the internal network environment, servers with relatively weak security policies may allow the ICMP protocol, while servers with stronger policies may allow the UDP protocol due to business reasons. Taking the union of the two reduces the problem of incomplete target scanning caused by fluctuations in the scanning network.

[0025] The port information is as follows: Port 6443: The core port of the Kubernetes control component API Server, which uses the HTTPS protocol, but in some cases also uses the HTTP protocol, with the port being 8080; Port 10248: The port used by Kubernetes components to check the health status of the Kubelet; Port 10250: The HTTPS port in Kubernetes components that provides services to the API Server; Port 8001: The port where the Dashboard is located, providing a graphical management interface for Kubernetes administrators; Port 2379: The port reserved by the etcd component for communication between the client and the server.

[0026] Step 200: The scanning program will organize and categorize high-value information, classifying it into three types: high-risk ports, sensitive page titles, and suspicious vulnerabilities in low-version services. High-risk ports include sensitive system and third-party application services; most authentication can be obtained through brute-force attacks. In the webpage information gathering, some control pages and login pages of critical systems are exposed to the external network, and these pages may also contain vulnerabilities, making sensitive page titles high-value targets. Finally, the authentication pages of third-party operation and maintenance systems are also high-risk applications; breaking their authentication may grant higher system and network privileges.

[0027] Step 300: This involves verifying and filtering available vulnerabilities on the target service and classifying them. This process requires further processing of high-value information submitted by the scanner. First, suspicious vulnerability targets are compared with known vulnerability verification POCs (Proof of Concepts). Results that fail to verify the existence of security vulnerabilities are discarded, while successfully verified vulnerabilities are added to the database. Then, successfully verified vulnerabilities are classified and evaluated based on two dimensions: the impact and severity of the vulnerability, and its location within the network structure. Vulnerabilities with significant impact and deep vulnerability layers are prioritized for the next exploitation stage.

[0028] Based on their severity, cloud-native security vulnerabilities can be broadly categorized into two main types: code-level vulnerabilities inherent in the development process and misconfigurations in orchestration systems and containers. These vulnerabilities include high-risk issues such as command execution, code execution, and privilege escalation, which could allow attackers to control or compromise applications or the cloud environment. Additionally, because cloud-native applications rely on Docker containers, traditional privilege escalation vulnerabilities such as kernel overflows also exist. In contrast, information leakage and XSS vulnerabilities, common in web applications, are less critical in automated penetration testing because they are difficult to exploit.

[0029] The automated program primarily utilizes unauthorized access vulnerabilities in cloud-native applications, API abuse and unauthorized access vulnerabilities in cloud-native application business vulnerabilities, and injection, XXE, invalid access control, and security misconfiguration vulnerabilities in Serverless applications. Simply performing loop probing and saving vulnerability information is insufficient to support full-process automation. In mature network architectures, various service programs are deployed at different network layers based on different business needs. Therefore, it is necessary to pre-design for potential web service vulnerabilities and third-party supporting software vulnerabilities that may occur at different network layers, possessing lateral movement or privilege escalation value.

[0030] Vulnerabilities are primarily located in external and internal network environments. In the penetration testing phase of container applications, the most common vulnerabilities are microservice applications developed using traditional Java frameworks and middleware. Therefore, in such an environment, any vulnerability can be exploited through remote code execution (RCE) against these frameworks. Step 400: Combining the lateral movement technique in traditional penetration testing, design a lateral movement module for cloud-native orchestration systems. This module utilizes the vulnerabilities identified in Step 300 to perform lateral movement between different containers on the same Node and between different Nodes, based on the network characteristics and container deployment characteristics of the cloud-native orchestration system Kubernetes.

[0031] Lateral movement in traditional penetration testing refers to the process by which an attacker, after successfully compromising a computer system, uses that system's authentication information and permissions to attempt to further attack other computer systems or resources. This attack method typically involves searching for other vulnerable computers or resources within the target network, then using the credentials or permissions of the compromised computer to access these target systems or resources. Attackers often employ several techniques during lateral movement, such as: ① Stealing credentials: Attackers use various methods, such as phishing and social engineering, to attempt to steal other users' usernames and passwords, and then use these credentials to launch attacks. ② Exploiting weak passwords: After successfully cracking a user's password by enumerating or guessing it, attackers can use these passwords to launch attacks. ③ Exploiting vulnerabilities: Attackers exploit existing vulnerabilities in the system to gain access and perform lateral movement. ④ Exploiting trust relationships: Attackers exploit existing trust relationships in the system, such as domain trust relationships, to obtain credentials or permissions from other computers. Through lateral movement, attackers can gain higher privileges, thereby controlling more system resources and ultimately achieving control of the entire target network. Therefore, preventing lateral movement attacks is extremely important during penetration testing.

[0032] In Kubernetes, a Node is a worker node in a cluster used to run container instances. Each Node runs a container runtime environment (such as Docker) and can be assigned as a host for Pods. Pods running on Nodes can access and communicate with each other through Kubernetes' service discovery mechanism, and Nodes can also communicate with each other over the network.

[0033] Specifically, multiple containers within the same Pod share the same IP address and port space, which are assigned through the network namespace allocated to the Pod and can find each other via localhost. Therefore, lateral movement between different containers within the same Node can be achieved by accessing localhost. However, lateral movement between different Nodes requires consideration of the CIDR block allocated to each node in the cluster. This block specifies the available IP addresses for the Pods running on that node. Once traffic flowing to the CIDR block reaches the node, the node is responsible for forwarding the traffic to the correct Pod, thus enabling lateral movement of containers between different Nodes.

[0034] In summary, this step will combine Kubernetes' network and control structure, and utilize lateral movement techniques between different containers on the same Node and between different Nodes to implement lateral movement modules for cloud-native orchestration systems, thereby improving the efficiency and accuracy of penetration testing.

[0035] Step 500 involves maintaining permissions for the cloud-native application cluster and orchestration system controller. In this step, security testers pull a malicious third-party image and use it to deploy a malicious container as a backdoor. Simultaneously, they deploy malicious scheduled tasks within the already controlled containers to achieve persistent control. Implementing this step requires combining traditional container persistence techniques with orchestration system task hijacking techniques to achieve persistent monitoring and control of the system hosting the cloud-native application.

[0036] Traditional container persistence refers to storing data or state within a container so that it persists even after the container is shut down. Task hijacking techniques in orchestration systems, on the other hand, involve controlling the lifecycle of containers within the orchestration system to hijack tasks or processes running within them. Combining these two techniques allows for the persistence of tasks or processes running within containers, ensuring they persist even after the container is closed, thus achieving persistent control. This allows attackers to continuously control cloud-native application clusters and keep malware running, enabling more covert attacks. For security testers, combining these two techniques allows for better testing of cluster security, identification of potential vulnerabilities, and the implementation of measures to strengthen cluster security.

[0037] Specifically, this step leverages the characteristics of containers and control systems to achieve persistent control. Persistence is divided into persistence within the application container and control persistence within the control node. Persistence within the application container utilizes the feature of Linux service containers containing scheduled tasks that can periodically run control instructions, allowing malicious scheduled tasks to be deployed within the container to achieve persistent control. Control persistence within the control node leverages the high-privilege control the control node has over the cluster to achieve persistent control.

[0038] In implementing persistent control, it is crucial to pay attention to the content and functionality of malicious images and scheduled tasks used by security testers, as well as their potential risks and impacts. Furthermore, to avoid detection and prevent discovery, security testers need to implement a series of covert measures, such as obfuscating code, hiding malicious containers, and scheduled tasks.

[0039] This embodiment also proposes an automated penetration testing system for cloud-native applications to implement the above method. The system includes the following modules: The information collection module is used to identify the services running on the target cloud-native application and collect information, including service fingerprint information, port open information, and exploitable vulnerability information, to generate a usable information database; high-value information is extracted from the usable information database and classified into three categories: high-risk ports, sensitive page titles, and suspicious low-version service vulnerabilities; The vulnerability screening module is used to further process high-value information, screen available vulnerabilities on the service, and sort and classify available vulnerabilities according to their severity and location. The lateral movement module, built on the lateral movement techniques in traditional penetration testing, is used to exploit selected available vulnerabilities and, based on the network characteristics of cloud-native orchestration systems and the deployment characteristics of containers, to achieve lateral movement between different containers on the same Node and between different Nodes. The persistence control module combines traditional container persistence technology with task hijacking technology of orchestration systems. It pulls malicious third-party images and uses them to deploy malicious containers as backdoors, and deploys malicious scheduled tasks in the controlled containers to achieve persistent monitoring and control of the system where cloud-native applications reside.

[0040] Figure 2 The diagram shows the data processing flowchart of the information collection module. It pre-defines fingerprint information of common cloud-native applications and their orchestration systems, while simultaneously collecting fingerprint characteristics and vulnerability features of high-risk common applications. During the scanning process, high-value target information and potential vulnerability information are stored in the database for later use. Specific details are as follows: Step 210: Services are exposed to users via ports. Network services can be divided into web services and non-web services. Web service attack testing points include traditional web vulnerabilities and unique middleware vulnerabilities, while non-web service vulnerabilities include service brute-force and overflow vulnerabilities.

[0041] Step 220: In cloud-native applications, web services include control and interaction web pages for Kubernetes components. These components have numerous disclosed vulnerabilities and unauthorized configurations. Other web vulnerabilities in non-Kubernetes components are also highly valuable, as they are likely found in legacy applications deployed in cloud-native containers.

[0042] Step 230: Perform a system brute-force attack on non-web services to obtain specific information about the system. Many services on the intranet use default passwords.

[0043] Step 240: Regardless of whether it is a web service, this module will execute commands after performing an automated vulnerability attack to check whether it has entered the container, in order to facilitate subsequent automated penetration testing.

[0044] Figure 3 The diagram shows the data processing flow of the vulnerability screening module. Based on the information reported and summarized by the scanning program, high-value targets and potential vulnerabilities are tested and verified. If a vulnerability is successfully verified, its potential impact is assessed, and vulnerabilities with the greatest impact and harm are selected as entry points for further in-depth penetration. Simultaneously, based on the vulnerability location, vulnerabilities that are conducive to penetrating the internal network are selected for the next penetration test. Specific details are as follows: Step 310: During automated penetration testing, the entire penetration process is progressively deeper. The target program may be located on an edge device or in a compromised container, so this module will first determine the location of the vulnerability to be exploited next.

[0045] Step 320: If the vulnerability to be exploited next is a vulnerability in a machine that has already been compromised, then check if privilege escalation is possible.

[0046] Step 330: If the vulnerability to be exploited next is a vulnerability in another uncompromised target, first check whether the vulnerability has unauthorized access or command execution vulnerability in order to conduct deep network probing and scanning.

[0047] Step 340: After confirming the existence of two types of vulnerabilities, namely unauthorized access and command execution, proceed with the next level of target probing.

[0048] Figure 4The diagram shows the data processing flow of the persistent control module. A backdoor is implanted into the container and control node machine, which are already under complete control, to persistently control the application and system. Detailed explanation follows: Step 410: The target address data comes from network probes in the cloud-native orchestration system and network data sniffed from vulnerabilities in various container applications.

[0049] Step 420: Post-exploitation includes implanting backdoor trojans and rewriting the target machine's scheduled tasks. These functional files and codes are written in advance and automatically delivered during the post-exploitation phase.

[0050] Step 430: After the door trojan is delivered, the permissions are maintained. This module will record the nodes that have been persistently controlled and report them to the control program.

[0051] Step 440: After completing the deployment of the door, clean up the logs and useless files from the previous detection, attack and persistent control.

[0052] Experimental test: To verify the effectiveness of the automated penetration testing method for cloud-native applications proposed in this invention, a comparative experiment selected 30 vulnerabilities from 52 security issues across 8 categories in cloud-native application scenarios. These 30 vulnerabilities were chosen for testing in a target environment. The experiment divided these 30 vulnerabilities into three groups of 10 each, representing a wide range of attacks from intrusion into internal networks to lateral movement and persistent privileges. After the comparative experiment, the results were projected onto an existing ATT&CK threat matrix to determine whether the method conceived and designed in this invention can cover as many threat stages as possible.

[0053] As a comparison with the method of this invention, Metasploit, a penetration testing framework that has been popular in the industry for many years, and CDK, a cloud-native penetration testing auxiliary tool developed by Tencent Cloud Ding Lab, were selected.

[0054] The selected vulnerability scenarios cover the entire process, from peripheral internet applications to internal support applications, and then to cloud-native infrastructure applications. Furthermore, both the severity and difficulty of exploitation of these vulnerabilities closely match the selected control group programs. Similarly, the components selected for vulnerability exploitation are well-known vulnerabilities since 2018, ensuring both difficulty of exploitation and, as far as possible, that the vulnerabilities were publicly disclosed in recent years.

[0055] Table 1 Comparative Experiment 1 Table 2 Comparative Experiment 2 Table 3 Comparative Experiment 3 From the three sets of comparative experiments, the CDK program successfully detected and exploited 19 vulnerabilities, Metasploit detected 11, and the method of this invention detected 23 vulnerabilities. The programs covered the ATT&CK process: CDK detected 6.7 vulnerabilities, Metasploit detected 3, and the method of this invention detected 7.7. The statistical results are shown in Table 4.

[0056] Table 4. Statistical analysis of comparative experimental results The above experimental tests demonstrate that the technical solution proposed in this invention maintains good automated penetration testing performance in cloud-native environments. It shows a certain improvement in vulnerability identification rate compared to existing mainstream penetration testing tools for cloud-native environments, and a significant improvement compared to traditional penetration testing frameworks. The penetration testing process is highly complete, covering a wide range of vulnerability types. Furthermore, it can cover most ATT&CK threat matrices and outperforms the comparative experimental tools.

[0057] 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. An automated penetration testing method for cloud-native applications, characterized in that, Includes the following steps: 1) Identify the services running on the target cloud-native application and collect information, including service fingerprint information, port open information, and exploitable vulnerability information, to generate a usable information database; 2) Extract high-value information from the available information database and categorize it into three types: high-risk ports, sensitive page titles, and suspicious low-version service vulnerabilities; 3) Further process high-value information, screen available vulnerabilities in the service, and sort and classify the available vulnerabilities according to their severity and location; 4) Based on the identified available vulnerabilities, and using lateral movement techniques from traditional penetration testing, and targeting the network characteristics and container deployment characteristics of cloud-native orchestration systems, lateral movement is achieved between different containers on the same Node and between different Nodes. 5) Combining traditional container persistence technology and orchestration system task hijacking technology, we can achieve persistent monitoring and control of the system where cloud-native applications reside.

2. The method as described in claim 1, characterized in that, Step 1) involves information collection, which includes: analyzing the differences in exposed ports between cloud-native applications and their orchestration system Kubernetes and traditional applications, as well as the differences in user login control pages of the operation and maintenance system; when analyzing the exposed ports, the focus is on scanning automated API ports, which include: Port 6443: The core HTTPS protocol port for the Kubernetes control component API Server; Port 8080: The port used by the Kubernetes control component API Server when it uses the HTTP protocol; Port 10248: The port used by Kubernetes components to check the health status of the Kubelet; Port 10250: The HTTPS port in Kubernetes components that provides services to the API Server; Port 8001: The port where the Dashboard is located, providing a graphical management interface for Kubernetes administrators; and / or Port 2379: The port reserved by the etcd component for communication between the client and the server.

3. The method as described in claim 1, characterized in that, In step 1), when scanning ports, the discovered traditional ports are also tested. The testing steps include: Traditional ports are divided into web ports and non-web ports. Web ports include traditional CMS ports, while non-web ports are for system services. Traditional ports are scanned according to ICMP, UDP and SMB protocols. The results of the ICMP and UDP scans are combined and then subtracted from the results of the SMB scan. The result of the subtraction is used as the input for subsequent steps.

4. The method as described in claim 1, characterized in that, Step 3) involves screening available vulnerabilities on the service by comparing the suspected vulnerability targets with the vulnerability verification POC. Vulnerabilities that are successfully verified are considered available vulnerabilities.

5. The method as described in claim 1, characterized in that, The available vulnerabilities mentioned in step 3) include code-level vulnerabilities present during development, misconfigurations of orchestration systems and containers, and traditional privilege escalation vulnerabilities.

6. The method as described in claim 1, characterized in that, The location of the vulnerability in step 3) includes both external network locations and internal network locations.

7. The method as described in claim 1, characterized in that, In step 4), lateral movement between different containers under the same Node is achieved by accessing localhost; lateral movement between different Nodes is achieved by accessing the CIDR block.

8. The method as described in claim 1, characterized in that, Step 5) Persistence of the system where the cloud-native application resides includes persistence in the application container and control persistence in the control node. Persistence in the application container is achieved by deploying scheduled tasks in the controlled container and having the scheduled tasks periodically run control instructions. Control persistence in the control node is achieved by leveraging the high-privilege control of the cluster by the control node.

9. The method as described in claim 1, characterized in that, In step 5), a malicious third-party image is pulled and used to deploy a malicious container as a backdoor. Malicious scheduled tasks are then deployed in the controlled container to achieve persistent monitoring and control of the system where the cloud-native application resides.

10. An automated penetration testing system for cloud-native applications, characterized in that, include: The information collection module is used to identify the services running on the target cloud-native application and collect information, including service fingerprint information, port open information, and exploitable vulnerability information, to generate a usable information database; high-value information is extracted from the usable information database and classified into three categories: high-risk ports, sensitive page titles, and suspicious low-version service vulnerabilities; The vulnerability screening module is used to further process high-value information, screen available vulnerabilities on the service, and sort and classify available vulnerabilities according to their severity and location. The lateral movement module, built on the lateral movement techniques in traditional penetration testing, is used to exploit selected available vulnerabilities and, based on the network characteristics of cloud-native orchestration systems and the deployment characteristics of containers, to achieve lateral movement between different containers on the same Node and between different Nodes. The persistence control module combines traditional container persistence technology with task hijacking technology of orchestration systems. It pulls malicious third-party images and uses them to deploy malicious containers as backdoors, and deploys malicious scheduled tasks in the controlled containers to achieve persistent monitoring and control of the system where cloud-native applications reside.

Images