On the morning of Saturday, December 29, 2018, hundreds of thousands of American households were surprised to find that their daily newspaper was not going to be delivered as expected. For many, the Saturday edition did not arrive until Sunday. Why? The answer may be malware.

Not getting papers into the hands of paid subscribers is highly unusual in an industry that prides itself on delivering the news in a timely fashion in spite of all manner of obstacles. But Saturday seems to be a first: non-delivery due to malware, more specifically, an alleged ransomware attack in which Ryuk malware disrupted the production process at a company called Tribune Publishing.

While Tribune Publishing owns the Chicago Tribune and several other newspapers, it also does the print work for other leading newspapers, like the Los Angeles Times, which has a circulation of over 650,000 and is America’s fourth largest newspaper. Also affected was my newspaper, the San Diego Union Tribune, plus the West Coast editions of the Wall Street Journal and New York Times. Delivery of the South Florida Sun Sentinel was also impacted and some newspapers went to print with a few sections missing, notably the Chicago Tribune, Hartford Courant, and Baltimore Sun Times.

This article looks at the Ryuk ransomware that was reported to be the root of the problem, as well as possible motives, attack vectors, and security measures that organizations can take to defend against this type of threat. You can find additional background and security advice on ransomware attacks similar to this one in my 20-page white paper – Ransomware: An enterprise perspective – available here on WeLiveSecurity.com.

Ryuk run amok?

The ransomware known as Ryuk was first reported in early August, 2018 (it is detected by ESET endpoint protection as a variant of Win64/Filecoder.T). Later that month a detailed technical analysis of the malware appeared (hat tip to Check Point), and by the end of the month the US government had issued a Ryuk-specific threat intelligence briefing (.pdf file).

Ryuk was not seen as a particularly innovative piece of ransomware, and was not being used in high volume campaigns, but it caused considerable concern because of how well it was being deployed, at least in terms of the amount of Bitcoin extorted from victims (more than half a million dollars’ worth of extortion money was paid in the first few weeks). Whether or not Tribune Publishing paid a ransom is not known at the time this article was published.

And speaking of things “not known,” I should make it clear that I have no inside information about the Tribune Publishing incident. That the cause of the incident was Ryuk ransomware is something that “sources familiar with the matter” have stated, including a claim that files encrypted with the .ryk extension – used by Ryuk – had been seen. I am not aware of an official statement on the details of the incident, which has been called both a “computer virus attack” (San Diego Union Tribune) and “a foreign cyberattack” (Los Angeles Time).

I should also note that this has been a challenging subject for journalists to report because the structure of the newspaper business today is very complicated. As indicated earlier, the production problem seems to have been centered on the printing end of the publication process but it affected several newspapers that do not own that process. In that sense this was a “supply chain attack” and it led the Los Angeles Times and the San Diego Union Tribune to cite “sources familiar with the incident” even as many outside observers assumed that those newspaper offices were where the incident originated, even though – to the best of my knowledge – it did not.

Knowns and unknowns

Based on my limited knowledge of the incident I cannot say what the attackers had in mind with this attack. Ever since the headline-grabbing outbreaks of WannaCryptor (aka WannaCry) and NotPetya in 2017, the world has witnessed ransomware being used to cause disruption - as well as, or in conjunction with, its original purpose, to make money.

I am equally ignorant as to the identity of the attackers. The original Ryuk code analysis by Check Point demonstrated clear similarities with the Hermes malware (detected by ESET products as Win32/Filecoder.Hermes). There is evidence that Hermes was the work of the Lazarus Group, a threat actor group that has been associated with North Korea; but kudos to researchers at Check Point for qualifying the statement that “Ryuk attacks were the work of HERMES operators (Lazarus)” with this important caveat: “or an actor that has obtained the HERMES source code.”

What I do know is that Ryuk is only the latest in a string of ransomware campaigns that have targeted critical data in larger organizations. It is reasonable to suppose that criminals are looking for the ideal combination of deep pockets and deep pain in order to maximize the return on their efforts. For newspaper publishers, delaying delivery of papers full of time-sensitive ads to paying customers would certainly qualify as deep pain.

For the last two years, this search for pain points appears to have been part of the targeting strategy that guided the perpetrators of the SamSam ransomware attacks (for which two Iranian hackers were indicted last month). Thanks to Check Point we do know that Ryuk victims are a mixed bunch, including a medical research equipment company, law firms, and convenience store chains in the United States and beyond.

I also know that a lot of these ransomware incidents occurred because the organizations being victimized either failed to block phishing attacks, or failed to adequately secure remote access to systems. The latter attack vector – often referred to as RDP because they abuse the Remote Desktop Protocol – has been particularly fruitful for cybercriminals in the last 12 months (that is why I focused on RDP in the previously-mentioned white paper, Ransomware: An enterprise perspective).

To be clear, I am no fan of victim-blaming. Anyone hit with ransomware is a victim of a criminal act. To assert otherwise is a slippery slope that quickly leads to the ethically indefensible implication characterized by that repulsive phrase: “they were asking for it”. At the same time, I am a strong critic of organizations that cry “sophisticated nation state cyberattack” too soon or too loud, especially when it turns out that what hit them was not sophisticated, and not the work of a nation state.

Defensive measures

With all of that in mind, the remainder of this article is directed to those who have responsibility for cybersecurity in their organizations. The advice provided here, while by no means a complete guide to digital security, indicates what any responsible organization should be doing these days in order to protect its digital assets against malware intrusions via RDP, plus specific measures to protect against Ryuk and similar ransomware, such as Hermes.

When it comes to protecting internet connected assets that may offer criminals a path to system compromise there are three main steps:

1. Document the problem: Make sure that all of your organization’s internet-connected assets are known to the people who have been tasked to secure them. Have a process in place for ensuring that all new devices are included.
2. Limit exposed assets: Make sure that no digital assets are remotely accessible directly from the internet unless they have been approved for use in that manner and configured appropriately. Ask why access to the asset cannot be provided via VPN (Virtual Private Network). Disable RDP whenever it is not required (these articles show how on different versions of Microsoft Windows: Server 2016; Server 2008/R2; Windows 10; Windows 8; Windows 7; Windows XP).
3. Protect exposed assets: If you absolutely positively have to use RDP without a VPN, be sure that you do as many of the following as you can:
   1. Change the default admin password.
   2. Enforce password complexity (length, mix of characters, etc.).
   3. Set an account lockout threshold to lock remote access after consecutive failed attempts to log in. By setting your computer to lock an account for a period of time after a number of incorrect guesses, you will obstruct attackers who use automated password guessing tools (a "brute-force" attack). To set an account lockout policy in Windows:
      Go to Start-->Programs-->Administrative Tools-->Local Security Policy
      Under Account Policies-->Account Lockout Policies, set values for all three options, such as 3 invalid attempts with 3 minute lockout durations.
   4. Use Network Level Authentication to enhance RD Session Host server security by requiring that the user be authenticated to the RD Session Host server before a session is created.
   5. Change the default port listening for RDP away from port 3389 (but note that this is merely security by obscurity and should not be the only measure you take). Note that you should not do this unless you are familiar with the Windows Registry and TCP/IP. Be sure to backup the registry before modifying, and restart the system to activate the registry change. See this Microsoft article for further details.
   6. Restrict which public IP addresses can connect via RDP (this can be burdensome if remote users do not have static IP addresses, for example, when traveling or working from home).
   7. Use more than one authentication factor. There are three possibilities: things you know, like username and passwords; things you are, like fingerprint or voiceprint; something you have, like your phone, to which a onetime passcode a code can be sent.
      However, if using codes sent to phones as a second factor, avoid SMS codes because criminals have a history of defeating SMS-based authentication (as described in this article). There are good 2FA solutions that leverage the ubiquity of phones but not communicate via SMS (such as ESET Secure Authentication).
   8. Tighten up user permissions and rights. Disable files running from the AppData and LocalAppData folders. Block execution from the Temp subdirectory (part of the AppData tree by default). Block executable files running from the working directories of various decompression utilities (for example, WinZip or 7-Zip). Additionally, if you have a good endpoint protection product, you can create HIPS rules to allow only certain applications to run on the computer (and block all others by default).
   9. Password-protect your endpoint protection to prevent unauthenticated settings modification, disabling the protection or even uninstalling the product (but use a different password from the one used for the RDP login credentials).

The following anti-ransomware measures were published by the US Health Sector Cybersecurity Coordination Center (HC3) in response to Hermes malware, which has many similarities with Ryuk:

• Firewall off SMB (port 445) for internal computers. If access to this service is required, it should be permitted only for those IPs that require access (e.g. if 445 is required for SCOM to push an agent install, therefore 445 should only be allowed from that source server);
• Application blacklisting should be implemented to prevent the use of tools such as vssadmin.exe, cmd.exe, powershell.exe and similar;
• File Integrity Monitoring should be considered and configured to monitor file creations in “trusted” locations such as the System32 directory. This can also be used to monitor deletes, with an alert configured to fire on excessive deletes in a row;
• Windows Security Event logs should be monitored to capture Scheduled Task creation events – Event ID 4698;
• Registry Auditing should be enabled and monitored to capture any additions to HKLM\Software\Microsoft\Windows\CurrentVersion\Run;
• Excessive use of known administrative privilege accounts should be alerted on – specifically in a “one to many” behavioral configuration. i.e. is one specific IP connecting to a large number of devices using the same credentials in a short period of time;
• Ensure privileged accounts have a complex password that does not include any part of the username, or application it relates to.