The creativity of some hackers and malicious actors is just amazing. There is a new bit of malware out there now that highlights some new approaches that I think we’ll start to see more of, and at the same time, incorporates SQL Server, which (at least since some infamous older issues) hasn’t been the specific key component of issues for a while now.
If you’re not familiar, this isn’t exploiting a SQL Server issue, it’s using the known traffic associated with SQL Server to “ride” around the network controls that are in place at many/most places of business. The operation of the malware is such that, when it phones home for instructions, it’s actually doing it by connecting to a remote SQL Server – that way the traffic appears to be typical database query and response information, typical ports, all of that.
Here’s a summary of what’s going on.
There’s a bigger issue here, though. That’s the use of “typical” looking traffic to scoot malicious code past the entry-guards. Firewalls, application, firewalls, all of that.
We’re bound to see more of this – and it gets harder to capture and block or detect as you implement hybrid solutions too, particularly those that involve on-premise and off-premise resources. If you’re already passing through traffic that is on the right ports and the “right” looking packets and such, but NOT implementing other protective measures, you’ll become more and more vulnerable to this type of traffic hijacking.
With all of the major cloud providers, you can set up custom gateway-type configurations where your network is in a much more controlled conversation with the provider. It’s not necessarily the default configuration and it could mean too that you want to consider changing legit ports and access points so you can better manage what’s supposed to be happening, vs. what may be, or start, happening.
You may recall the early days of IM, or video or other chat systems or file servers and custom web servers… those used techniques where the port, the configuration, the flow of information tried to “look” like legit traffic while actually taking people to non-business sites. I remember the early days of IM, the applications would jump around ports and protocols until they found a way to connect. It was not a lot of fun to try to lock down.
Be thinking about defining and controlling “legitimate” traffic on your networks. Be thinking about what that looks like – and how you can define it based on (for example):
– endpoints (what should be talking to what, over what path)
– protocols
– ports
– encryption vs. clear-text
…and pretty much anything else you can use to define legitimate conversations vs. something that doesn’t seem right. Get the tools, and the configuration abilities, that support these types of control. They do exist, they may (will) take more planning and more implementation and management as things change for your company, but it’s a sure-bet that this is something that you’ll be glad you took on.
