Information Collection Technology of Cloud Native Environment (I)

Information Collection Technology of Cloud Native Environment (I)

março 31, 2022 | Jie Ji


Information collection is a very important part of both attack and defense, and high-quality information collected is the basis and premise of follow-up work. However, fragmentary information and the complex composition of cloud native itself bring certain challenges to information collection in cloud native environment. This series of posts will share ideas and methods of information collection. in the cloud native environment in a systematic manner.


Information collection is a very important part of both attack and defense. From a macro perspective, most information-related work can be viewed as an alternate cycle of information collecting and information processing. High-quality information collection results are the primary condition for the next step. There is a saying in Sun Tzu’s Art of War: the energy developed by good fighting men is as the momentum of a round stone rolled down a mountain thousands of feet in height. So much on the subject of energy. Only when you have obtained sufficient information can you come to effective and even powerful methods for attacking and defensing.

However, the fragmentary information and the complexity of cloud-native technologies bring certain challenges to information collection in cloud native environment. You might ask: “How difficult is this? I can give you an example: by executing the uname -a command, you will collect a kernel information.”  Yes, information collection is indeed done step by step, item by item. However, if you just take it for granted, the collected information will inevitably be messy, trivial, and probably not comprehensive.

Rather than collecting information, defenders take more attention to consume and analysis information as they, compared to attackers, more easily carry out collect and harvest information they need, from types, scopes, start time to permissions they can be granted. Here I would like to discuss the following four issues from the perspective of an attacker, aiming to help defenders to better identify attack behaviors and motivations. From the perspective of an attacker:

  • What methods are used to collect information in the cloud native environment?
  • How the collected information is categorized?
  • How valuable the collected information is?
  • Does the attacker hinder defenders collecting information?

This article will discuss the first question.

Note: The operations related to the cases in this article are all carried out in an experimental environment. The relevant technologies are only for research and study, and should not be used for unauthorized penetration testing.

From the perspective of an attacker, what methods are used to collect information in the cloud native environment?

There are always rules to go by, starting from a point, and then expanding with all clues. In a cloud native environment, there are usually three attack scenarios, which are always closely related to in information collection:

  • Attacks launched remotely. Remotely-executed attacks are common, for example, executing commands by exploiting unauthorized access vulnerability existing in a Kubernetes API Server or Docker Daemon.
  • Attacks launched from inside containers. An attack launched in a container is usually the post-penetration stage of a penetration test – its premise is that the Shell of a certain permission in the container has been obtained, or that the attacker is one of customers of the service, which is called Container as a Service (CaaS).
  • Image-based software supply chain attacks, including “image vulnerability exploitation”, “image poisoning”, etc.

Correspondingly, there are mainly three types of information collection methods matching these scenarios. Let’s take a look.

Collect information through remote interaction  

In general, there are mainly two main types of remote services open in a cloud native environment: cloud-native control plane service and containerized business service. Remote interaction, as the name suggests, can be done with accessible network only. The amount and value of the information collected depends primarily on the target’s access control mechanism.

(1) Collect information from cloud-native control plane service

As mentioned above, if you encounter a Kubernetes API Server with unauthorized access vulnerabilities, you can easily control the entire cloud native cluster; if the target has a reasonable access control mechanism, the valuable information obtained will be greatly reduced, but not for nothing. For example, many Kubernetes API Servers allow anonymous users to access some API endpoints. In the example below, the attacker obtains the version number of the target Kubernetes by accessing /version:

rambo@t-matrix:~$ curl -k
  “major”: “1”,
  “minor”: “16”,
  “gitVersion”: “v1.16.2”,
  “gitCommit”: “c97fe5036ef3df2967d086711e6c0c405941e14b”,
  “gitTreeState”: “clean”,
  “buildDate”: “2019-10-15T19:09:08Z”,
  “goVersion”: “go1.12.10”,
  “compiler”: “gc”,
  “platform”: “linux/amd64”

Through version matching, attackers will know which vulnerabilities may exist in the target Kubernetes and further exploit them, which is the value of version information.

Even if the target has very strict access controls, attackers can usually gain some information. For example, even if access to /version fails, it is possible to know that the target is a Kubernetes cluster according to the failure information, which is helpful to attackers equipped with knowledge of Kubernetes to detect other Kubernetes control plane service ports (such as kubelet, etcd, etc.).

(2) Collect information from containerized business services

In most cases, containerized and non-containerized business services are not significantly different in terms of information collection, and the information collected is strongly related to the business services (such as web services, database services, etc.) themselves. We won’t go into details these collection methods as there have been many summaries in the security communities.

However, in the process of cloud nativization of many businesses, their own architecture or deployment form will also change, introducing features of microservice governance (such as service mesh) and API governance (such as API gateway). These characteristics are sometimes valuable to collect as they provide some clues about the cloud native environment that hosts the business. For example, if we find that the HTTP return headers interacting with a service contain items starting with x-envoy-, we can infer that the service is in a cloud native environment managed by Istio/Envoy service mesh. Much more important is the “x-envoy-peer-metadata-id”, which contains information such as the Pod where the service is located at, the internal IP of the Pod, and the Kubernetes namespace [1]:

rambo@t-matrix:~$ curl -k -vv 2>&1 | grep x-envoy-peer-metadata-id
< x-envoy-peer-metadata-id: sidecar~

In fact, one of the key steps in cyberspace surveying and mapping is gathering information through remote interactions. When we are carrying out surveying and mapping, we found that cloud native governance programs such as Istio, Envoy, and Kong always are added one or more features on the governed business services. These features are of positive significance for exploring business network topology.

Collect information in Containers

The ability to execute commands to collect information in containers indicates that the attacker has obtained a shell with certain permissions in the container, which is commonly seen in the post-penetration stage of penetration test for cloud native environment. For example, the attacker uploads a Webshell through file upload vulnerability in advance. In addition, CaaS provided by cloud service providers also allow attackers to directly create and access containers as users.

(1) Collect information from cloud-native control plane service

Although the starting point is different, the attacker’s goal in both scenarios is similar: to break out of the container to the host or other containers. However, the initial permissions the attacker has in the two scenarios may be different. With the enhancement of people’s security awareness, many containerized services have been deployed with Rootless Container, and the business process itself runs as a user with low permissions (such as www-data), which is usually Webshell permissions obtained by the attacker. However, as a CaaS user, an attacker can usually have root privileges inside the container.

(2) Collect information through network interaction in the container

Compared with the remote interaction described above, network interaction in containers has unique advantages for attackers. That’s why we put this part here separately, emphasizing “in the container”. Advantages include:

  • Access the intranet. The container has the internal IP addresses of the cloud native cluster, and also has the CAP_NET_RAW permission configured by default. The attacker can find out the internal network topology of the cluster by network scanning or other methods, discover valuable services, and even access metadata services of node. The advantage of network accessibility is worthy of attention, while external attackers usually need SSRF and other means to achieve the same goal.
  • Obtain certain permissions. There may be some form of access credentials in the container of cloud native cluster. One example is the Service Account token carried by Pod, which can be used to access to the Kubernetes API Server and obtain version information, even though it is a low-level permission.

Collect information based on images

In recent years, software supply chain security incidents have occurred frequently, and people have paid more and more attention to them. Containers are created from images, just as processes are created from programs. Therefore, relying on images, attackers can collect a lot of valuable information. Information collection methods include:

  • Using images and image repositories to collect information. Sometimes attackers have limited permissions in the container and cannot read or write critical files and their metadata. If the image used by the target environment can be obtained or its public image repository can be discovered, it will be possible to attackers to find weakness of image components and carry out exploitation.
  • Using a special image to collect runtime environment information. Due to the design problems of container runtimes such as runC, attackers can obtain the container runtime binary program files in the environment by deploying special images in the target environment, thereby obtaining version information and discovering potential vulnerabilities. 


This article is the beginning of a series of “Information Collection Technologies in Cloud Native Environments”, which helps you sort out common methods of information collection in cloud native environments. With this knowledge as a foundation, we will further discuss how to systematically collect trivial and complex information in a cloud native environment.