In today’s digital age, many educational institutions rely on innovative platforms to make hands-on learning more accessible. A client providing a SaaS (Software as a Service) platform for educational purposes faced an unexpected challenge. Their solution allowed teachers to set up virtual lab environments — mini-servers pre-installed with the required software for hands-on student training. Each student received an isolated environment to practice and complete practical tasks using isolated, pre-configured servers without complex setups on their personal devices.
Here’s how it works: The platform uses Google Cloud Platform (GCP) to create virtual machines for each teacher. These machines group into a Docker Swarm cluster, which powers a dashboard for managing lab activities. Teachers upload customised Docker images containing the required software, and each student accesses their private lab environment through a unique link.
This setup allows students to focus on their learning while teachers efficiently manage multiple labs from a dashboard. However, a student discovered a vulnerability in the system and exploited it, turning the educational environment into a hub for unauthorised cryptomining activity.
This incident reminds us all about the importance of implementing robust safeguards to protect advanced, well-intentioned systems from opportunistic exploitation and misuse.
Cryptominer Detected
A notification from the Google Cloud Platform alerted us to a cryptominer running on one of the client’s servers. Without delay, we connected to the server using the IP address specified in the alert to investigate further.
To find the culprit, we executed the `htop` command and sorted processes by CPU usage. We identified a suspicious process consuming relatively high resources; its name also contained the word “miner” 🙂.
Using the PID of the process identified in `htop`, we ran the command `cat /proc/<PID>/cgroup` to uncover the Docker container ID associated with this suspicious process.
Here’s an example of the output:
sudo cat /proc/11549/cgroup12:devices:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
11:rdma:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
10:pids:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
9:freezer:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
8:perf_event:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
7:cpu,cpuacct:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
6:blkio:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
5:memory:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
4:hugetlb:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
3:cpuset:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
2:net_cls,net_prio:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
1:name=systemd:/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
0::/docker/ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a
—
In this case, ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a — is the container’s ID. Note that the actual ID is 64-bit, while the Docker `ps` command displays only the first 12 characters — ddff0f76467f.
Next, we retrieved the container name using the command:
docker ps -a --filter "id=<container_id>"
Example:
docker ps -a --filter "id=ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a"
This revealed the container’s name, allowing us to trace its owner through the platform’s web interface; the container belonged to a student performing lab tasks.
We connected to the container with the miner using the command:
docker exec -it ddff0f76467f0f62acf57affdaa8cc426c6175c86ebcb8090f57eeb66451c69a bash
Inside the container’s file system, we found a cryptominer archive and the active mining process. The student had exploited their lab container by uploading the miner via SSH, extracting it, and running it.
Fortunately, the container’s CPU and memory usage were capped, so the miner only consumed 3% of a single node’s CPU, with minimal impact on the main server.
We promptly terminated the mining process and informed the client, who could take appropriate disciplinary action against the student.
