July 2021 - SecurIT360

Every day we see evidence of bad actors attacking various sized companies with ransomware. A commonly agreed upon defense mechanism that offers a good chance to recover your data without paying the ransom is a robust backup strategy. With federal entities considering the idea that victims paying the attackers ransom a crime, now is a great chance to get ahead of any possible criminal action to getting your firm back online. The strategy we outline here will help your organization build a resilient backup strategy for protection from ransomware or any other incident.

Attackers Are Going After Your Backups

We know without a doubt that attackers are going after primary datastores and servers to encrypt companies’ data, and as the business of ransomware evolves, these attack strategies continue to become more successful. According to Revil, targeting backups has become a key element in an attacker’s strategy, and they are focusing efforts on encrypting or neutralizing backups. If a company has tested backups that are resilient to attacks, there is a lower chance they will be forced to make ransomware payments.

Snapshots Are Not Backups

Snapshots are great, no way around it, for IT services and operations this may be one of the greatest tools since sliced bread. However, snapshots should not be considered a replacement of a solid backup strategy. Now, that is not to say that snapshots don’t have a place in a solid backup strategy. Snapshots are great if you need to restore from the past few hours; however, in some cases, we need to know our backups are safe and clean from previous days or even weeks. While snapshots can do this, it is not the most effect mechanism. Especially as we consider replication to multiple locations and offline, air-gapped backups.

It’s not just me saying this checkout what VMWare has to say on why snapshots are not backups.

3-2-1- Strategy

Backups are as simple as 3-2-1, right? This sounds very simplistic, and in reality, it is a simple plan; however, it can be hard to execute. The idea is simple. Create 3 copies of your backups, across 2 different media types, and at least one offsite backup. Let’s break this down to a real-world example to contextual this for practicality.

3 Backups might look like this at a high level. With backups to Disk, which could be a SAN, you have backups that are quickly accessible for most recovery needs. Backups to cloud gets the data offsite to another location. Backups to tape satisfies our two media types strategy. Of course, you can mix and match other medias, locations and methods but the idea to have a diverse strategy so you have options when you lose confidence or access to other backups.

Backup to Disk > Backup to Cloud > Backup to Tape

Test, Test, and Retest

Backups are only great when they work and are ready. Develop a strategy to regularly test your backups AND your process! Restoring a file, application, or server for a ticket or service issue, while technically is a test, for those of us with compliance requirements this generally does not satisfy our requirements. Testing regularly has a few advantages to help you when you need them.

1. You know your backups are available.

2. Your team knows how to restore from backups.

3. Your team knows where to find your backups.

4. You know how long it takes to recover.

If you have a large environment consider a sample testing method where you test your high risk systems every time, with a set of lower risk systems to go along.

Separately, you should test your disaster recovery plan either with a table top or actual execution of the plan including failover to recovery location or backups.

Feel free to contact us if you’d like to review and reinforce your backup strategy.

Sources:
https://blog.cyble.com/2021/07/03/uncensored-interview-with-revil-sodinokibi-ransomware-operators/
https://www.vmwareblog.org/snapshots-checkpoints-alone-arent-backups/
https://www.veeam.com/blog/321-backup-rule.html

On July 1st Microsoft issued a new advisory regarding the Windows Print Spooler Remote Code Execution vulnerability and has assigned it a new CVE: CVE-2021-34527

On July 6th Microsoft issued an emergency, out of band security update, to address the Windows Print Spooler Remote Code Execution vulnerability, dubbed PrintNightmare.

What is PrintNightmare?

There exists a critical vulnerability in the Windows Print Spooler, CVE-2021-34572 (previously identified as CVE-2021-1675), that researchers and the security community have been calling “PrintNightmare.”

This vulnerability could allow an attacker to perform privilege escalation, or remote code execution, which could result in a full domain compromise.

The vulnerability itself was thought to have been patched by Microsoft on June 8^th. They even considered it low severity. However, according to researchers it was not fully resolved in Microsoft’s patch release.

For details on the technical components of this vulnerability, see the resource section below.

Why is it making headlines?

As indicated by Kevin Beaumont @GossiTheDog, since releasing the June 8^th patch, researcher Zhiniang Peng tweeted out proof of concept exploit code, which was hosted on GitHub, that indicated privileged escalation and remote code execution are possible. The tweet was deleted shortly after posting it. However, the repository was forked before it was deleted. There are now several other PoC variants floating around GitHub.

This prompted Microsoft to modify their advisory on June 21^st, to include the correct impact: privilege escalation and remote code execution and increase the severity from low to critical. Microsoft has since released another advisory, on July 1st, related to the remote code execution vulnerability.

The PoC code is one reason for the headlines, the other reason is because of the scope of this vulnerability. The Windows Print Spooler is enabled by default on Windows 7, 10, and 11 as well as on Domain Controllers. Many servers also have the Print Spooler enabled.

What are the real-life implications?

As of right now, it’s believed the vulnerability is only possible post-authentication. Meaning, you must first have access to a valid account before you can exploit this.

As stated previously, there are two attack vectors:

Privilege escalation – this is a ‘local’ privilege escalation which means that a threat actor, who has accessed a machine on your network using even a low privileged user account could easily elevate their privileges to Administrator or SYSTEM on that same machine. This would be a full compromise of the affected machine.
Remote code execution – this means that a threat actor can exploit this vulnerability without having access to the targeted/vulnerable machine. This attack vector could be used to enable a threat actor to move, machine to machine, throughout the environment. This is commonly called lateral movement. This is often done by threat actors in order to find and gain access to high value targets such as Domain Controllers.

This is a very serious vulnerability, one that affects even patched versions of Windows 7, 10 and the insider build of Windows 11, Windows Server 2008, 2012, 2016 and 2019. By design it also affects Domain Controllers.

Exploitation of this vulnerability in an environment could result in full domain compromise.

Can this be patched?

At the time of posting this, the June 8^th patch is believed to not fully remediate this vulnerability. Your efforts are better spent on mitigation and detection.

As of July 6th, Microsoft now has an emergency out-of-band security patch for the PrintNightmare Remote Code Execution vulnerability. Unfortunately, just how well KB5005010 protects against both the RCE and LPE vulnerabilities is questionable. Additionally, according to researchers, the additional hardening measure to restrict printer driver installations to administrators only and signed drivers only (RestrictDriverInstallationToAdministrators registry value), appears to not be working as Microsoft intended. The key component here seems to be Point & Print. Even after patching if Point & Print is enabled, non-administrators may still be able to use an unsigned DLL to achieve Local Privilege Escalation.

How do I mitigate it?

There are a couple options for mitigation depending on your level of comfort with disrupting printing across your organization. Bear in mind, this is a double edge sword situation. Even though this is a very serious vulnerability, for many businesses, disabling printing may not be the best option. Printing, for many, is a core business process. On same note, some temporary interruption to business process while waiting for Microsoft to issue a hotfix could be very well worth it.

Option 1 – ACL Restriction

The first option is to restrict the ACL (access control list) on a specific windows folder to prevent the SYSTEM account from modifying its contents. For more details on this approach, see this blog post by TrueSec. The PowerShell code below, reproduced from the TrueSec blog post, will do just that:

$Path = “C:\Windows\System32\spool\drivers”

$Acl = Get-Acl $Path

$Ar = New-Object System.Security.AccessControl.FileSystemAccessRule(“System”, “Modify”, “ContainerInherit, ObjectInherit”, “None”, “Deny”)

$Acl.AddAccessRule($Ar)

Set-Acl $Path $Acl

Option 2 – Disable the Print Spooler Service

The other option is to stop and disable the Print Spooler service. To do this you can use the commands below:

Using The Command Line

net stop spooler && sc config spooler start=disabled

Using PowerShell

Stop-Service -Name Spooler -Force Set-Service -Name Spooler -StartupType Disabled

Alternatively, you can configure the Print Spooler with Group Policy found here:

Policies/Windows Settings/Security Settings/System Services/Print Spooler

Option 3 – Disable inbound remote printing through Group Policy

According to Microsoft, this policy will block the remote attack vector by preventing inbound remote printing operations. The system will no longer function as a print server, but local printing to a directly attached device will still be possible.

Configure Group Policy as follows:

Computer Configuration/Administrative Templates/Printers

Disable the “Allow Print Spooler to accept client connections” policy to block remote attacks.

You must restart the Print Spooler service for the group policy to take effect.

Additional hardening

Local privilege escalation is still possible under certain circumstances even with the Print Spooler service disabled thanks to Point and Print technology. The flow chart below, shared by @gentilkiwi, is a great illustration you can use to determine when the PrintNightmare vulnerability can be used.

To harden Point and Print make sure that warning and elevation prompts are shown for printer installs and updates. These are the default settings but verify or add the following registry modifications:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Printers\PointAndPrint

NoWarningNoElevationOnInstall = 0

UpdatePromptSettings = 0

Microsoft also recommends explicitly listing specific print servers which should be used by clients.

In additional to the UAC prompt settings above it may also be a worthwhile endeavor to restrict Point & Print further to only allow users to connect to specific print servers you trust. This can be done with Group Policy located here:

Computer Configuration\Policies\Administrative Templates\Printers: Point and Print Restrictions

How do I detect it?

Unfortunately, Windows machines do not have visibility into exploitation of this vulnerability by default. In order to monitor event logs to find possible exploitation you must have appropriate logging enabled.

Ensure that Microsoft-Windows-PrintService/Operational logging is enabled throughout your environment.

Jake Williams @MalwareJake recently shared a quick and easy way to enable this logging with PowerShell.

Once enabled, you want to monitor for entries to that log that contain error messages indicating a plug-in module failed to load.

Note, threat actors can avoid errors in this event log if they are able to package a legitimate DLL that the Print Spooler would normally use. In that case, errors would not be logged.

If you want to quickly search for exploitation attempts, you can try this code shared by Florian Roth @cyb3rops:

Get-WinEvent -LogName ‘Microsoft-Windows-PrintService/Admin’ | Select-String -InputObject {$_.message} -Pattern ‘The print spooler failed to load a plug-in module’

Quick note about copying and pasting code from the internet. Be sure you understand what this code does and how it will affect your system. Use at your own risk.

Lastly, check with your security vendors and MSPs regarding detection. The security community has banned together to help create and publicly distribute viable detection’s using things such as Sigma rules. Security vendors should do the same.

Florian Roth @cyb3rops, together with @KevTheHermit and @fuzzyf10w, have created some Sigma rules to detect these exploits and shared them with the public. Make sure your vendors and MSPs are working to be able to detect potential exploitation of this vulnerability.

Now what?

The best way to stay up-to-date on the latest with PrintNightmare is by following the twitter thread #PrintNightmare. Also, follow your security vendors blogs/alerts/notifications to learn more about what they are doing to detect and/or mitigate this and other news breaking vulnerabilities.

Resources

Updated July 2^nd, 2021 – Changed the CVE number and added information about Microsoft’s latest update

Updated July 6^th, 2021 – Including option 3, disable inbound remote printing through Group Policy

Updated July 6^th, 2021 – Added “Additional hardening” subsection

Updated July 7^th, 2021 – Added link to out of band Microsoft patch to address the PrintNightmare RCE

Updated July 13^th, 2021 – Updated Point and Print Registry setting in hardening section