Ransomware: Is it time to take keyboards away from production?

It is 4:45pm on a Friday and the phone rings:

“Hello?”

“Is this the head office of the CEO of the MegaBank?”

“Who is this?

“I need to talk to the CEO, now. It is a matter of life and death.”

“Sure, it is.” Hangs up.

5 minutes later, the phone runs again.

“Hello?”

“I am calling from the law firm of Grab’em, Screw’em, and Run. We have a cease and desist all commerce order for your company on behalf of our client.”

“One moment, I will transfer you.”

This is how it starts. After checking that the company information is legitimate, a Ransomware actor attempts to contact either the executive committee, senior management, a member of the board, or the company’s legal department. The purpose: to extort money from the company in advance of a Ransomware attack. What will come next is a conversation involving clear proof that the racketeer can do what they claim, with valid, already tested credentials, and can damage the company’s reputation or damage its infrastructure in some crucial way before it happens.

This is the new face of Ransomware. Not malware already installed, although that may be part of it, but the threat of fiscal injury. This has been going on a long time – remember Al Capone? Same formula, different technology. At this stage, the Board of Directors invokes their risk assessment and mitigation plan to determine whether the threat is credible, which it likely is.

Foreground

The nature of Ransomware has evolved over the past few years. Malware is no longer the primary method of infiltrating organizations. Instead, Ransomware actors are working through a wide variety of phishing scams, including emails, spoofed websites, fake DNS pointers, and others, all designed to convince your staff that the scams are from an internal subsystem that have a legitimate right to ask for their identity, passwords, and other critical credentials.

As they get further into your organization, eventually they will come across operations staff who have access to user ids like SUPER.SUPER with VPN access. Malware is still in play, but more as a mechanism to gain access to resources rather than to encrypt hard disks – NonStop is fortunately fairly well hardened from direct encryption attacks, but there are both subtle and glaring approaches that I will not discuss here for data and system corruption.

On the downside, applications running on NonStop, by the very nature of the reputation of the platform, and the applications running on it, are increasingly high-value targets for bad actors.

Exploiting Bad Practices

In the Ransomware world, a core bad practice is to trust anyone. Well, that is not a fair characterization. You cannot trust that anyone is who they say they are at a login prompt because their credentials may have been compromised. And as we all know, if you have SUPER.SUPER, you have the keys to the corporation. It does not take long to reconfigure and break critical systems if you have those keys.

Another bad practice is to have unapproved deployments of code, scripts, or commands executing in production systems. The key reason for this is that by the time you have detected a breach in a log somewhere, the damage is already done, and it may be too late to save your organization.

The third bad practice is to assume you can save your system by depending entirely on logs. Access logs and keystroke logging are fine if you are trying to find out the compromised identity  of the user who did something bad (not necessarily the actual person), but by the time the keystrokes are logged, it could very likely be too late. Preventing malicious commands from being used in the first place is more important and urgent defence strategy.

The last bad practice described here – there are more, of course – is to compile and deploy directly from workstations. I was astonished and dismayed to hear at NonStop TBC 2023 that some organizations actually advocate using the NSDEE deploy function to move code built in ECLIPSE directly to production environments. This is fundamentally dangerous for many reasons including the potential presence of malware, which has infected your x86 workstation, can be designed to migrate over to your x86 NonStop with few or no changes at all.

Countering Attacks

While there are no guarantees that you will stop all forms of attack in the future, there are some practices and techniques that can make you more resilient to being threatened by bad actors.

First, use a club on your steering wheel. Sure, this is not exactly a Ransomware solution, but so many cars are being stolen by hacking FOBs and electronics that visible deterrents can help, particularly for some vehicle manufacturers. But the idea of deterrents is important for fighting back against racketeers. In this case, an important set of deterrents is the removal of the obvious access points, those being anything resembling login prompts.

If you remove the ability to log in, you remove the primary target of social engineering attacks, which are currently designed to obtain your credentials, a.k.a., your user id and password. Turn off keyboard-authentication for your SSH access points. GitHub did this last year for programmatic access and pushing changes to git repositories. When the scammers call your board of directors and tell them that they are logged into the system right now, you can tell them that you do not have a way for them to log in. It is a start anyway.

The next technique is to lock down critical subsystems that can be used to do damage. Programs like SCF, BRCOM, MEDIACOM, TMFCOM should not be accessible except in emergencies. Obviously, there are others, but no one should be able to modify your TMF configuration on a whim.

Now that NonStop runs on x86 Xeon processors you can, and should, virus and malware scan your programs before deploying them. See my NonStop TBC 2023 presentation for details on how to do that.

Mostly, it is important to take away keyboards from your production staff. This will ensure that even if someone manages to obtain their credentials, no damaging action could be taken. This would work by establishing a location where commands could be entered and then reviewed and approved by independent observers. Only following approval would an automated system execute the command.

There is a small cultural change management issue involve as the production staff are probably going to push back on having their keyboard access taken away, but they still should be able to get onto the system with escalated credentials (SUPER.BOB, for example) in an emergency. But that requires the use of the automated command review system to enable those users.

Summary

The key point is that if you make social engineering attacks ineffective, Ransomware actors cannot steel your car, I mean company. Their threats will fall on deaf ears and scams that are designed to extorting money will not work, at least until they figure out new attack vectors. A practical mechanism that exists to make such attacks less effective is to remove the ability to do anything useful or harmful on the system even if they manage to somehow break through your security perimeter and procedures. And hopefully, they will not take your car either.