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 in ThreatOps shaking our heads. Let’s get right to it and talk about reverse shells.
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.
Process Insights, 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 Invoke-WebRequest (IWR for short) method, which sends HTTP and HTTPS requests to hxxps[://]onerecovery[.]click. 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 ThreatOps are a curious bunch, so we wanted to be sure we covered our bases.
When we try this from the command line via the wget 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.
Let’s break this down.
We can see in this snippet that content was certainly returned, including a public IPv4 address (88[.]119[.]175[.]55), some PowerShell scripts and an SSH path.
That itself was definitely sus, so we pulled the rest of the script by using (wget hxxps[://]onerecovery[.]click).rawcontent. 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:
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.
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.
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.
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.
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.
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 Process Insights, the Huntress feature that drove this investigation, click the banner below!