Cyber Threats
Metasploit Shellcodes Attack Exposed Docker APIs
We recently observed an interesting payload deployment using the Metasploit Framework (MSF) against exposed Docker APIs.
We have discussed the importance of keeping Docker APIs secure in previous articles, as leaving them exposed can give cybercriminals unfettered access to the host with root privileges. This access can lead to distributed denial of service (DDoS) attacks, remote code execution (RCE), and unauthorized cryptocurrency mining activity.
We recently observed an interesting payload deployment using the Metasploit Framework (MSF) against exposed Docker APIs. This active attack involves the deployment of Metasploit’s shellcode as a payload, and this is the first attack that we’ve seen that uses MSF against Docker. It also uses a small and a vulnerability-free base image in order for the attack to proceed in a fast and stealthy manner.
Technical Analysis
One of the first things we’ve noticed is the attackers’ use of “alpine:latest” as their base container image. Aside from being known for its small size, Snyk did not detect any vulnerabilities in the image, allowing attackers to pass through checks that are meant to flag the use of vulnerable images. Snyk provides security scanning services, including for open-source and containers.
We found that most of the latest attacks on our container honeypots are taking advantage of well-known and established base images. Doing this allows them to bypass malware and vulnerability checking.
We also saw that the executed commands follow Base64 encoding as opposed to the more traditional plain text encoding, a trend within the Linux malware scene that we’ve mentioned in a previous article. The container is executed with privileged flags, which means that the payload has host root privileges.
Lastly, the most interesting observation pertains to the payload itself. As shown in the screenshot in Figure 4, the whole payload is compressed into a small file size using Base64 encoding. When we decoded the payload, we obtained an executable link format (ELF) file with a minuscule size of only 250 bytes.
Further analysis revealed that the payload wasn’t written in any high-level programming language but in pure assembly code. As such, there are no excess instructions that require processing, allowing a very small Base64 encoding to perform the necessary work to execute code. However, the motivation might be simpler than that, for example, the limit of number of characters present on the shell line.
The deployed payload first allocates a 4,096-byte memory page with the “PROT_READ,” “PROT_WRITE,” and“PROT_EXECUTE” protection flags. These flags allow attackers to execute code inside this part of the memory region.
The TCP socket is then opened from inside the system and the connection is initiated with the C&C server. This is made evident by the hardcoded “sockaddr” structure.
A “read syscall” is executed on an opened socket descriptor, and will then read up to 126 bytes from the C&C server. These are saved inside the previously mentioned allocated memory region and then executed.
This notable technique is reminiscent of shellcode behavior, so we looked into it and discovered that the ELF file is a compiled Metasploit reverse_tcp shellcode. It is a simple x64 ELF file with the attacker IP and PORT hardcoded in the binary. Despite not being obfuscated, the file’s hash could not be found on any online threat platform at the time of writing.
Since there was an indication that this was a reverse_tcp file generated by the MSF, we created a proof of concept that spoofs the attackers’ IP of a container and runs the backdoor in a secure environment to obtain the reverse shell.
Conclusion
Exposed Docker APIs have become prevalent targets for attackers as these allow them to execute their own malicious code with root privileges on a targeted host. While we’ve mostly seen cryptocurrency-mining deployments in attacks that abuse exposed Docker APIs in the past, this recent attack indicates that more stealthy techniques are entering the landscape. We also expect attackers to deploy more advanced threats the near future.
In the two years spent monitoring our honeypots, this is the first time that we’ve seen an attack that uses an MSF exploit right away. It’s important to note that due to our honeypot configuration, the attacker didn’t have a lot of time to perform further attacks. This means that we cannot conclude what the attackers’ main motivation is with this specific attack. We are continuing to monitor the indicators of compromise (IOCs) and will be providing updates based on new discoveries and further analyses.