We all know vulnerabilities have a lifecycle. First, they start as closely held secrets, hopefully known to the company producing the vulnerable software. After becoming publically known, there is often a "mad dash" to a public exploit. During this phase, security companies often show their skills by hinting at privately developed exploits first until the exploit is publically known. Once a public exploit is available, the next race starts among adversaries to collect the largest possible market share of vulnerable devices. In this stage, some nation-states may attempt to expand their attack network, while at the same time, kids in basements and North Korea are looking for coin mining bots. Oddly enough, they often do not patch the vulnerability, and you end up with devices being exploited repeatedly. In the end, you have the crustaceans among the attackers picking apart the crumbs or looking for web shells dropped by others. Finally, Iran and Mirai try to see if anything is left for them.
We saw this in a compressed form with CVE-2022-1388, the F5 BIG-IP remote code execution vulnerability. The vulnerability was particular in several ways:
We had this cycle play out over about four days:
The first attack probing for "POST /mgmt/tm/util/bash" arrived on May 9th at 2:34 UTC:
The source IP 220.127.116.11 isn't known for prior attacks, which is interesting. It looks like a "normal" unconfigured Windows web server.
Only about half an hour later, we did see the second attack, this time with a bit a more complex payload from 18.104.22.168:
The base64 encoded text decodes to a simple webshell:
About 4 hours later, we do see attempts to use the webshell from 5 different IPs: 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, and 220.127.116.11. Indicating that the same actor likely controls these IPs.
It followed many more "id," "whoami," and similar commands to determine if our system was vulnerable, mixed in with a few webshells, backdoors, and the usual fare. Only very few attackers attempted to execute anything BIG-IP specific. We got only two or three attackers executing "tmsh" commands to extract users and password hashes. Overall, attackers plugged the exploit into existing tools and "let it go."
One of the more interesting sequences of attacks came at 19:04 UTC on monday from 18.104.22.168:
The speed of this attack (it took about a minute from beginning to end) makes me believe that this was a manually executed attack. The attacker should have noticed that they were dealing with a honeypot but maybe wasn't sure or didn't understand the response, so they killed what they didn't understand with a swift "rm -rf /*."
BIG-IP mounts the /usr partition read-only. This attack would have partially prevented the system from rebooting, but the BIG-IP software may have continued to work for a while.
At least two more attempts were made to run "rm -rf" on our honeypots
Overall, this was about it. "more of the usual." This morning, Brandon Prince, one of our sans.edu interns, reported seeing this malware uploaded to an ssh/telnet honeypot:
It is well detected as Mirai, and a simple string search shows the CVE-2022-1388 exploit present in the file among the usual payloads bots like Mirai are using these days:
Final words (as Brad usually says):
You can't survive from patching alone. A secure configuration will buy you enough time to apply patches. F5 has good guidance, and you should never expose admin interfaces to the internet on any device. At this point: Assume all vulnerable, exposed F5 BIG-IP devices have been exploited. Likely multiple times. Webshells have been installed. Do not just look for published IOCs, but look for all-new, unusual files and rebuild. A more sophisticated attacker may have used the BIG-IP device to target traffic passing through the device.Application Security: Securing Web Apps, APIs, and Microservices - SANS London June 2022
May 13th 2022
May 13th 2022
1 week ago