MikroTik? She doesn’t even go here

I recently shared some basic analysis of traffic to my SSH honeypot, and this is a continuation of that work. If you want to know details about my setup or read the overview, you can find that here.

Introduction

One of the things I discovered in my initial look at the data was a number of attempted logins and user input related to MikroTik routers. Having dealt with MikroTik-powered botnets in the past, this caught my eye. I’ve been on the side of defending against brute forcing and credential stuffing attacks powered by zombie routers, but I’d never taken the time to look closely at the infection process.

If you’re less familiar with MikroTik, you may be wondering why this brand of routers, in particular, warrants an entire writeup. While coverage of this alone could fill an entire post, here are a few highlights: vulnerabilities in MikroTik routers have been exploited for cryptojacking, hosting TrickBot C2s, and general botnet shenanigans.

Despite patches being released for these vulnerabilities, lack of security updates by router admins has left them vulnerable to opportunistic actors:

Searching Shodan for “product:mikrotik” yields just under 4 million results as of 2021–01–01, 18:06 UTC.

I used the Reports feature in Shodan’s UI to examine the results more closely. MikroTik’s most recent RouterOS versions are 6.46.8 (Long-term), 6.48 (Stable), 6.48rc1 (Testing), and 7.1beta3 (Development).

Version 6.46.8 barely makes it into the top thirty most common versions seen on Shodan, and the others are further down the list.

Whew, okay. Hopefully I’ve presented a compelling case as to why I wanted to look further into MikroTik-related honeypot activity.

Logins and input

In my previous post, I briefly addressed some attempted logins to my honeypot with username “MikroTik,” which quite honestly, weren’t all that exciting. As of 2021–01–01 18:24 UTC, I have 211 attempted logins with a username of “MikroTik”, but as observed previously, none of these attempts have provided input once in the honeypot. Given the automated appearance of the login attempts, it’s possible that the script has a condition to disconnect if all of the following passwords appear to work. That’s total conjecture, but it’s at least one way I might discern whether I’d connected to a honeypot or a real router.

As I mentioned, this wasn’t all that exciting, as it wasn’t tied to any user input. I’m sure there are plenty of things to dig into around IP addresses and networks, but I was more curious about more active attempts to take over my machine. Fortunately, I found just that.

I was pretty certain these commands were attempting to add some task to a schedule on a 10 minute interval to download this “7wmp0b4s.rsc” file, but it didn’t look like any system scheduler I’d seen (which, admittedly, is not that many–but still).

Beyond a quick glance at the command, the unusual filename seemed like a good place to start, so I searched for “7wmp0b4s.rsc,” figuring I wasn’t the first to have seen it. I had no idea this activity was related to MikroTik before searching for the file.

The .rsc file, as it relates to MikroTik, is a human-readable configuration file for the router. The commands shown above attempt to use the MikroTik scheduler to download the .rsc file.

This command only works on MikroTik devices, so no file was downloaded and available for me to examine. However, I found a recent Sophos report on Glupteba malware that outlines how RouterOS is exploited as a part of the malware’s operation (pp. 38–42). According to their research, the “scheduled task downloads the file to the router in every 10 minutes. The script contains SOCKS proxy settings to allow communications for [multiple IP addresses]” (p. 40).

I also found a Reddit result that contained the .rsc file delivered to one user’s hacked MikroTik. I don’t know for certain that this is the same “7wmp0b4s.rsc” that had an attempted delivery to my machine, and based on the Sophos report, it appears there may be different versions of the file.

Domains

I couldn’t wrap this up without at least looking at the domains used to host the .rsc file.

Each of these were created on the same day within an hour of each other, and though they used different domain registrars, they all use Cloudflare. None of them resolve for me at the time of this writing, though I’m sure I’ll have more samples over the coming months. Maybe they’re geofenced? I don’t know. Anyway. That’s that, I guess.

Some final thoughts

Perhaps this was a bit anticlimactic, but it’s important to illustrate the research process, even when results aren’t groundbreaking. I enjoy understanding how others approach problems, so I wanted to share my approach to this little puzzle. And anyway, I learned more about RouterOS than I’d known before researching these honeypot input strings, and also what an .rsc file is. Hopefully you at least found this interesting or maybe learned something, too!

Security engineer with a running problem.