True Support Tales: All Roads Lead To Ransomware

There, was that headline sensational enough to bring you to this blog?

Apologies for the click bait, but the headline isn’t necessarily wrong. The theme today: What starts as a seemingly innocuous alert can be just the tip of the iceberg, with a deep sea of more serious consequences waiting at the bottom. For good reason, ransomware steals all the headlines these days, but these cautionary tales remind us that we sometimes need to sweat the small stuff before it can snowball into something more.

Let’s take a look at a few recent events, as seen from our proactive support team’s point of view.

Leaving SMB Open To The World

The Server Message Block (SMB) protocol over port 445 is commonly used to share local files, and can also share access to printers, serial ports, and network data. Unfortunately, it is sometimes used to share files across the public internet. It is a fairly common practice because there are a lot of business use cases for it, it’s convenient, and sometimes it’s the only answer. That said, it is far from security best practice.

Recently, one of our customer’s Outposts autonomously notified our team that an external resource had established a connection to their network over SMB port 445.

After notifying our customer and opening up a dialog on the issue, it turns out they frequently use the SMB protocol to interact with their cloud environment. Their existing procedure was to open the port, use the connection, then shut it again. Unfortunately, this time the user had simply forgotten to close the port when they were done, allowing potentially bad actors to create inbound connections to the internal network.

It’s a common first step in gaining a foothold in a target network, and can eventually lead to a ransomware incident.

Needless to say, what started out as a simple alert turned into top-level policy changes and the addition of additional checks and balances.

The Government’s Bandwidth For Sale

When installed on an endpoint, proxyware is software that allows outside networks to utilize the endpoint’s internet connection, much like a traditional proxy server. The owner of the endpoint can make a little money for sharing their connection, and the external user gets to lean on someone else’s IP address. It’s a win-win that’s great for streaming English Premier League matches for free, but not so great for everyone else using that connection.

We were first alerted when the Honeygain proxyware app performed a remote TLS handshake originating from one of our customers – a local Texas municipality. That let us know it was in use. Proxyware wasn’t forbidden on this network, but the alert was flagged as a “Potentially Unwanted Application”, or PUA. We reached out to the customer to let them know about the application, and they determined that one of their users was indeed profiting from providing external access to the city’s internet connection. Needless to say, it was not theirs to share, and the software was promptly removed.

There are many other reasons allowing proxyware isn’t a good idea: For example, proxyware can be used to monetize malware. By bundling the two together, bad actors can sell infected hosts’ bandwidth. It also might be used by attackers launching scans from your network. Threat actors use this type of application to obfuscate their identity, originating scans, probes, and exploits under “your name.” It’s a really good way to get your organization’s IP address blacklisted.

SocGholish Reveals Mixed Reactions

SocGholish is a popular form of malware that’s been triggering alerts across our client base for some time now, and its infiltration can lead directly to ransomware. But that’s not quite the story we want to tell here.

Once installed on an endpoint, SocGholish beacons out to a handful of specific domains. One of the ways we detect its presence is an alert when DNS requests are made for those domains. Not surprisingly, we see this a lot on public Wi-Fi networks, like a municipality’s City Hall or Public Library connection.

And when we notify our clients about these connections, something even more interesting happens:

Some simply don’t respond. The last thing they’re worried about is a random phone or laptop connected to their free public wi-fi network. They’re confident the public wi-fi is well segmented from their internal LAN and the other critical assets on their network, and they’re strapped enough for time as it is. We understand.

Some want to know, but may or may not take action. The same reasoning applies to this lack of enthusiasm; The network might be a public wi-fi segregated from anything they consider important, but they still want to stay informed and potentially act when required.

Finally, some act, and act quickly. While it might not pose an immediate threat to their critical network assets, they realize that someone beaconing out from their network, much like with Honeygain, could land their IP in a lot of trouble. Once notified, this third group typically blocks the guilty party’s MAC address on the wireless access point so they can no longer access the network with that device. It’s a good way to ensure their good name, and might spare a few more potential victims in the process.

Molehills Into Mountains

Evaluating these alerts in isolation, they might seem somewhat innocuous. But hopefully these “True Support Tales” illustrate that sometimes even the simplest event really can be the tip of the iceberg.

‍