The Threat Landscape
In the fast-paced world of information technology, it’s easy to get caught up in the latest firewall tech, encryption, security information and event management (SIEM) tools, and the plethora of technical controls we use to prevent malicious activity on our networks. Often, we forget that there's more to securing a network than investing a big chunk of the annual budget into a panacea-like technology that will supposedly solve all our problems. Sure, technology is one piece of the picture. But it takes just one dropped guard to open the door for an attacker and to render all those investments null.
Phishing, or sending out emails in order to entice users to reveal sensitive information, is one of several tools in an attacker’s bag. Phishing has been around for a while, and we are routinely reminded to keep our eyes open. Yet, in spite of all the training and the internal phishing tests information security teams send out, people still make mistakes. A lot them, in fact.
An analysis of the threat landscape conducted by the SANS Institute showed that in nearly half of the instances in which an email with a malicious payload enters a network, a user launches it with an unsuspecting click. Phishing can be a successful strategy because its underlying principles are fundamental to human interaction. Various ploys use urgency, authority, or intimidation to persuade targets to unknowingly – or even knowingly – let their guards down.
Macro Potential
Phishing and social engineering pit our responses against us. That is, we are conditioned to trust and open friendly- or familiar-looking files. The only technical challenges for attackers involve putting together a good-looking email, post, website, or document with which to lure victims. For example, do either of these look familiar to you?
Source: Crowe analyst screen shots
Using fabricated documents with “compatibility issues” to get a user to enable seemingly innocuous features before they can view the content is a common social engineering ploy. Unfortunately, the “Security Warning” header is not the warning that users might expect.These documents have hidden macros waiting for an unsuspecting user to enable the content to subsequently compromise their machine.
These types of attacks have been around since the late 1990s and, while declining, they are clearly not going away, as the examples above demonstrate. Macro-based attacks provide an easy method of entry for an attacker for a number of reasons. First, they are relatively easy to code. The Microsoft Visual Basic™ language used to develop these tools is a high-level language, but one that is easy to understand. Second, a well-crafted, legitimate-looking document can fool the unprepared user. For example, note how the familiar-looking yet fraudulent document manipulates user trust in the example above. Macros can also be written or obfuscated in a way that bypasses traditional antivirus software. It’s easy to see why macros are a useful attack vector.
Creating malicious programs that can compromise hosts if their macros are executed is not difficult. Success varies depending on the ploy they are coupled with, but a few important challenges with macros exist that can have an impact on the success rate of an attack. The first challenge is the business need for a macro. Users who spend a lot of time crunching data in Microsoft Excel™ spreadsheet software can attest to this need. Reliance on macros makes it difficult to completely disable them quickly to reduce attack surface. The second challenge with the success of macros is poor deployments of macro security measures. Fortunately, Microsoft has continued to make improvements in the area of macro restriction.
The Recommendation
One solution for addressing macro-based threats is to engage a third party to test your system’s security. As part of the social engineering and phishing tests performed for clients, penetration testers and red teams can use a number of different ploys and approaches in an attempt to gain access to systems or information. One of these ploys includes sending macro-enabled documents to execute remote codes.
Although users ultimately must decide what is right for their organizations, they should also consider a few key points. First, organizations can help protect themselves from macro-related threats through education and nontechnical measures. Awareness training, or making sure your users address document-based threats in your programs, is one measure. Not all attacks come from unrecognized file types or hyperlinks. If your company does not regularly use macros, your information security teams should communicate to employees that macro-enabled documents are more than likely to have originated outside the organization and then explain the related risks associated with executing them.
Second, if yours is a smaller organization that does not use or need macros, the best practice is to disable them altogether. Microsoft makes this an easy process. Macro security settings can be centrally configured and managed via the Group Policy template. Each version of Microsoft Office has its own Office Resource Kit that contains the policy templates for editing macro settings, among other things. Macro-related policies are contained within the Trust Center section of the Group Policy template, found in the 2016 version of Office by navigating to User Configuration > Administrative Templates > Classic Administrative Templates > Microsoft Word 2016 > Word Options > Security > Trust Center within the Group Policy snap-in. The Trust Center also provides a few options for locking down macros. Administrators should inspect the VBA Macro Notification Setting in which they can disable macros.
These preventive steps may not be realistic for larger organizations with users who require these tools. Options still exist for restricting macros, but because each organization has different needs and structure, one "best solution" doesn't work for all.
When macros are necessary to an organization’s business functions, a good strategy is to use basic whitelisting to restrict macro execution. Microsoft Office 2013 introduced a feature called Trusted Locations, a form of whitelisting that allows organizations to restrict macro execution only to files residing in specific network locations or from certain publishers. Office 2016 enhanced the feature by enabling it to block macros from running Office files downloaded from the internet. Organizations should consider using these features to limit the harm externally provided macros can cause.
A second approach that can be used in conjunction with whitelisting relies on Microsoft Active Directory™ (AD) databases and a well-designed, role-based organizational unit (OU) structure to enhance existing layers of security. As an example, let’s assume a situation in which all departments have their OUs in AD but only users in one department within an OU should be using macros. To provide the greatest level of protection, it makes sense to completely disable all macros for every employee except for those in that specific department. Using Group Policy, you can implement policies that restrict macros to all employees except for the subsets who require it. This can be done by linking Group Policy objects to an OU or blocking inheritance of a Group Policy object to a specific OU to create role-based whitelisting.
If your organization is considering a broader whitelisting approach, several solutions can help your organization tackle its macro security needs. Microsoft AppLocker™ is a built-in tool (a replacement for the Software Restriction Policies feature) that provides application whitelisting capabilities based on location, publisher, hash, or type of file.
Be Prepared
Steps that organizations can take to protect themselves against phishing and macro attacks include assessing whether or not macros are essential to business functions, disabling macros whenever possible, whitelisting employees or departments that require macros, and educating employees about best practices when confronted by seemingly innocuous files. Being prepared is the best defense against malicious macros.
Microsoft, Visual Basic, Excel, Active Directory, and AppLocker are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.