What Is Ransomware?

Ransomware is a type of malware that encrypts the files on a user’s device or a network’s storage devices. To restore access to the encrypted files, the user must pay a “ransom” to the cybercriminals, typically through a tough-to-trace electronic payment method such as Bitcoin.

How Does Ransomware Spread?

Ransomware is most typically distributed through spam email attacks. The spam email will have an attachment disguised as a legitimate file or will include a URL link in the body of the email. If the former method is used, the ransomware program is activated as soon as the attachment is opened and within seconds, starts to encrypt files on the device. If the attack vector is a link, upon clicking it the user is taken to a web page where the ransomware is delivered to the device unbeknownst to the user. Additionally, cyber criminals may utilize existing exploits as seen in the recent WannaCry attack, which took advantage of a well-documented Windows vulnerability known as EternalBlue.

Reducing the Risk of Ransomware Impacting Your Business

Educate the weakest link. The vast majority of ransomware requires someone to take action to activate the payload. Educating employees about how to recognize and defend against cyber attacks is vital. Many attacks will use email and social engineering techniques to trick the employee into downloading malware or divulging their username and password. As such, training should focus on these common attack vectors. Exercises where employees are sent faux “phishing” emails are effective in coaching users to distinguish between a genuine supplier communication and a phishing email with the subject line “Invoice Attached – please open.”

Patch, patch, patch. Then patch again. Failing to implement a rigorous approach to patching known security vulnerabilities can leave an enterprise exposed. It’s relatively simple for cybercriminals to identify unpatched devices and software on an enterprise’s network, and once identified, to take advantage of known vulnerabilities.

Make it harder for the bad guys—have multiple layers of defense. Cybercriminals spend huge amounts of time and money developing ever-more sophisticated forms of advanced malware that are designed to bypass a company’s security defenses. Relying on a single layer of security against this evolving barrage is not best practice. Utilizing multiple security layers means that if one layer does not block an attack, you have additional overlays that can mitigate the threat. So, what layers of security defense does your company currently have in place? Do you have different security solutions to help mitigate risk during all stages of an attack? Are there current gaps in your security that malicious actors can exploit?

Real-World RansomWare attack that I worked on

I recently worked with a company that was affected by a ransomware attack.  They had everything taken out by the attack which affected 2,500 VMs and 50,000 users. It is suspected that the hackers got in with a phishing email and slowly worked their way around the network. Once they had Domain admin credentials, they started putting things in place to take out the company.  When the switch was flipped, and the ransom was demanded the company was dead in the water.  The hackers took out all documentation as well as all VMs.  They tried to take out the backups but were unable to as those were not on the same domain and they were not able to get credentials into that system. The restore process took several weeks but was successful.  It would have been impossible to restore if the backups had been compromised.  If you don’t read any further in this blog take this one thing away, make sure your backups are not on the same domain or use common credentials to access them.

Initially I was brought in to help with the restoration of the systems.  I had previously worked at highly secure organizations and was tasked with coming up with a plan to stop a pass-the-hash attack in the future as well as implementing Department of Defense (DoD) Security Technical Implementation Guides (STIGs).  If you are unfamiliar with these, I recommend looking into them. Some manufacturers are now including them in their products to help harden their systems out of the box.

Department of Defense (DoD) Security Technical Implementation Guides (STIGs)

The STIGs are mainly GPOs that you apply to your systems to put in place to harden your environment to help mitigate attacks from happening. The download for the STIG GPO templates used is at https://nvd.nist.gov/ncp/checklist/753/download/5356

New templates are released quarterly and for every new version of software.  For this company I downloaded the Q4 2019 templates and created the GPOs that they needed to protect their systems.  To implement these, you first need to create a blank GPO then import the settings into the GPO. You can see they break out the STIG based on OS and what role the Server has.

The GPOs I created for this company were:

 

These settings will most likely break some things as they are changing settings to the most secure option across your environment.  When this happens, you want to reverse that setting creating a new policy, and have it override the STIG policies.  This is done so it is easy to see what exceptions to the STIGs you have applied, and when new STIG policies are created you can easily import them and apply the fixes without having to recreate your exception policies.

This company uses Citrix and I put together a list of items to address to meet the DoD standards in their Citrix environments.

The DoD guidelines for Citrix hardening are as follows. 

The steps to harden your Citrix environment are as follows:

  • Install Certificates on all Delivery Controllers
    • These are required for all communication with storefront and NetScaler
    • Configure IIS and XML to use port 443
  • Change the VDA default registration port to 8888
  • Set windows firewall rule to allow port 8888 inbound on delivery controllers
  • No anonymous user logon
  • Disable CEIP
  • Set user rights assignments for allow log on locally to only be the XenApp/XenDesktop administrators group.

To configure the SSL Cipher Suite Order Group Policy setting manually, follow these steps:

  • At a command prompt, enter “”gpedit.msc””, and press “”Enter””. The Local Group Policy Editor is displayed.
  • Go to Computer Configuration >> Administrative Templates >> Network >> SSL Configuration Settings.
  • Under SSL Configuration Settings, select “”SSL Cipher Suite Order””.
  • In the SSL Cipher Suite Order pane, scroll to the bottom.
  • Follow the instructions that are labeled “”How to modify this setting””.”,C-81139r1_chk,”Enforcement is via FIPs encryption.

To verify, open the Registry Editor on the XenDesktop Controller and find the following key name: HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\DesktopServer

  • Verify the XmlServicesSslPort registry key exists with the correct value for SSL port. By default, it is set to “”443″”.
  • Verify XmlServicesEnableNonSsl is set to “”0″”.
  • Verify the corresponding registry value to ignore HTTPS traffic, XmlServicesEnableSsl, is not set to “”0″”.

If “”XmlServicesSslPort”” is not set to the desired port, this is a finding.

If “”XmlServicesEnableNonSsl”” is not set to “”0″”, this is a finding.

If XmlServicesEnableSsl is set to “”0″”, this is a finding.

To verify FIPS Cipher Suites used:

  • From the Group Policy Management Console, go to Computer Configuration >> Administrative Templates >> Networks >> SSL Configuration Settings.
  • Double-click SSL Cipher Suite Order and verify the “”Enabled”” option is checked.
  • Verify the correct Cipher Suites are listed in the correct order per current DoD guidelines.

In the past I have forgone installing IIS on the Delivery Controllers and applied the certificate to the IP address of the machine.  This was done due to IIS lockdown policies enforced that caused other issues, so it was best not to use IIS in this environment.  One downside to this method was it did cause issues when the IP is changed, and the certificates no longer work.

Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques

A Pass-the-Hash (PtH) attack uses a technique in which an attacker captures account logon credentials on one computer and then uses those captured credentials to authenticate to other computers over the network. A PtH attack is very similar in concept to a password theft attack, but it relies on stealing and reusing password hash values rather than the actual plaintext password. The password hash value, which is a one-way mathematical representation of a password, can be used directly as an authenticator to access services on behalf of the user through single sign-on (SSO) authentication.

The PtH technique allows an attacker who has compromised a single computer to gain access to connected computers, including domain controllers and other servers storing sensitive information. For this reason, mitigating the risk of PtH attacks and other similar credential theft attacks can significantly improve the security posture of an Active Directory environment. The PtH attack is one specific type of credential theft and reuse attack. While this document focuses on Windows operating systems, other operating systems are vulnerable to similar credential theft and reuse attacks.

How is a PtH attach performed?

 

Note: An attacker is limited to the logon credentials that they can obtain from the compromised computer. Accounts the attacker cannot harvest locally cannot be used in further attacks. If a Domain Admin account is never used for authentication to workstations, this account will not be available to an attacker that has compromised these workstations.

If local privileged accounts, such as the built-in local Administrator account, have the same password on the compromised computer as other computers on the network, the attacker can log on to those computers using the stolen password hashes. This can be done because NT password hashes are created using an unsalted MD4 algorithm, so they are identical on each computer. This allows the attacker to match the username and password hash required on network logons.

How-to implement a PtH defense and what I recommended to the example company above:

  • Create workstation admin accounts
    • Deny server admin and domain admin accounts from accessing workstations
      1. Deny access to this computer from the network
      2. Deny logon as a batch job
      3. Deny logon as a service
      4. Deny logon locally
      5. Deny logon through Remote Desktop
      6. Remove all non-admin accounts from local admins on workstations
  • Create Server admin accounts
    • Deny workstation admin, normal user and domain admin accounts from accessing servers
      1. Deny logon as a batch job
      2. Deny logon as a service
      3. Deny logon locally
      4. Deny logon through Remote Desktop
      5. Remove all non-admin accounts from local admins on servers
  • Create Domain admin accounts
    • Deny workstation admin, normal user and server admin accounts from accessing domain controllers
      1. Deny logon as a batch job
      2. Deny logon as a service
      3. Deny logon locally
      4. Deny logon through Remote Desktop (I have seen some companies take this one step further and didn’t allow domain admins to logon to domain controllers locally but with a server admin account then elevate to do anything once on it.)
  • Create Citrix admin accounts
    • These accounts will need limited AD creation abilities that are locked to specific OUs and only allow creating Machine accounts in the specified OUs. This is needed due to how Citrix PVS and MCS creates machines with the wizards.
    • Deny workstation admin, domain admin and server admin accounts from accessing Citrix backend and front-end systems
      1. Deny logon as a batch job
      2. Deny logon as a service
      3. Deny logon locally
      4. Deny logon through Remote Desktop
    • In the Citrix environment: Server, workstation and Domain admin accounts do not work as Citrix is isolated to its own eco system.
  • Deny any admin account from remote access
    • Limit NetScaler authentication policies to only allow non-admin accounts

 

Summary

Ransomware attacks are getting more and more prevalent.  There are many levels of how to mitigate an attack so be prepared to cover everything from user education, to hardening of systems. The more roadblocks you can put in the way the better protected you will be.  Microsoft has said don’t say when you are infected do this: they say prepare as you are already infected.

About the Author

Craig Harmel is the Technical Services Manager at X-Centric IT Solutions with over 20 years of experience designing and deploying solutions for clients of all sizes and business types.  He is a Citrix Certified Expert – Virtualization, Citrix User Group Leader and a member of the Citrix Partner Technical Expert Council (PTEC)