Starting about a week ago, PowerWare ransomware
began to propagate in email campaigns using Word documents laced with
macros. PowerWare works by launching
cmd.exe via macros contained within the infected Microsoft Word document. The resulting cmd.exe process in turn calls
PowerShell to perform encryption of the files.
PowerWare is a “fileless” malware variant so
protection technologies that rely on file signatures or static attributes of
executable files have difficulty protecting against this threat. In the case of PowerWare, opening a Word
document and enabling macros can lead to your files being encrypted and held
for ransom by the attackers. This is decidedly bad for business!
Fortunately, Symantec Endpoint Protection (SEP)
customers can use some of the granular controls contained in our product to
protect against these types of threats. In particular, the Application
and Device Control feature of SEP can be used to provide much stronger
controls.
To protect against PowerWare and similar threats,
we created an Application and Device Control policy with two new rule sets to
protect against PowerWare and other similar malware that provides two major
safeguards. The resulting Application and Device Control policy is shown
below and the two new rule sets are outlined in red. The remainder of this document describes how
these new rule sets function and how they can be created. (More information on configuring Application and
Device Control policies can be found here.)
Preventing
Process Launch Attempts from Outlook, Word, etc.
In the first new rule set we created, we prevent
processes such as Microsoft Word, Excel, Outlook, etc. from launching cmd.exe
and/or powershell.exe directly from within these applications. Preventing
cmd.exe and powershell.exe from being directly launched by applications such as
Microsoft Word attacks the tactics exhibited by the malware. There are
extremely few, if any, valid business reasons to allow cmd.exe and
powershell.exe process launch activity from within Microsoft Word and the other
monitored applications. Hence, any
impacts to generic end user workstations should be noted in testing and handled
as exceptions.
The configuration of this rule set is shown in
the following images.
Prevent
Monitored Application from Tampering with Critical Executables
In the second new rule set we created, we prevent
the monitored Microsoft applications from being able to tamper with cmd.exe or
powershell.exe. This prevents future variants of the malware from simply
making a copy of cmd.exe or powershell.exe and then launching the copy of those
programs. While we have not seen this behavior exhibited so far, it does
not require much imagination to see that this would be a technique for
bypassing the previously discussed controls around process launches from within
the monitored applications.
The configuration of this rule set is shown in
the following images.
Lastly, Symantec provides a standard Application and
Device Control rule set as part of the default SEP installation to prevent
vulnerable Windows processes including Outlook, Excel, Word and others from
being able to write executable files to disk.
This rule set is named “Prevent vulnerable Windows processes from
writing code [AC17]”. By default,
this rule set is not enabled. However, enabling
this rule set can provide a strong additional control that may prove useful in
preventing endpoint compromise.
As threats evolve, so must our endpoint protection
solutions. Paying careful attention to
the tactics, techniques and procedures used by attackers and adjusting our
endpoint protection posture accordingly can greatly reduce risk for our
organizations. With the flexibility of
SEP and Symantec's multi-layered approach to protection, Symantec customers are well
positioned to adjust their protection strategy as the threats change.
