Fight Windows ransomware with on-board tools

Negotiating Hurdles

Allowing Specific Software

Wouldn't it be far better to retain control and, above all, not let attacks happen in the first place? A number of strategies are at hand. Although not a popular approach, allowlisting and associated tools have been around since time immemorial:

  • XP, Service Pack 2, software restriction policies (aka SAFER)
  • Windows Vista, AppLocker (Enterprise, aka SAFER2)
  • Windows 10 1607, Device Guard
  • Windows 10 1709, Device Guard becomes Windows Defender Application Control (WDAC)
  • Patchday 30 September 2022: Every Professional version of Windows now supports AppLocker with Group Policy; it is no longer an Enterprise feature. Although you have always been able to set up AppLocker by mobile device management (MDM) in the Professional versions, the process has been quite unwieldy.

Blocking unknown software is certainly the sharpest sword in the defense arsenal, similar to completely blocking email attachments. In principle, only code known to the company can be executed. In other words, malicious code has to be very carefully crafted if it is to work. You might still have gaps in the rules, but if so, you should establish software allowlisting in the enterprise and maintain it as an ongoing process.

Understandably, administrators are reluctant to add this work to the usually huge zoo of custom applications. However, if you simplify the approach and declare only %programfiles% and %systemroot% to be secure, because these paths cannot be changed in the user context, you have already provided protection against most malware with just two rules. Of course, these actions will not protect against attackers with admin rights, but the first line of defense has to withstand most attacks. Users have no write permissions for these paths, with just a few exceptions that can also be regulated [2].

Restricting Access to Folders and PowerShell

Malware usually needs a location with write access to generate an executable or to save the script. Everything below %userprofile% and C:\Temp, both of which are easily accessible directories, is addressed. It is therefore important only to allow paths for execution to which a user does not have write access. In the phenomenon of "dummy folders," the Windows Explorer API does not distinguish between "C:\Windows" and "C:\Windows " (with a space at the end). However, code can be stored in "C:\Windows " and Explorer will think it is talking to C:\Windows. Annoyingly, Windows allows users (and therefore also attackers) to create a new directory directly below C:, which must be prevented at the NTFS level [3].

In addition to path rules, publisher certificates can be used to authorize software. Programs that do not have a certificate can be self-signed if necessary with your own code signing certificate and the Set-AuthenticodeSignature cmdlet. If you have a code-signing certificate, you can also use it to sign macros and PowerShell scripts that are allowed to run. Only allow certain paths for execution, and only trust a few certificates – this is a clear set of rules. Of course, you can go one better: You can target specific program versions or create hashes for individual files. Initially, however, a less granular, simpler set of rules should be established to allow the technology to be used.

PowerShell must also be regulated for users, because it is ultimately an admin tool. Among other things, it also allows code to be reloaded or executed without files [4].

Getting Started with AppLocker

One criticism of Microsoft's own product is the poor and sometimes painstaking administration; on the upside, it is available as an on-board tool and can be used directly. AppLocker (Figure 1) has a monitoring function that only logs events prior to enabling the feature. Monitoring needs to be combined with Windows event forwarding to collect the events of blocked applications in a central location. However, the idea that you can start AppLocker today and be ready to go after a few days is misguided.

Figure 1: AppLocker is Microsoft's (admittedly inconvenient) approach to allowing specific software.

Instead, you start monitoring and improving your set of rules, and once the errors stop, the system switches from monitoring to enforcing. Depending on the company and the test clients used, this process can take two weeks or two months. The important thing is for the IT department to get started. Third-party providers usually use intelligent agents on the clients that also support port blocking in addition to software allowlisting and better central management. In AppLocker's favor, however, is that you have no excuse not to start using it this very moment. Without question, a virus scanner or the Microsoft Defender attack surface reduction rules also need to be in place, but allowlisting is the most important part.

Unlocking software in a targeted way also shuts down two further vectors: unwanted software downloads and malware on websites. Software is often not downloaded directly from the manufacturer but by dubious portals that are likely to be at the top of the search engine list. The other goodies that end up on the computer from these sites is unknown. Another useful side effect of allowlisting is gaining control over the Microsoft Store; admins have been tearing their hair out over this repository for years. The answer is simple: Allow the Windows Store and use a publisher rule to control the apps. What is not permitted will simply not happen. It is sometimes irritating to see how companies refuse to use this technology because they are afraid of extra work and administrative overhead.

Before I forget, having a potentially unwanted application (PUA) or potentially unwanted program (PUP) also means extensions in web browsers, which might have direct access to the form data of websites and therefore to password fields, bank details, and so on. Not every extension does only what you have downloaded it for. The three major browsers – Chrome, Edge, and Firefox – offer group policies to control extensions. A blocklist (* , everything) is implemented and only what is known is allowed. Conveniently, the extensions have unique identifiers which can be used to install extensions or allow them to be installed automatically.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=