Chris Grube and I been tracking some bizarre brute force activity at work since Wednesday but we believe this botnet started attacking as early as March 15th. While brute force attacks are nothing new, this one has some uniqueness to it. One of which is the size of the botnet, it appears that after every 6ish attempts, a new IP roll in and tries again. In a 12-hour period I noted 1600 unique IP’s just for one customer. Between what I’m seeing and what others are, these things could be in the numbers of 10’s of thousands at its current state. The other thing that’s incredibly unique and most concerning is that we’re seeing very unique non-disclosed usernames in the logs. Names that do not even show up in any dumps anywhere, are not showing up in any forums and are so specific and weird that no one would even guess it. I wanted to be clever in naming this botnet, so since all we’re observing is brute force activity, I’m attempting to be funny and name it the Brutus Botnet.
Let’s start from the beginning. Originally, we were tracking this to attacking SSLVPN appliances exposed publicly. Not specific to any firewall vendor either, we’re seeing Fortinet, Palo, Sonicwall and Cisco. Dependent on the company’s architecture we’d see one of two event ids. The most common for me was Event ID 4776, which is NTLM over Kerberous. The other was 6273, which is NPS (Radius). Threat hunting into these logs we wrote queries for the Event ID 4776, validated if the Source Host Name field existed, if it does not exist then we’re seeing VPN traffic or other outside authentications and finally making sure the target username does not contain $. With this we had a pretty solid idea of just how many attempts we were seeing. Spoiler alert it’s 10s of millions a day. To validate if we we’re seeing any successful authentication’s we’d drill down a bit further with Status: 0x0. While working with someone to remediate this issue, we learned this is like far more spread-out than just SSLVPN as they did not have SSLVPN, but they did have a web app exposed to the internet that used AD for authentication. (Thank god no one accepted any MFA push notifications). After relaying this info to colleagues in the field, it was confirmed, this was no longer a targeted SSLVPN attack. But still the one thing everyone is seeing are these unique non-disclosed accounts being brute forced. That question still remains unanswered. Zero-day? Un-disclosed breach? Here’s to hoping we have info on that soon.
On to the “Brutus” botnet, this thing is weird and makes zero sense either. There’s nothing that correlates these Ips together, it’s all completely random. We’re seeing roughly 6 attempts before a new IP steps in and starts trying from there it’s just rinse and repeat. There’s not any distinct location for the botnet either, countries ranging from the US, UK, Russia, China, Netherlands, etc and it’s random locations, i.e. business offices in Brooklyn, Azure, AWS, residential locations. No specific appliances either, random VMs, linux/windows hosts, obscure IoT devices. There are some interesting IPs in the mix as well. Noting some devices from Palo Alto, random legitimate companies, and random CDN’s. Purely speculation right now, but from our estimates this thing could end up being bigger than the Mirai botnet. In 12 hours with one customer, we saw 1600 unique IPs, while other colleagues aren’t seeing any of those IPs and have their own sets of unique IPs. From our base so far, I’ve noted more than 20k unique IPs and we’re not even through our base yet.
The last thing I can note is around the User Agent IDs, I’m seeing mostly Mozilla 5, while others are seeing things like Mozilla 3 or random Chrome UA ID’s. 2 of the more interesting ones I see are Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html) &
Mozilla/5.0 zgrab/0.x.. While the rest are basic iPhone, Apple, Windows, etc.
I’m going to continue to update this blog and twitter/linkedin. More is definitely going to come out from this, but I think there’s going to be a bit of a waiting game for the shoe to drop. I just can’t emphasize enough that everyone needs to be checking their log sources now. I think you’re going to be very surprised to see service accounts that have never been exposed being brute forced thousands of times. Chris Grube and I are continuing to monitor this closely together and will be providing updates as we can.
*UPDATE* Seeing 2 IPs associated with APT29 at least they were in the past.
64.20.30.18/216.182.106.149 — Seeing Brute forcing to SSLVPN & RDP between these two. This is the same APT group who breached MSFT earlier in the year and had stolen source code. Thanks to @DunstableToble1 on Twitter for this assist!
Working theory we had before this update was this pointed back to a MSFT breach due to the nature of the un-disclosed unique accounts being brute forced. This just throws more fuel on the fire of that theory.
*UPDATE 2* After reviewing new IOCs, a common thread between all of these IOCs is cPanel port 2082/2083.
If you have any info to share or would like to collaborate feel free to ping on twitter: https://twitter.com/AnnoyedEngineer & https://twitter.com/cgrub3
Et Tu Brute?
