Unraveling a Reverse Shell with Managed EDR

We could take a note or two on what agility means from our adversaries, aka threat actors.

Something doesn’t work? Plan B is ready.

Password not cracking? Bruteforce it.

Dropped shell not proving to be fruitful? Reverse it.

We recently found a reverse shell on one of our partners’ systems, which included quite a bit of obfuscation and other sus activity that had us on the Huntress Security Operations Center (SOC) team shaking our heads. Let’s get right to it and talk about reverse shells.

What Is a Reverse Shell?

First things first: what is a reverse shell?

There are plenty of legitimate ways that a sysadmin may connect their admin machine to another computer: SSH, RDP, PowerShell remoting. These methods of gaining a shell are legitimate and a part of necessary administration.

Reverse shells, on the other hand, belong in the nefarious adversarial arsenal of the threat actor.

A reverse shell inverts the intended methods of how one would legitimately gain access to a machine. In this situation, the victim machine is forced to reach out to the attacker’s machine and gift them a shell. For example, if an attacker exploits a vulnerable Apache Tomcat web server and can run commands via the exploit, they will instigate a reverse shell so they can run commands much smoother and easier.

From there, an attacker has a more reliable and convenient connection to carry out their campaign.

It’s the ultimate UNO reverse card in the cybersecurity world.

Finding and Analyzing the Payload

Malicious Process Behavior, our Managed EDR feature, initially tipped us off to this activity. We received an alert that an encoded PowerShell command was being run on one of our partner's computers:

We looked into the parent process to see what spawned this task and were horrified to discover that it was the partner’s ScreenConnect instance. This told us that the attacker had access to the ScreenConnect host. 💀

What’s especially horrifying about the prospect of an adversary controlling Remote Monitoring and Management (RMM) infrastructure is that they then may gain access to the thousands of other computers that are connected, allowing the adversary a quick and easy way to cause cascading damage across the network.

With no time to spare, we focused on the encoded payload.

We headed straight over to CyberChef so we could see what was actually happening with this script. The decoded Base64 text was unscrambled to this simple (but daunting) one-liner:

You can interact with this payload yourself in CyberChef.

Breaking this down a bit, the command is using PowerShell's [.highlight]Invoke-WebRequest[.highlight] (IWR for short) method, which sends HTTP and HTTPS requests to [.highlight]hxxps[://]onerecovery[.]click.[.highlight] It then parses the response and returns collections of links, images and other significant HTML elements—which looked seemingly normal at first.

If you look at the website with a tool like urlscan.io, all you’d see is "loading..." and the source from the site doesn't show anything interesting either.

A lot of people may see this and assume that the threat actor’s staging domain is defunct and no longer poses a threat.

However, we in the Huntress SOC are a curious bunch, so we wanted to be sure we covered our bases.

When we try this from the command line via the [.highlight]wget[.highlight] command, we saw something a lil spicy. Attempting this in the command line allowed us to move past the Loading… message to see if anything was actually present on the site.

What we found was certainly 🌶️ enough to be considered Tums-worthy.

Honing in on the Reverse Shell

Let’s break this down.

We can see in this snippet that content was certainly returned, including a public IPv4 address ([.highlight]88[.]119[.]175[.]55[.highlight]), some PowerShell scripts and an SSH path.

That itself was definitely sus, so we pulled the rest of the script by using [.highlight]wget hxxps[://]onerecovery[.]click).rawcontent[.highlight]. It returned yet more ripping-hot spicy content. 🌶

I don’t want us to get too lost in the sauce on the specifics, so here's an overview of the above shady shenanigans:

A firewall rule allowing inbound SSH connections
Dropped the SSH executable in that folder
Persistence in the form of a scheduled task
A file called [.highlight]go.bat[.highlight], which was used to run the following batch script

We can briefly dwell on the batch script, which created the reverse shell listener back to the IP we saw in the original script—all while creating persistence in the form of a scheduled task to launch the SSH reverse shell listener so the attacker would always have access to it!?

Talk about insistent persistence.

If you want to take a little look-see at the PowerShell script, we’ve got your back.

Rejecting and Repudiating Reverse Shells

I know we just spent a while gushing about how cool malicious stuff is, but let’s get back to WORK. We don’t work for Bad Guy, Inc.

We have some specific defensive advice based on the findings of this investigation.

1. Ensure you have 2FA and strong credentials on your RMM.

And actually check. We can’t tell you the number of times that someone swears blind 2FA is implemented account-wide, only to discover there was an edge case for an account.

2. Monitor incoming (and outgoing!) network traffic for anomalous behavior.

Now, we know this is easier said than done. And you’ll have to make choices and tradeoffs when monitoring network traffic. Are you going to monitor DNS and ICMP traffic, which are both verbose and the former soon to be encrypted, but very sneaky protocols threat actors may use? Monitoring these will come with storage and processing costs.

3. Consider implementing an intrusion detection system/intrusion prevention system (IDS/IPS) to detect and prevent this type of behavior.

No matter how tough you make your perimeter, intrusion is inevitable. If the threat actor is gonna get in regardless, then deploying appropriate security controls will mean you catch, evict and recover rapidly.

4. Don’t download random things from the internet!

Most intrusions we see at Huntress start from adversaries leveraging SEO poisoning, spraying attachments in emails, or users just generally downloading some random stuff they have no business downloading. User education on appropriate cyber security hygiene is your best bet at defense here, and it’s something we’ll be helping you with real soon. 😉

***

We hope you enjoyed this technical unraveling of a threat. We see these kinds of things 24/7, and our team is devastatingly efficient at investigating, advising and then sharing our findings.

If you'd like to check out Huntress Managed EDR, you can start a free trial here!