We have reason to believe that the same kind of ransomware attack that we saw happen just a few weeks ago is coming to specific industries – namely road contractors, other state contractors and construction firms.

Here’s what went down, and why we believe we can stop you from being its next victim:

An MSP called us early in May asking if we could shore up the backup framework for one of its clients. Unfortunately, their client’s environment was in Azure and had already been hit by a ransomware attack – and it hadn’t had a second-copy backup. By the time we got the call, the client found itself with no choice but to pay the ransom.

The company that got attacked was a road contractor, which is an important detail here because recent patterns of threat actors like this is that they tend to attack multiple companies in the same industry over short periods of time. This means other similar contractors could be the next targets.

The ask of us in this matter? Deploy a secure backup solution and get a recreated copy of the client’s data back into that environment as quickly as possible.

However there were two issues that made this attack so bad. We still don’t know the exact details of how the threat actors got into the system. It will take a lot of after-the-fact forensics to determine that.

But the second problem was obvious: All the data was in the same location, so there was nothing that kept the attackers from getting to any backups that might have existed.

That’s not a best practice – and we do not recommend it. This was the first thing we addressed when we came in to develop the better backup structure.

Now, having said that, a lot of people make this mistake when they’re using Azure. Because Azure has servers in different geographic locations, people assume that their backup data on an Azure server in, say, Denver, will automatically keep it secure from an attack on their main server in, say, Detroit.

That is not true.

No matter how geographically spread out the servers are, Azure is all one system, and you must put guardrails around it.

The MSP didn’t design this, of course. They inherited it and found out too late just how vulnerable it was.

If anyone reading this works with another company in the same industry, we urge you to contact us so we can find out – and inform you – of two things:

1. Is there a vulnerability on your front end? (If we’d been involved at the outset with the company discussed above, we could have deployed our tech stack and our people to shore this up.)
2. Is there a secure backup setup to access a second copy of your data? It doesn’t take that long or cost that much to do this. But you have to.

If you’re a contractor that hasn’t been attacked yet, have your MSP contact us, please – or do it directly.

If a client comes to us and wants to review our architecture to make sure it complies with best practices, we show them everything. We want you to see it. If you go to the public cloud, they won’t.

So make sure your MSP knows if your data and your system are secure. Most hope, but they won’t know. With UBX, they’ll know.

Let’s make sure you have this kind of confidence.