Earlier this year, I arrived at the office on a Monday morning to a ringing telephone. One of my longtime customers was on the line, frantic about a security issue. When he arrived at work that morning, he discovered that the Microsoft Exchange server at his midsized company was offline and infected with ransomware. Further digging revealed that several other servers on the company’s network were similarly affected, and their desktops contained demands for a ransom, to be paid in cryptocurrency, for the key required to unlock the servers’ contents. The company needed help investigating the incident and restoring operations as quickly as possible.
CDW’s incident response team immediately got to work and helped uncover the cause of the incident. The team identified a Windows server on the network that had the Remote Desktop Protocol (RDP) exposed to the internet, allowing anyone to attempt an administrative connection to the server. Over the weekend, a system in the Netherlands had done just that, spending more than ten hours conducting a dictionary-based password attack against the server. The server logs showed an onslaught of unsuccessful login attempts that ended with a 30-second successful connection to the server.
That session was followed by a few minutes of silence before a new connection came in from Russia. The automated password guessing program had handed off control to a human attacker who quickly installed network discovery tools on the server, using them to conduct reconnaissance on the company’s network. Noticing that a domain administrator had logged on to one of the systems, the attacker then leveraged that account to gain control of the server and install Ryuk ransomware on several critical systems.
My client was fortunate. The company had a rigorous backup procedure, and all of these systems were routinely backed up to tape. We worked with them to restore the backups and get everything up and running without acquiescing to the ransom demand. An incident that could have been an unmitigated disaster was reduced to a disruptive nuisance.
As I reflect on this, I see three key lessons that we can draw from it that apply to almost any IT environment.
Lesson 1: Recover Before Considering a Ransom Demand
If you have a strong backup process, your best bet in the wake of a ransomware incident is to begin the recovery procedure quickly, without even contacting the attacker. Paying a ransom is risky, and it rewards bad behavior. That said, it’s important that you understand the root cause of the incident and correct it before beginning the recovery effort. In this case, a misconfigured firewall rule allowed the RDP connection that was exploited. We corrected that rule to prevent future compromises and then dove right into the recovery effort.
Lesson 2: Audit Your Firewall Rules
Misconfigured firewalls, like the one we found at the company’s site, are all too common. Firewall rule bases contain many complex rules, and I’ve never encountered one that didn’t have at least one error. Take the time to periodically review your firewall rules, and supplement these reviews with regular vulnerability scans. These controls will provide you with the opportunity to patch holes before they’re exploited by an attacker.
Lesson 3: Monitor Your Server Logs
Monitoring isn’t the most exciting task that cybersecurity professionals have, but automating monitoring can provide early warning of potential security incidents. In this case, server logs clearly showed the attack was underway 10 hours before it succeeded. An automated alert to system administrators would have provided them with ample opportunity to detect and correct the firewall misconfiguration before the attack succeeded.
Ransomware attacks can have a devastating effect on your business. Take the opportunity to learn from others who have experienced the effects of ransomware and reduce the likelihood and impact of a similar event in your organization.