Malware from the '90s comes back into fashion

Today’s attackers are exploiting common weaknesses in organisations’ technical security configuration that were once considered a thing of the past.

There's a resurgence in targeting independent execution environments via the type of malware that was for the most part eliminated in the late ‘90s.

The Australian Cyber Security Centre’s (ACSC) latest threat report [pdf], published last week, outlined a case where the Australian Signals Directorate discovered that an adversary had gained initial access to a unnamed government agency network using malicious Microsoft Office macros.

Does anyone remember Melissa? 

This incredibly successful virus, released in 1999, was beautiful in its simplicity. When a user received a Microsoft Office file that contained the virus, the VBA code ran and emailed a copy of itself to the first 50 people in the user's address book.

In 1999, protecting against code running in these independent execution environments was seldom done, and the built-in controls in Microsoft Office weren’t much help.

Macro (VBA) code was either enabled or disabled, but a lot of people made use of VBA for real business functions, so turning it off was not an option. Microsoft's Office security did get better, though, providing granular controls with options for running only digitally signed code and preventing code from running operating system functions.

But fast forward to 2016, and according to the ACSC, these independent execution environments are again responsible for a significant number of successful attacks.

It seems the security industry has forgotten that there are hundreds of useful configuration settings within operating systems that can be used to prevent a lot of these attacks, without having to buy more technology to layer on top to detect it.

The ASD has a guide to Microsoft Office macro security to help organisations strike the right balance what’s needed for the business and what’s secure.

However, there are a lot more uncontrolled execution environments and threats within operating systems that could be listed, some of which have been around for years and are largely unprotected.

Take HTML applications, for example - self-contained applications written in HTML, Dynamic HTML and any number of allowed scripting languages.

An HTA can run outside the context of the Internet Explorer security model, therefore your IE lockdown won’t matter. Even if you’ve upgraded to Windows 10 with Microsoft Edge, IE is still installed for backwards compatibility, so legacy HTA exploits could still execute.

The question you need to ask is do you know whether you are vulnerable to these kinds of attack and how many of these uncontrolled execution environments are actually present in your standard operating environment.

For example, attackers use Adobe PDFs for remote exploitation on victims’ computers, where PDF documents arrive as email attachments, links from websites, etc. Attackers can embed .EXE files inside .PDF files, or include Flash programs that can do practically anything when executed.

Furthermore, most Windows systems have multiple scripting engines, such as JScript and CScript, as well as the all-powerful PowerShell. Even applications come with their own execution environments that can be used by attackers to run their exploit code, so you need to be aware of what you install on your systems, as well as what comes by default with the operating system.

Another little gem is that Microsoft’s .NET framework installs a C# compiler on your computer that could be leveraged by an attacker to build exploit code inside your organisation’s perimeter. An attacker then runs the C# compiler from a shell script or via a batch operation by simply calling the executable file, csc.exe.

As you can see, the list of possible attack vectors is troublingly long. It pays to know what you are installing on your desktop and seek expert advice as to how it could be exploited and what you should do to fix it.

Access control lists, application whitelisting and using policy to control what users have and have not got access to will go a long way, but sometimes you need to leave these aspects of systems vulnerable – it’s then that you need to consider monitoring as the only course of action.

Without fully understanding the nuances of all layers of the network, operating system and applications, you will always be vulnerable.