A Close Call with Cryptolocker

Cryptolocker

We recently had an interesting run-in with Cryptolocker

We have a number of customers that run the pre-release version of our ProfitSystem software. We also use it in-house, it’s called “dogfooding“, where a company “eats it’s own dog food.” In return for testing the software, we help with their IT services.

This customers desktops are actually hosted on Server 2012 via Remote Desktop services. So, each user actually uses a thin client to connect to the server where they have their own desktop, documents folders, etc. This makes it very easy to update to new versions as there’s only installation to upgrade. We can also shadow user sessions to watch them use the software.

In the past they’ve had problems with users browsing Facebook, Instagram, Twitter, etc. on the server, and doing things like playing on-line Flash games. On a remote desktop server, lots of users running Flash will eat up a good portion of the CPU. Since all the users share the same remote desktop server, this slows everyone down. So, a few years ago we implemented Squid as a white-list proxy server for the users on the remote desktop server. This means that they can only access web sites on the approved list. It can be inconvenient at times, but since most everyone has a smart phone Facebook is never far off.

“The internet is broken”

One day they started reporting intermittent problems with internet access from the server.  Web sites that shouldn’t time out were. However, they weren’t seeing any problems from any other workstations, which are on the same network.  So the problem was only occurring on the remote desktop server.

One of the first things I checked was the Squid proxy.  Only the remote desktop server used the Squid proxy.  The log files were quite large, which is not unusual, so I stopped the server and cleared the logs.  I restarted the server and within a few seconds the log files had started to grow.  The odd thing was, I was checking on the server before the store was open, so there was almost no one there.  There would usually be some web access from the server (software auto-updates, etc.) but not as much as seemed to be occurring.

Within a few seconds the log files were over 1k, which seems much too large.  I opened the log file and saw the same 25 or so web sites repeated over and over.  An application on the server was trying to acess these sites and download .tgz file, .zip files, etc.

“Uh-oh…”

Going back to the remote desktop server and viewing the running processes revealed two unknown programs.  I made note of the user they were running under and Googled their names and one came up as a trojan used to deliver Cryptolocker (horror!).  I terminated the two programs and ran an malware scan on the server.  It found the same trojan had been downloaded and saved to the temporary internet files folder for the same user.  I cleaned it up as well.

“They wouldn’t phish if it didn’t work”

At this point, it was clear that the user in question had received an phishing email with the trojan as an attachment.  The trojan had been run and was trying to contact it’s download servers to receive its payload.  However, since the download servers were not on our white-list, they were being blocked and the trojan was trying over and over to contact it’s server.  I assume that it was bogging down Squid and that’s what caused the intermittent web access issues.

Epilogue

Had Cryptolocker actually run, it would have encrypted only that users files which would have been bad, but not catastrophic.  Each user can only access their own files, even though they’re all on the same server.  They also perform nightly offsite backups with 30 days retention, so we should have been able to recover that users files if they’d been encrypted.

Due to the user security on the server, the trojan was unable to install itself to survive termination.  All the users on the server run with limited permissions, so if the trojan tried to install itself to  HKCU\Software\Microsoft\Windows\CurrentVersion\Run, or any other sensitive registry keys it would have failed.

We did have Symantec Endpoint Hosted Protection active on the server.  Surprisingly, it did not detect the initial trojan download.  We’re looking into this as we would expect it to block the trojan.

With 30+ users on one server, it’s not surprising that the phishing attack worked on one of them.  We’ve reiterated to the users that they shouldn’t open any attachments unless they expected to receive a file from someone they know.  We’ll also be making sure Endpoint Protection functioning correctly going forward.

Minimize your vulnerability

• Users should run with limited permissions
• Malware protection updated and working
• Good offsite backup with at least the last few versions of files
• Whitelist access to web sites.  This isn’t practical for all environments, but it does help.