Implementing the ACSC Essential 8 Maturity Model. Mitigation Strategy 4: User Application Hardening

The Essential 8 Maturity Model is a set of baseline cyber security measures for Australian organisations developed by the Australian Cyber Security Centre (ACSC). This article forms part of our Essential 8 series and goes into detail on Mitigation Strategy 4: User Application Hardening. Read on to learn about how you can implement Mitigation Strategy 4: User Application Hardening for all Essential 8 Maturity Levels within your organisation.

What is User Application Hardening? Why is User Application Hardening important? Maturity Level 1: User Application Hardening Maturity Level 2: User Application Hardening Maturity Level 3: User Application Hardening Summarising User Application Hardening Where to Next?

What is User Application Hardening?

We have established that there are many business applications we use. Therefore, we have limited the number of business applications that can be used with Mitigation Strategy 1: Application Control and patched them with Mitigation Strategy 2: Patch Applications.

So, what does it mean to harden user applications? Unfortunately, not all applications are created equal, and not all are secure-by-design. With the speed of applications launching from top development houses and start-ups, it is common for security to become an afterthought. Therefore, some applications may be able to perform higher privileged tasks than what it was intended to do. Threat actors understand this and seek to exploit common applications with access to higher-level tasks enabling them to do more damage.

User application hardening applies least privileges principles to limit what common applications can do.

Why is User Application Hardening important?

Let’s think of our users again.

👩‍💼Business users

I have no idea what application hardening is
I didn’t even know applications could do that
I don’t know if my application has more privileges than needed
I just want to use applications for business purposes
Sometimes I will use applications for personal reasons
I am constantly browsing the internet or using applications through my browser
I download and open PDF files regularly
I use Microsoft Office suite daily
I see ads all the time, and sometimes I click on them if they are interesting to me
Sometimes my browser doesn’t let me do what I want, so I may change my settings
I have no idea what PowerShell, .NET, or event logs are

✅Risk managers

I want to manage the risk all applications pose to our organisation
I want to decrease the likelihood of it happening
I want to limit in the event something does happen

👩‍💻IT users

I don’t know which applications to harden. There are so many of them
I don’t want to be blamed by other teams for stopping them from doing work

😈Threat actors

I want to inject malicious code in any way I can
I know companies organisations use Microsoft office, PDFs and PowerShell regularly
I know companies still use outdated software because they can’t upgrade them

Maturity Level 1: User Application Hardening

Web browsers do not process Java from the internet.

Java is widely used in the enterprise. Over web browsers, Java applets could present users with a popup box, and upon clicking on the popup, they allow the execution of malicious code. This could provide threat actors with the same or higher-level access to systems as the user.

Most modern browsers, including Chrome, Firefox and Edge, know the risks associated with Java and have already disabled Java, so why are you still using it, especially Java, from the internet? Disable them from your web browsers today.

Since the only web browser that still has support for the Java Applet is Internet Explorer 11, and there is a requirement below not to allow Internet Explorer 11 to process content from the internet, it is a self-fulfilling requirement.

Web browsers do not process web advertisements from the internet.

Ads are everywhere. They target you, follow you, and try to get you to click and buy from them even after you have already purchased them!

Well, ads can be used by organisations but can also be used by threat actors maliciously posing to be a legitimate business that lets them hit a broad audience, sites, geographies, and operating systems at once. So malvertising can be dangerous and safer to be blocked.

I’ve blocked ads for years, and seeing them on other people’s computers is strange. We’ve got to be careful, however. Some websites make money from ads, so they want you to allow ads. I guess those users will have to find other sources of information.

Internet Explorer 11 does not process content from the internet.

Does anyone still use IE11? Unfortunately, some organisations do.

If you have web applications that require IE11, consider upgrading those or finding other solutions. On the other hand, there really is not much excuse to use IE11, especially since IE11 was marked end-of-life as of Jun 2022. It should be removed.

Use your Application Control solution to disable IE11.

Web browser security settings cannot be changed by users.

Don’t let users undo your excellent work. Best to manage these policies centrally by restricting users from changing web browser security settings.

Maturity Level 2: User Application Hardening

Microsoft Office is blocked from creating child processes.

In Mitigation Strategy 3: Configure Microsoft Macros, we have limited macros and want to stop Microsoft office from creating child processes. Microsoft Office is a trusted application, so its child processes are likely to be trusted. Bad actors know this, so they write macros and other creative things to create child processes to carry out malicious actions.

If your Microsoft Office Macros configurations are effective, this requirement limits the damage. Blocking Microsoft Office from creating child processes limits the execution of malicious child processes. Regular macros should not be creating child processes in the first place, so they should be blocked.

This forms part of Microsoft’s Attack Surface Reduction rules and can be implemented there.

Microsoft Office is blocked from creating executable content.

Should Microsoft Office be able to create executable content? I haven’t seen any real business reason for this. Threat actors, however, could use this as an attack vector. They can create and write executable content to disk, leaving the door open for them to come onto the system even after it has been rebooted.

Again, another of Microsoft’s Attack Surface Reduction rules.

Microsoft Office is blocked from injecting code into other processes.

Why Microsoft Office can inject code into other processes is beyond me. If you know anyone at Microsoft, please let us know. It would be good to chat with some product owners at Microsoft to find out why. Injecting code from one process to another is typically okay. However, if it is malicious, it can hide in other trusted processes to do damage. This rule applies to Word, Excel and PowerPoint.

Yet, another requirement implemented through Microsoft’s Attack Surface Reduction rules to limit exploitable behaviours.

Microsoft Office is configured to prevent activation of OLE packages.

Threat actors are truly creative! OLE, or object linking and embedding as the name suggests, allows you to link office and other applications together and embed items in your documents. Bad actors commonly use OLE embedding to deliver malicious Visual Basic or JavaScript in the document, which, when run, can result in the execution of malicious code.

Block OLE packages with Microsoft Attack Surface Reduction rules.

Microsoft Office security settings cannot be changed by users.

With all the efforts to protect users from unwittingly running malicious macros, OLE, child process and executable content, we should make sure these controls remain in place.

Manage Microsoft Office security settings centrally by implementing Group Policy Object Settings changes.

PDF software is blocked from creating child processes.

Aside from Microsoft Office, PDF files can also create child processes. PDF files are commonly used in business and are a common attack vector. Bad actors can embed payloads in a PDF file and, either by social engineering or other methods, then manage to get users to run the malicious code. I have never seen a business reason for this, and Microsoft data sees few legitimate reasons for PDFs requiring child processes.

Another Attack Surface Reduction rule introduced by Microsoft can be implemented there.

PDF software security settings cannot be changed by users.

As with Microsoft Office and web browser security settings, we should not allow users to undo policies created to protect our environment. If there is a legitimate business reason, it should be raised.

ACSC or vendor hardening guidance for web browsers, Microsoft Office and PDF software is implemented.

The ACSC understands web browsers, Microsoft Office and PDF software are the most common business applications. However, they also know they are highly exploitable on workstations. Hence the ACSC have put together hardening guidance, and to achieve Maturity Level 2, these must be implemented to reduce the risk.

See the ACSC’s hardening guidance for detailed guidance on implementation.

Blocked PowerShell script execution events are logged.

You can do anything with PowerShell. As the name suggests, it is a powerful shell. Knowing how to use PowerShell can help automate many tasks and deploy code to thousands of endpoints simultaneously. Unfortunately, they can also be misused, so like anything powerful. They should be logged.

Maturity Level 3: User Application Hardening

.NET Framework 3.5 (includes .NET 2.0 and 3.0) is disabled or removed.

.NET Framework 3.5 was released in 2007, it's now 2023, and the latest version is 4.8. Unfortunately, .Net Framework 3.5 is known for its lack of security functionality compared to newer versions and its linkages to PowerShell 2.0, which we will discuss later.

If you have not already and want to achieve Maturity Level 3, you will have to upgrade to a newer version and ensure your .NET applications are compatible with the latest version. However, Essential 8 knows there are companies out there still using .NET Framework 3.5, so they have added this requirement.

Applications are moving rapidly, and so are cyber criminals, so keeping your frameworks up to date can help reduce your attack surface.

Windows PowerShell 2.0 is disabled or removed.

PowerShell 2.0 is old and was integrated with Windows 7, XP, Vista and Windows Server 2003 and 2008. It saw the end of life in 2017 with the release of the Windows 10 fall creators update. Do you know what that means? No more patches. Newer PowerShell versions have security features making it harder to carry out exploits PowerShell 2.0 does not have. Last checked, the latest version is PowerShell 7.3.

Disable it or, better yet, remove it altogether. How? Use PowerShell to disable PowerShell.

PowerShell is configured to use Constrained Language Mode.

As we learned earlier, PowerShell is very powerful. However, only some-powerful features are needed to perform business tasks, so Microsoft created the constrained language mode. It limits what you can do with PowerShell enough to let you still perform routine PowerShell tasks. It would be worth checking to see if the complete list of language mode constraints would impact your admin operations.

You can turn them on with Microsoft Attack Surface Reduction rules if there is no impact.

Blocked PowerShell script execution events are centrally logged.

Like other Mitigation Strategies, a SIEM is required.

Ingest blocked PowerShell script execution events into your SIEM solution to have them logged centrally.

Event logs are protected from unauthorised modification and deletion.

Again, logs should always be protected. However, given that this requirement is consistent across Mitigation Strategies, it is a good idea to standardise how they are protected.

Event logs are monitored for signs of compromise and actioned when any signs of compromise are detected.

Make sure your logs are safe from compromise. If you need help or don’t have the capability in-house, our managed CyberOxide SOC has SOC analysts available to monitor your logs for any signs of compromise. Contact our team to find out how we can partner with your organisation.

Concluding User Application Hardening

User Applications can do more than we know and, therefore, must be restricted or hardened. Unfortunately, bad actors are aware of this and have openly exploited them. Subsequently, the ACSC has created what they deem as Essential hardening requirements for common user applications into this Mitigation Strategy.

This Mitigation Strategy prevents attacks by exploiting through malvertising, Java, Microsoft Office, PDF, and PowerShell.

Where to Next?

Harden your organisation’s Applications! Accelerate your Essential 8 program and reach out to a CyberOxide Specialist to help uplift and assess your Essential 8 Mitigation Strategy 4: User Application Hardening.

Continue learning about Essential 8 with our next article on Essential 8 Mitigation Strategy 5: Restrict Admin Privileges.