Attackers Use Containers for Profit via TrafficStealer
Cloud
We found TrafficStealer abusing open container APIs in order to redirect traffic to specific websites and manipulate engagement with ads.
Our team deploys containers and containerized honeypots to monitor any unwanted activities, as well as to reinforce cloud security solutions and recommendations. While these honeypots frequently capture cryptocurrency miners trying to exploit computational resources, we recently discovered a different type of attack: a piece of software that leverages Docker containers to generate money through monetized traffic. Although the piece of software itself appears to be legitimate, it likely has compromised components that result in monitoring as a potentially unwanted application (PUA).
During analysis, we noticed a dataset captured by one of our honeypots; this is unusual, as we did not program our honeypots to do so. Instead of cryptocurrency-mining software or Linux commands likely running reconnaissance, however, we found an unfamiliar program running in the background — a container using our lab network to generate money by driving traffic to specific websites and engaging with ads. The attackers had turned our honeypot into a revenue-generating machine for themselves, but they also left some valuable information behind, allowing us to gain a better understanding of their tactics and gather valuable learnings from this experience.
From the JavaScript Object Notation (JSON) honeypot log we got, we identified information on the targeted IP address, country, traffic movement from the honeypot, timestamp of when the attacks were conducted, token, environment path, and actions taken with the container. We are also continuously monitoring the development of this routine because, as of this writing, the Docker image is still publicly available for download.
One trend that has developed over time is the tendency of attackers to now use either established services or base images rather than crafting their own container image, publishing it, and pulling from their repositories. What we are seeing now is an increased use of those valid images, with the infection or malicious routine starting on or after the deployment through variables and parameters. In this case, YAML structures can be helpful to automate these attacks.
How it works
The container image we spotted in our environment is published by a service that offers “traffic monetization.” The term can be applied in a broader sense and mean different types of services, but in this case, the service promises to pay users who are willing to install the piece of software that takes traffic from various mobile app users and proxies it via this container app. Supposedly, the subscriber receives some money in return for routing their network traffic through the subscriber’s own network. Upon signing up for the service, the user receives a unique token that serves as an ID, which will later be configured and used for retrieving the possible revenue.
Once the attacker’s piece of software or container is installed or run, there is no visibility on the traffic using the subscriber’s device as proxy.
Losing visibility over what is running through the network is a bad idea, but running these kinds of services unknowingly can create an even worse scenario. In the case of our honeypot (and similar to previous attacks that exploited vulnerabilities and misconfigurations to deploy coinminers using containers), this service can be weaponized for attackers to generate revenue. Instead of targeting the CPU, however, the target here is the network traffic to take advantage of victims and generate money.
The piece of software, which we have dubbed “TrafficStealer,” operates using a combination of techniques. Under the assumption that we are running the container and the application ourselves, the developers claim there is nothing illegal in the traffic; however, they also claim to not own any of the traffic generated on the client.
The following are some examples of typically routed traffic on these services:
- Web crawling. This involves scanning the internet for websites that have a high potential for ad revenue. The cybercriminals then target these sites, driving traffic to them through the network.
- Click simulation. Once the targeted websites have been identified, the software generates fake clicks on the ads displayed on those sites. This increases the perceived engagement with the ads, leading to higher ad revenue for the attackers.
All the traffic exchanged with the server is encrypted, and the communication uses an unusual TCP port, which can make activities dubious. Legitimate clients trying to measure the performance of their ads not only have to pay for traffic utilization but also have unknown traffic being routed through their respective networks.
The official service requires the user to create an account for generating a token to be used as a parameter, as well as a unique ID to run the service locally. The attacker that used it on our environment hard-coded their token, passing it as a parameter on container creation.
Looking for a similar behavior on code repositories, we found examples of this same behavior on Dockerfile and docker-compose.yaml files. In some instances, the same behavior could be observed even on cloud pipeline YAML files. YAML configuration files provide structure in giving software configurations and parameters to applications and software, while the cloud pipeline allows for the automation of cloud services’ deployment, run, and modification. In this specific case, the developers and publishers of these YAML files automated the process to publish the configuration file and automatically deploy it to the cloud. This results in faster malware service deployment, automation, and most importantly, attack scaling. Given these files and behaviors, the more runners are deployed, the higher the income collected by the attacker.
Another aspect of the intrusion that caught our attention was the fact that the attacker never created a TTY (a telephone typing command-line interface input terminal where the user interacts with the machine without a graphic interface), which is usually a sign of automated attacks. When attackers want to conduct reconnaissance, or when the attack is more targeted, it is common to see the TTY parameter as “True.” In cases of automated and container attacks that are analogous as worm attacks, these options are often “False.”
One of these services offers a comprehensive web dashboard where an attacker can monitor how the infected nodes are working, including some information about the operating system and the IP address.
The image that was used to infect our honeypot was pulled 500,000 times from Docker Hub alone, processing 15 MB in a matter of seconds. From that data reference, it is hard to estimate how many legitimate sites are running it willingly on their respective environments.
Conclusion
The discovery of this containerized TrafficStealer highlights how threat actors adapt their techniques to take advantage of new and popular platforms. In our own honeypot run and study of the data, 500,000 containers were pulled from a single image at some point in time either for running the container or for inflating the numbers. For some of the subscribers who are aware and supposedly profiting from this service, they might not be reaping the promised returns on capital expenses such as the initial subscription they paid for cloud services. However, some unwitting users might be running it and generating revenue for attackers unknowingly. This implies losses in charges made for cloud services. Moreover, the users did not authorize the piece of software to run on their respective environments (specifically as a PUA), and thereby likely have no control over the traffic that uses the network as a proxy. If the network is being used for criminal activities, the IP address of either the unwitting user or organization is the one that is logged.
In addition, the use of either established services or base images (instead of crafting an entirely new one and publishing it) helps automate attacks with this scope. While it does not give a heightened advantage, it is comparable to using compose for benign processes and helping with automation. While we’ve only found Docker currently being abused, the majority of container-powered platforms, such as Kubernetes and Amazon Elastic Container Server (ECS), can also be abused. If routines like these continue running and are not found to be malicious per se, this routine or scheme can yield a profitable sum even for short periods for those deploying it.
We have yet to complete our analysis to understand the scope and breadth of this technique and routine, but we continue to monitor this technique and deployment to understand the possible illicit activities that can abuse it. To mitigate the risks that threats like TrafficStealer can pose to systems, networks, and containers, here are some best practices we recommend:
- Employ zero-trust security on all container environments.
- Do not leave container APIs unsecured.
- Implement a container authorization policy. No container should be allowed to run without being scanned, signed, and approved.
- Include and/or implement an antimalware scan policy for container images.
Indicator of Compromise (IOC)
| SHA256 | Description | Detection |
|---|---|---|
| 856963cece315dea93a685a9cc76cc2c75a8625694c03c3e15a2bc1a7876606c | traffmonetizer.dmg | Proxyware.MacOS.TraffMoney.A |
Tags
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk
Read More HERE
