Essential Guide To Blocking Malware Without A Soc

THE ESSENTIAL GUIDE TO
Blocking Malware
Without a SOC
How to Sabotage Attack Chains and
Block Infections Before They Start
Table of Contents
3 Introduction
6 Part 1: Keeping malware off your endpoints
6 ... Making it more difficult for malware to be delivered
11 ... Making it more difficult for payloads to be retrieved
21 Part 2: Making endpoints dead ends for malware
21 ... Making it more difficult for malware to run
28 ... Making it harder for attackers to conduct post-exploitation activities
34 One last thing
35 How Barkly can help
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 2

Introduction
Embracing your role as

Malware-Saboteur-in-Residence
If you’re like others reading this guide, you may have found that your job as your
company’s malware slayer has gotten increasingly...complicated. Malware is changing,
constantly, and keeping up can be difficult, even for security experts.
To make sure we’re all up to speed, here’s a quick recap of current threat landscape in
a nutshell: Attacks are advancing rapidly; everyone from hospitals to local governments
to law firms, banks, and mom-and-pop shops is getting whacked; hacking tools have
become so commoditized a grandmother can use them; even the average spam campaign
is doing evasive things; ransomware is still everywhere; traditional solutions are failing;
and to top it off your users are still using passwords that got leaked in the 2012 LinkedIn
data breach (and in a dozen other mega breaches since).
Right. So what exactly do we do about all that? One option is to give into the futility.
To stock up on Bitcoin and cyber insurance. After all, a lot of people say infections are
inevitable. But where’s the fun in that? Besides, giving up isn’t your style. You’d rather
fight back, and that’s exactly what this guide is about.
If you’re tired of reacting to malware infections, here you’ll find tips for getting more
proactive. The key is understanding how modern attacks work, so you can lay the
groundwork for sabotaging them before they have the chance to do any damage.
3 truths about how today’s cyber criminals

operate, and 3 ways you can sabotage them
1 They are opportunists. They prefer going after low-hanging fruit and taking paths of
least resistance.
Your job as malware saboteur is to make the easy things difficult. This
guide will help you set up roadblocks on the paths most commonly used for
infection. Raising the barriers to entry even slightly can often be enough to
repel a large number of malware campaigns.

INTRODUCTION
2 They prefer using your tools to theirs. If you’ve been following along recent evolu-
tions in attack techniques, you may have noticed a common refrain — more and more
attacks are hijacking legitimate tools and applications and putting them to malicious
use. As a tactic, it makes sense. Why trip alarms with malicious executables when you
can use whitelisted programs to do your dirty work? This approach, which security ex-
perts refer to as “living off the land,” isn’t new, but whereas it was once used primarily
by advanced attackers, now it’s being used in more widespread campaigns.
Your job as malware saboteur is to take those tools away. By disabling

commonly abused tools or restricting their functionality you can create a
lot of dead ends for attackers. This guide will explain which tools are being
abused most often and how to take them out of the equation.
3 They conduct attacks in stages. Malware infections are rarely instantaneous. The
majority take place by chaining together a series of commands and functionality. The
reason many security solutions fail to identify infections until after the fact is because
they are built to inspect the individual links in the chain, only, and in many cases, the
individual links are legitimate tools and applications. Building a clever infection chain
can help an attacker evade detection, but it also carries risks. If any link in the chain is
disrupted, the attack will fail.
Your job as malware saboteur is to break infection chains at the

earliest possible opportunity. This guide will help you identify weak
points in the most common infection chains that are ripe for disrupting.
If you can accomplish these three tasks then you’ll raise the degree of difficulty for
attackers considerably. Think of it as the difference between reactively pulling weeds
vs. proactively making your environment an inhospitable place for weeds to grow and
survive in the first place.
Best of all, this approach doesn’t require a fully staffed security operations center (SOC)
or complex, enterprise-grade security technology to accomplish (though we’ll explain
throughout the guide how the right kind of technology can help).
Who this guide is for

While the information in this guide can be helpful for organizations of all sizes, it’s been
primarily written with mid-sized businesses in mind. These organizations often don’t
always have the benefit of dedicated security staff and the amount of resources large
enterprises have, but on the flip side, they also don’t have the burden of trying to secure a
sprawling, complex enterprise environment, either. They can be tighter with their controls
without having to accommodate for such a wide array of scenarios and exceptions.
More specifically, this guide is written for busy IT and security pros who prefer practical
quick wins and killing as many birds with as few stones as possible.

INTRODUCTION
What this guide will cover

In Part 1 of this guide, we’ll explain easy steps you can take to make it more difficult for
criminals to get malware onto your systems. The primary focus will be on preventing the
abuse of legitimate tools like email, Microsoft Office, and Remote Desktop Protocol (RDP)
to gain footholds on endpoints.
Then, in Part 2, we’ll shift the focus to steps you can take to make it harder for criminals
to accomplish their goals, even if they do gain initial access to an endpoint. Again, the
emphasis will be on preventing attackers from abusing powerful, legitimate tools and
applications already present on your systems.

PART 1
Keeping malware off your endpoints

For many reasons, your top priority should be making sure attackers don’t establish a
foothold on your systems in the first place. After all, the best way to avoid an infection is
to avoid being exposed.
Perimeter defenses such as firewalls and email filtering play a key role here, but don’t
forget the parts you and your users (for better or worse) have to play. It’s also important
to realize that in many attacks, malware delivery is actually broken up across multiple
stages, with initial email attachments often serving as downloaders that retrieve the
actual attack payloads in a subsequent step. That provides defenders with another
chance to sabotage the delivery before the payload touches the device.
CHAPTER 1:
Making it more difficult for malware

to be delivered
THIS CHAPTER AT A GLANCE
• The two most common ways companies are currently getting infected
with malware are via email and remote desktop protocol (RDP) access
• Securing email centers on email filtering and user awareness training
• Attackers have proven ways of getting past both, but don’t worry,
there’s still hope
• Securing RDP centers on restricting access and setting account

lockout policies
The two most common ways of getting infected

with malware
Malware can be delivered in any number of ways, but in keeping in line with our “more
birds, fewer stones” mantra, let’s focus on the most common delivery methods first.

PART 1 | CHAPTER 1: MAKING IT MORE DIFFICULT FOR MALWARE TO BE DELIVERED
While there are certainly companies out there getting infected via sophisticated spear-
phishing campaigns and zero-day exploits, there are many, many more getting infected
via more basic methods. Remember, the vast majority of malware campaigns are
launched indiscriminately and are aimed at picking off low-hanging fruit. When it comes
to preventing malware delivery, your first job should be making sure “low-hanging fruit”
isn’t referring to you.
To that end, here are two basic scenarios you should be well prepared to face:
• Infection via spam emails with malicious attachments
• Infection via malicious RDP access (brute-forced or via stolen credentials)
In fact, these are currently two of the most common ways malware is being distributed.
Take steps to prevent these two scenarios and you’ll already be well on your way to
reducing your risk and enjoying more peace and quiet on the malware front. Let’s take a
closer look at how to do that for each.
SECURING COMMON INFECTION VECTORS
Email
Considering email represents direct access to the most vulnerable part of your network
(your users), it’s no surprise it’s criminals’ preferred channel for distributing malware.
According to Verizon’s 2018 Data Breach Investigations Report, an astounding 92.4% of
malware was delivered via email. Compare that to 6.3% that was delivered via malicious
or compromised websites.
92.4% of malware was delivered via email in 2017.
— VERIZON 2018 DBIR
In addition, Symantec’s 2018 Internet Security Threat Report asserts that, of the malicious
emails the company observed in 2017, 88% utilized email attachments while only 12%
utilized malicious URLs. So attackers clearly don’t mind playing favorites. When it comes
to distributing malware, emails and, more specifically, email attachments are their
obvious go-to.
But what types of attachments are they using? According to Symantec, the most popular
file types are script files (.vbs and .js), followed by .exe’s, .jar files, and Microsoft Word
documents. Webpage files (.html, .htm), Windows script files (.wsf), PDFs, Excel files, and
.rtf files also make the cut.

Looking at that list, two things jump out. First, many

of these file types are malicious scripts. Attackers MOST COMMON TYPES OF
are increasingly relying on scripts rather than FILE ATTACHMENTS USED
traditional malicious binaries because they provide IN SPAM CAMPAIGNS:
rich functionality and are often more difficult for
traditional antivirus solutions to block. For that 1 .vbs (VBScript file)
reason, while it may not always be practical, one thing
to consider is restricting or disabling users’ ability to 2 .js (JavaScript file)
run scripts altogether.
3 .exe (executable)
Even if you can’t disable scripts at the endpoint
level, however, filtering them out at the email level 4 .jar (Java archive file)
is definitely something worth considering. In fact,
due to the risks script files pose, Google has added 5 .docx, .doc, .dot (Office docs)
many to its list of file types blocked in Gmail. Unless
your organization specifically requires otherwise, you 6 .html, .htm (webpage files)
would be well-suited following their lead and blocking
all of the following: 7 .wsf (Windows script file)
.ADE, .ADP, .BAT, .CHM, .CMD, .COM, .CPL, .DLL,
.DMG, .EXE, .HTA, .INS, .ISP, .JAR, .JS, .JSE, .LIB, .LNK, 8 .pdf
.MDE, .MSC, .MSI, .MSP, .MST, .NSH .PIF, .SCR, .SCT,
.SHB, .SYS, .VB, .VBE, .VBS, .VXD, .WSC, .WSF, .WSH 9 .xml (Excel file)
Second, many of the attachments on the Symantec 10 .rtf (rich text format file,
list are widely-used legitimate file types that often used by Office)
can’t be categorically blocked. That’s obviously a
strategic decision on the part of attackers, who know
their best chance of sneaking malicious code past
gateway filters is by smuggling it inside legitimate file types. While you likely won’t be
able to filter out all of these file types at the email level (Office files, especially), we’ll cover
additional actions you can take to prevent attackers from abusing them in Chapter 2.
Where user awareness training comes in

Training users to spot malicious emails and to avoid opening suspicious attachments
can be a good additional deterrent, but you have to operate under the assumption that
mistakes are going to be made and malicious attachments are going to be clicked.
In addition to using legitimate file types users are used to receiving over email, criminals
have also become increasingly effective at making it look like their emails are coming from
legitimate sources. In some cases, they’ve even been reported hijacking the email accounts
of previous victims and replying to existing email chains with booby-trapped attachments.
The good news is that, in many cases, opening an attachment doesn’t result in immediate,
full-blown compromise. The majority of email attachments will provide attackers with
some of the functionality they need, but not all of it. For that reason, the majority serve

as downloaders for the attack’s real payload. That means even if a malicious attachment
is opened, the game typically isn’t over yet. We’ll cover steps you can take to preemptively
sabotage the payload retrieval process in Chapter 2.
SECURING COMMON INFECTION VECTORS:
Remote Desktop Protocol (RDP)

While malicious email attachments may be responsible for triggering the lion’s share
of malware infections, they’re far from the only delivery option available to criminals. A
growing number of criminals have turned their attention to targeting another vulnerable
access point: Remote Desktop Protocol (RDP).
RDP was developed by Microsoft as a remote management tool particularly useful for
offsite admins. It is commonly exposed in internal networks for use in administration
and support, but when exposed to the wider Internet it can be a dangerous beacon for
attackers. Identifying servers with vulnerable RDP connections (port 3389 is default) has
been made incredibly easy thanks to scanning tools like Shodan and masscan. From
there, it’s simply a matter of applying brute-forcing tools like NLBrute to crack the RDP
account credentials, and attackers are in.
Alternatively, if attackers are feeling especially lazy they can simply head over to the
underground marketplace xDedic, where RDP access to a compromised server can cost
as little as $6.
RDP has become a favorite infection vector for ransomware criminals, in particular, with
the actors behind SamSam, CrySiS, LockCrypt, Shade, Apocalypse, and other variants all
getting in on the act. Of these, SamSam has generated the most attention, infecting such
high-profile targets as the City of Atlanta, electronic health records provider Allscripts,
the Colorado Department of Transportation, and others.
The good news is there are relatively simple steps you can take to make RDP off limits
to attackers:
• Restrict access behind firewalls and by using a RDP Gateway and/or VPNs
• Use strong passwords and two-factor authentication
• Limit users who can log in using RDP
• Implement an account lockout policy to help thwart brute force attacks
Taking these precautions is critical since attackers who gain access via RDP typically then
have a strong foothold on the machine with local admin privileges. Once initial access
has been established, attackers typically don’t waste time scouting out the network and
laying the groundwork for a large-scale infection.

Quick review: Your to-do list
COMMON INFECTION VECTORS PREVENTION
• Block commonly abused file types (.vbs, .js, .exe,

Email attachments .jar, .html, .htm, .wsf, .bat, .lnk, .zip, .7z, etc.)
• User awareness training
• Web filtering
Web (including URLs in emails) • Ad blocking
• Patch management
• Restrict access via firewalls, RDP gateway, VPNs

• Use strong passwords and 2FA
Remote Desktop Protocol (RDP)
• Limit users who can log in using RDP
• Set an account lockout policy

PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
CHAPTER 2:
Making it more difficult for payloads

to be retrieved
• The majority of malicious email attachments are downloaders designed

to retrieve the attack’s true payload
• Preventing that retrieval stops the attack short
• Retrieval is typically carried out by abusing legitimate applications or

scripting tools
• Disabling or restricting those legitimate resources from downloading

files from the Internet can help prevent payload retrieval
Now that we’ve covered a few basic steps toward making malware delivery more difficult,
let’s turn our attention back to the challenge of email attachments you can’t practically
filter out. What happens when a malicious attachment successfully makes its way into a
user’s inbox and that user gets fooled into opening it?
Well, it’s not game over yet. In the vast majority of cases, that attachment isn’t going
to do anything inherently malicious on its own. Its main role is to serve as a dropper
that retrieves the primary malware payload from a C2 server or compromised website.
Luckily, that means there’s still time to nip this attack in the bud.
Here’s a simple diagram to illustrate that point. It depicts one of the most common
infection scenarios — a spam email with a Word document attachment, weaponized with
a macro designed to launch PowerShell and download a malicious payload. As you can
see, there are multiple opportunities for disrupting the process, even after a user makes
the unfortunate mistake of opening the attachment.

The point is, malware infections aren’t single events, they’re chain reactions. Each link
represents an opportunity for you to break the chain.
In this chapter, we’ll look at specific ways you can disrupt the payload retrieval process by
taking away the tools and functionality attackers are used to abusing.
REMOVING PAYLOAD RETRIEVAL OPTIONS:
Abusing Microsoft Office

There are few legitimate applications attackers love abusing more than Microsoft Office
programs. Why? A couple of reasons...
1) Office files are almost universally accepted

Attackers are able to capitalize on the fact that using and sharing Office documents is
baked into most users’ day-to-day work. Rather than trying to trick users into downloading
suspicious executable files that many AV programs would block anyway, instead they can
deliver the types of familiar-looking documents, reports, invoices, spreadsheets, etc. that
users expect to receive at work.
2) Office files are easy to weaponize

Microsoft has gone to great lengths to build powerful capabilities into Office programs
designed to make them more useful. Unfortunately, those capabilities are just as attractive
to attackers as they are to users, and because Microsoft considers these capabilities as
features rather than vulnerabilities, the company has rarely issued patches or fixes in
response to abuse. Let’s take a look at some of the most commonly-abused capabilities.
How attackers abuse Microsoft Office to retrieve payloads

METHOD #1: MACROS
Macro abuse has been around for years, having experienced its first heyday back in the
late 1990s and early 2000s. Over the past few years, there’s been a major revival, with a
large percentage of spam campaigns utilizing Word documents and embedded macros
to download malware.
For attackers, part of the draw of macros is how simple they are to build and configure,
but they have their drawbacks, too. For one thing, macros are disabled by default, so
utilizing them requires tricking a user into enabling them.
Macros also don’t provide attackers with all the functionality they need to accomplish
their goals, so they’re typically used to send a request out to a command-and-control
server or compromised website to grab a second-stage payload.

WORD DOCUMENT USED IN A SMOKELOADER TROJAN CAMPAIGN IN DECEMBER 2017
Preventing macro abuse

Here are a few options for protecting your organization from macro malware, listed from
most to least demanding:
• Disable macros across the entire organization: While it might be a nat-

ural conclusion to jump to, simply disabling macros entirely isn’t always a
practical option. Some legitimate software and business processes rely on
macros for functionality.
• Whitelisting: What about only allowing authorized macros? Maybe. Macros

do have a signature format that can support allowing only digitally-signed
macros to run, but that’s difficult to maintain from an IT perspective, espe-
cially as an organization grows.
• Disable macros in certain scenarios: Microsoft ramped up macro protec-

tion in its Office 2016 suite, providing admins with more granular controls.
One helpful option is the ability to block macros in high-risk situations only,
such as when a user is attempting to enable macros in a document down-
loaded from the Internet.

METHOD #2: OBJECT LINKING AND EMBEDDING (OLE)

Microsoft developed OLE to give users the ability to link to and add data from other
applications inside Office documents, or even embed one type of document inside
another. Attackers haven’t been shy about abusing this capability, often using it to trick
users into inadvertently launching embedded scripts (typically Visual Basic or JavaScript)
that in turn download a second-stage payload.
Like macros, one downside from the attacker’s perspective is OLE-embedded objects
require user interaction. First, the user has to interact with the object (often disguised as
a file icon), then respond to a warning prompt by confirming that they do want to open it.
OLE-EMBEDDED OBJECTS ARE OFTEN DISGUISED AS FILE ICONS TO ENTICE A USER INTO CLICKING THEM.
— IMAGE SOURCE: HEALTHCARE IT NEWS
Preventing OLE abuse

If your organization doesn’t actively utilize OLE packages, you can prevent the activation
of them altogether by modifying the registry key HKCU\Software\Microsoft\Office\<Office
Version>\<Office application>\Security\PackagerPrompt and setting the value to 2. That
will prevent objects from executing, even when a user takes the bait and clicks them.
Consider that one less tool in the attacker’s toolkit, and one more way you’ve made their
lives slightly more difficult.

METHOD #3: DYNAMIC DATA EXCHANGE (DDE)

DDE is actually an older feature that was superseded by OLE, and it provided similar
capabilities by allowing Office programs to automatically load data from other Office
programs. Attackers latched onto that functionality, as well, abusing DDE to launch code
to the command line, instead.
Once again, the good news is DDE requires user interaction. When a user opens a
document with DDE fields they will receive a warning notifying them that the document
contains links that may refer to other files. To continue, the user then has to confirm that
they do want to update the document with data from the linked files.
WARNING PROMPT DISPLAYED WHEN USERS OPEN DOCUMENTS UTILIZING DDE
Preventing DDE abuse

The even better news is that, if your versions of Windows and Office are up-to-date, DDE
won’t be a problem (at least when it comes to Word documents). After an influx of attacks
brought mainstream attention to DDE abuse in late 2017, Microsoft initially responded
by saying it had no plans of removing the functionality because, as the company saw
it, DDE was working as it should. That decision was eventually reversed, however, and
the company officially removed DDE functionality from Word with Microsoft’s December
2017 Windows security update.
It’s important to note that DDE functionality does still remain active in Excel and Outlook,
however. To disable it, admins need to make the following registry changes to disable the
programs from updating automatic links at open:
To disable DDE in Excel:
[HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\OFFICE\<VERSION>\EXCEL\SECURITY]
WORKBOOKLINKWARNINGS(DWORD) = 2
Note: This will prevent Excel spreadsheets from updating dynamically, so it may not be a
practical mitigation for everyone.

To disable DDE in Outlook (Office 2010 and later versions):
[HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\OFFICE\<VERSION>\WORD\OPTIONS\WORDMAIL]
DONTUPDATELINKS(DWORD)=1
To disable DDE in Outlook (Office 2007):
[HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\OFFICE\12.0\WORD\OPTIONS\VPREF]
FNOCALCLINKSONOPEN_90_1(DWORD)=1
HOW BARKLY CAN HELP

If you’re wary of making registry changes, or if completely disabling these features isn’t feasible in your environment, Barkly can
help. Barkly detects and blocks the attempted launch of malicious programs, command lines, or scripting engines from Microsoft
Office programs. Plain and simple. Learn more.
METHOD #4: EXPLOITING EQUATION EDITOR

Microsoft Office Equation Editor (EQNEDT32.exe) is a legacy formula editor that began
giving the company headaches in late 2017. Details of a remote code execution vulnerability
affecting the program (CVE-2017-11882) were publicly disclosed in November, quickly
followed by reports of exploits being used by attackers in the wild. Microsoft fixed the
bug in its November 2017 security update, but after a second vulnerability (CVE-2018-
0802) was revealed in January, the company decided to remove Equation Editor for good.
Preventing Equation Editor abuse

Microsoft officially killed off Equation Editor in its January 2018 Windows security update.
Patched machines are immune to this avenue of infection.

REMOVING PAYLOAD RETRIEVAL OPTIONS:
Abusing scripting engines and other legitimate

system tools
As we covered earlier, scripts provide attackers with several advantages. Not only do
they provide rich functionality, the fact that they have many legitimate use cases and can
be easily obfuscated mean detecting and blocking them can be problematic. For these
reasons, they’ve become a favorite tool for attackers to utilize throughout the infection
process, but especially in the payload retrieval phase.
In this section, we’ll look at how scripting engines and other legitimate applications and
command interpreters can be abused to download malware, and what you can do to
preemptively make those methods ineffective.
Preventing VBScript and JavaScript abuse

We’ve already covered ways you can prevent malicious scripts from being launched via
Microsoft Office documents, but unfortunately that’s not the only way attackers can
smuggle scripts onto a machine. Other options include disguising .vbs and .js attachments
by taking advantage of the fact Microsoft doesn’t show file extensions by default (meaning
invoice.txt.js can appear as invoice.txt), or simply hiding them inside archive file formats
such as .zip, .rar, or .7z files.
In order to protect users from inadvertently executing malicious script files, Microsoft
recommends making changes to the registry so a warning prompt is issued prior to
allowing a script file to run. When feasible, admins can also take things one step further
and prevent users from running VBScript or JScript scripts altogether by disabling
Windows Script Host.
Attacks leveraging PowerShell increased 432% in 2017.
— MCAFEE LABS MARCH 2018 THREATS REPORT
Alternatively, an additional trick admins can use to mitigate the risk of malicious .js files
in particular is to tell Windows to always open them with Notepad.
Preventing PowerShell abuse

As its name implies, PowerShell is an extremely powerful framework that consists of
a command-line shell (powershell.exe) and an associated scripting language. Built by

Microsoft to make admins’ lives easier, it can be used to automate an enormous variety
of tasks on both local and remote systems. It’s not exactly a mystery why attackers love it.
PowerShell can be abused to carry out a broad array of malicious activity, from
downloading and executing malware payloads to helping attackers gain persistence,
privilege escalation, and lateral movement. It also features prominently in penetration
testing frameworks like Metasploit and Empire, which provide ready-made attack
modules designed to exploit system weaknesses while evading detection.
PowerShell abuse is a meaty topic and there are certainly plenty of rabbit holes to fall
into. If you’re interested in more in-depth information, we recommend checking out
Symantec’s guide, “The Increased Use of PowerShell in Attacks” as a good place to start.
For our purposes here, however, we’re going to keep things simple and suggest that you
strongly consider disabling PowerShell across the board unless you have specific users or
scenarios that require it. As one security researcher puts it, “just as just as you wouldn’t
leave a 28” heavy-duty cable cutter next to a padlock, you probably don’t want to allow, or
at least make it much more difficult for, hackers get their hands on PowerShell.”
If disabling PowerShell isn’t an option, there are steps you can take to restrict it.
Unfortunately, many of the restriction options built into PowerShell have well-documented
workarounds (there’s even literally a “ –ExecutionPolicy Bypass” command). A more
effective method is to take the whitelisting approach by using Microsoft’s Software
Restriction Policies (SRP) or, better yet, AppLocker. The benefit of using AppLocker is it
allows you to implement more granular controls like, for example, enabling PowerShell
for a select group of power IT users only. You can find a walkthrough of setting up
PowerShell restrictions using AppLocker here.
Preventing abuse of certutil.exe, mshta.exe, and regsvr32.exe

PowerShell isn’t the only built-in Windows tool attackers abuse to download and execute
malicious payloads. Security researchers like Casey Smith and others have sounded
warnings that the following three tools in particular have been ripe for dangerous misuse.
• certutil.exe: This program provides a variety of functions involved with

managing certificates in Windows, including the ability to download a
certificate (or any file) from a remote URL. In addition to abusing certutil.
exe to download malware, attackers can also take advantage of the tool’s
decoding ability to make sure the malware gets past security. First, attack-
ers base64 encode the malicious file in order to make it appear as harmless
text. Then, once downloaded, certutil.exe’s decode command can be used
to decode it back into the executable.

• mshta.exe: HTA is short for HTML application, which consists of HTML and
one or more scripting languages supported by Internet Explorer (ex: VB-
Script or JScript). The danger with .hta files is that they behave as an exe-
cutable and run as a fully trusted application (mshta.exe). So by leveraging
mshta.exe, attackers can launch files that function as executables while
circumventing application whitelisting policies.
• regsvr32.exe: Regsvr32 is a command-line utility designed to register and

unregister OLE controls in the registry. Attackers’ interest in regsvr32 stems
from its ability to execute scripts from remote URLs.
To prevent these three legitimate tools from being used to download payloads, we
recommend either disabling them altogether (in the case of mshta.exe) or blocking
them from making outbound requests. That can be accomplished with Windows Firewall
(instructions here) or any other firewall you have in place.
Preventing abuse of bitsadmin.exe and curl.exe

Over the past year, we’ve also spotted cases where attackers have stopped trying to
be creative and have instead taken a much more straightforward approach to getting
malicious code onto target machines — using legitimate data transfer tools.
In December 2017, for example, we saw attackers use Microsoft’s Background Intelligent
Transfer Service (BITS) to download the SmokeLoader trojan. BITS was also abused by
a different group of attackers in March, this time as part of a campaign that hijacked
MailChimp accounts to distribute the Gootkit trojan.
In non-malicious cases, BITS is used to create valid download or upload jobs, primarily
for Windows and third-party software updates. As is the case with the other tools we’ve
mentioned, because BITS is a valid component of Windows, use of it can blend into
legitimate system activity and be very difficult for many security solutions to detect. If
your organization isn’t actively using BITS, your best move is to disable it.
We’ve also seen campaigns use curl.exe, a command-line tool for transferring data that
is open source. Curl stands out in our list of tools since it doesn’t come pre-installed in
Windows. Because it is widely-used tool with legitimate use cases, however, it is still unlikely
to be blocked by security solutions. In addition to providing the ability to perform file
transfers from the command line, curl also offers file extraction capabilities — something
attackers can certainly put to good (bad) use. Once again, unless your organization actively
uses this tool, it’s recommended you proactively adjust policy settings to block it.
Once again, unless your organization actively uses this tool, it’s recommended you
proactively adjust policy settings to block it.

COMMON TOOLS AND

PREVENTION
APPLICATIONS ABUSED
MICROSOFT OFFICE
Macros Disable or restrict
OLE Disable or restrict
Functionality removed from Word, still needs to be

DDE
disabled in Excel and Outlook
Functionality removed in January 2018 Windows

Equation Editor
Security Update
WINDOWS APPLICATIONS
bitsadmin.exe Block application
certutil.exe Block from making outbound requests
mshta.exe Block application
powershell.exe Disable or restrict using AppLocker
regsvr32.exe Block from making outbound requests
BLOCKING ABUSE OF MICROSOFT APPLICATIONS WITH BARKLY
By watching for malicious process patterns that are allowed by Microsoft but abused by attackers, Barkly detects and
blocks attempts to misuse Office programs and scripting engines to launch attacks.

PART 2
Making endpoints dead ends for malware
In Part 1, we shared how you can ensure attackers have fewer openings and tools to work
with when they attempt to deploy malware, but proactive prevention doesn’t stop there.
You still have to be prepared for the possibility of malware being successfully deployed
on your endpoints. Here in Part 2, we’ll provide tips to help you address that possibility
by seeing to it that nothing malware wants to do when it lands on one of your machines
comes easy.
CHAPTER 3:
Making it more difficult for malware to run

• Traditionally, organizations have relied on antivirus (AV) software to

prevent malware from running
• Attacks have evolved to bypass AV
• To be effective, endpoint protection software should utilize machine

learning for smarter file analysis and real-time system activity analysis
designed for detecting and blocking malicious behaviors
• Application whitelisting is another good layer, but can be difficult to

maintain
• Attackers can also bypass whitelisting and AV by injecting malicious

code into approved processes
• Preventing malicious process injection is difficult without disrupting

legitimate programs, but new endpoint protection solutions can help
Blocking malicious executables prior to them executing has been the job of antivirus
solutions for years. Unfortunately, performance has been slipping. According to research
from the Ponemon Institute, 54% of organizations reported they were compromised by
attacks in 2017, despite having antivirus solutions installed.

PART 2 | CHAPTER 3: MAKING IT MORE DIFFICULT FOR MALWARE TO RUN
As the techniques covered in Part 1 suggest, the average cyber criminal is more concerned
with developing tricky new ways of sneaking droppers past firewalls and email filtering
than they are with evading AV. They know that if they successfully manage to get a payload
onto an endpoint, there’s a very good chance AV won’t catch it. The problem lies in AV’s
traditional reliance on signature-matching.
54% of organizations were compromised in 2017,

despite having AV.
— PONEMON INSTITUTE
How signature-matching works

Antivirus software was built on the concept of blacklisting. AV vendors build and maintain
massive lists of known malware, creating identifying “signatures” for each malware file
sample they find. When a new file shows up on a system, AV will scan it to see if it matches
any of these signatures. If so, it won’t be allowed to run.
Weakness of signature-matching (and static file scanning, in general)

AV products are able to block a lot of malware this way, but as an approach, blacklisting has
inherent drawbacks. For one thing, it’s a numbers game, and thanks to the proliferation
of automated malware toolkits, criminals are able to pump out new samples faster than
AV vendors can create new signatures. For another thing, in order to create a signature
for a new malware sample, there often has to be a “patient zero” who gets infected first
(certainly not fun if you’re that unlucky person).
A real life case-in-point is the ransomware infection that crippled the Colorado Department
of Transportation (CDOT) in February 2018. The CDOT was infected with a variant of
SamSam ransomware, despite having McAfee antivirus installed on its machines. McAfee
responded by updating its software with a new signature designed to block that particular
new SamSam sample. Just eight days later, however, attackers proved how trivial it is to
bypass signature-based detection by infecting the CDOT again, this time with a “new”
SamSam variant that had been slightly modified.
The event caused a CDOT spokesperson to respondin exasperation. “Sure enough, the
variant of SamSam keeps changing,” she said. “The tools we have in place didn’t work. It’s
ahead of our tools.”

Using endpoint protection software to block

malicious behaviors in addition to executables
By this point, the limitations of the signature-based approach are well known, and the
endpoint security industry has been evolving, accordingly. One major change has been
the widespread adoption of machine learning, ushered in with the arrival of “next-
generation” antivirus (NGAV) solutions. This has allowed vendors to dramatically extend
their ability to determine whether or not a file is malware. Whereas that determination
was once based entirely on a simple binary question — does this file match a known
malicious signature? — now vendors are able to leverage the power of machine learning
models to make more accurate predictions based on a host of determining factors, no
signature-matching necessary.
While that innovation has greatly improved the ability of endpoint solutions to detect
even new or modified malware, it still presents one glaring limitation — it relies on there
being a file to scan and analyze. Attackers have adjusted accordingly, increasingly moving
away from using malicious executable files and adopting “fileless” attack techniques,
instead. When all the action during an infection takes place directly in memory or under
the guise of legitimate system processes, for example, neither AV nor NGAV solutions
stand much of a chance.
For that reason, the latest innovations in endpoint protection are being geared toward
gaining greater visibility into system activity and blocking malicious behavior in real-time.
When thinking about endpoint protection, it’s therefore important to recognize which
solutions offer file-based security, which ones can block “fileless” malicious activity, and
which ones cover both.
HOW BARKLY CAN HELP

In addition to leveraging machine learning to analyze potentially malicious files more accurately, Barkly also analyzes system
activity in real-time to block malicious behaviors at the earliest possible opportunity, before damage is done. As an example,
Barkly blocks both ransomware executables and ransomware activity, such as use of native Windows APIs to enumerate file
directories and delete shadow volume copies. Learn more.
Application whitelisting
This section wouldn’t be complete without mentioning application whitelisting, which
some IT pros swear by, but which can also have practical limitations. Your mileage will
really vary based on how complex your environment is and how much time/tolerance
you have for keeping a whitelist properly managed and up-to-date.

If you’re looking for advice on whitelisting, here are two posts that provide helpful tips for
leveraging Microsoft’s built-in whitelisting tools:
• AppLocker — Another Layer in the Defense in Depth Against Malware
• Deploying a Whitelist Software Restriction Policy to Prevent Cryptolocker and More
It’s also important to point out that while application whitelisting can be a healthy deterrent,
attackers have unfortunately developed ways of bypassing it, too. How? Based on the
recurring theme of this guide you can probably guess — by abusing legitimate programs.
With the help of independent researchers, Microsoft has created a list of applications
attackers can use to circumvent application whitelisting policies and recommends that
you proactively block them.
Making it more difficult for attackers to hide

behind code injection techniques
Attackers can also bypass whitelisting and many AV/NGAV solutions by injecting malicious
code into the memory space of a legitimate process, thereby hijacking its privileges and
executing under its guise. There are a variety of malicious injection techniques attackers
can utilize. We’ll cover some of the most common here, but you can read about others in
this post on the Endgame blog.
• DLL injection: One of the most common ways attackers insert malicious
code into a legitimate process is through DLL injection. Dynamic Link Library
(DLL) files contain instructions that multiple programs can call on as need-
ed during runtime. By writing a path to a malicious DLL in a host process,
attackers can trigger that process to execute it. As researchers at ReaQta
discovered, there is even a legitimate, trusted Microsoft program called
Mavinject.exe attackers can use to conduct malicious DLL injection without
raising red flags.
• Reflective DLL injection: With reflective DLL injection, attackers are able to
copy an entire DLL into process memory, which avoids that DLL residing on
disk (making it easily detectable) and being registered with the process it’s
being injected into. Reflective DLL injection has become a popular technique
heavily incorporated into attacks as well as penetration testing tools such as
Metasploit, Cobalt Strike, Empire, etc. which make deploying it easy.
• Process hollowing: Another well-established evasive execution technique is

process hollowing, which involves creating a suspended process, swapping
out the original executable code from that process with a malicious payload,

and resuming the process so the payload is executed. Sorebrect ransomware

uses this technique to hijack svchost.exe, using the legitimate process as cover
to run the malware’s encryption routine.
• AtomBombing: AtomBombing is a code injection technique developed by

researchers at enSilo and later used in the wild to deploy the Dridex trojan.
Its name comes from its abuse of Windows atom tables, which provide appli-
cations the ability to store, access, and share data. By writing malicious code
into an atom table, attackers can force a legitimate program to retrieve and
execute it in the security context of that program.
• Process doppelgänging: Researchers at enSilo presented another stealthy

take on process hollowing at Black Hat Europe 2017. Dubbed “process doppel-
gänging,” it abuses the Windows NTFS Transaction feature and an outdated
but still supported version of Windows process loader to hide malicious code
in the memory of otherwise legitimate processes.
• Early Bird: A new technique discovered in the wild in late 2017 and publicly
disclosed in April 2018, Early Bird involves attackers injecting malicious code
in a very early stage of process thread initiation, prior to where many security
products place hooks (code sections that help them monitor API calls).
Malicious process injection isn’t just a tactic for advanced attackers. We’ve even seen it
utilized by such commodity ransomware as GlobeImposter and GandCrab. One of the
major hurdles in defending against these techniques is that they abuse features and
functionality baked into the way Windows was designed (it’s sort of similar to billionaires
taking advantage of controversial tax loopholes). As a result, prevention is unfortunately
difficult and putting controls in place can run the risk of disrupting legitimate software.
That leaves actively monitoring processes and API calls, which, depending on how many
hours you have in your day, may or may not also be a realistic option. If you do choose
to go that route, Microsoft’s Sysinternals Process Explorer is a good place to start. It
provides a variety of info on active processes, including DLLs and memory-mapped files
they’ve loaded. The PowerShell script Get-InjectedThreads, which scans active threads
on the system for suspicious start addresses, can also help. Last but not least, there are
specific calls in the PowerShell operational log that can provide strong indication of an
attack, and one way of spotting traditional process hollowing activity is by monitoring for
processes being spawned with the CREATE_SUSPENDED flag.
HOW BARKLY CAN HELP

Monitoring is good. Blocking threats automatically is better. Barkly utilizes unparalleled visibility across user space, kernel space,
and the CPU to protect memory and block process injection techniques, no action required. Learn more.

PAYLOADS PREVENTION
• Endpoint protection (machine learning

Malicious executables file analysis)
• Application whitelisting (AppLocker or other)
• When possible, disable or restrict users from

Malicious scripts
running scripts
Malicious behaviors
EX A M PL ES: • Endpoint protection (real-time

behavior analysis)
• Ransomware activity (encryption,
shadow volume copies deletion, etc.) • Windows Controlled Folder Access and
Credential Guard
• Credential theft (ex: stealing
credentials from LSASS)
INJECTION TECHNIQUES PREVENTION
• DLL injection
• Reflective DLL injection
Prevention is difficult without disrupting
• Process hollowing legitimate programs.
• AtomBombing The alternative is monitoring processes and API calls
• Process doppelgänging (Microsoft Process Monitor can help), though that can
also be difficult due to the noise.
• Early Bird
• Etc.
BLOCKING MALICIOUS PROCESS INJECTION WITH BARKLY
Barkly blocks a variety of malicious process injection techniques by preventing processes from mapping new
executable code into the memory of other running processes.

LEGITIMATE APPLICATIONS TO BLOCK

The following can be used to circumvent application whitelisting
• addinprocess.exe, • kd.exe
addinprocess32.exe
• ntkd.exe
• addinutil.exe
• lxssmanager.dll
• bash.exe
• msbuild.exe
• bginfo.exe (versions prior to 4.22)
• mshta.exe
• cdb.exe
• ntsd.exe
• csi.exe
• rcsi.exe
• dbghost.exe
• regsvr32.exe
• dbgsvc.exe
• system.management.automation.dll
• dnx.exe
• windbg.exe
• fsi.exe, fsiAnyCpu.exe

PART 2 | CHAPTER 4: MAKING IT HARDER FOR ATTACKERS TO CONDUCT
POST-EXPLOITATION ACTIVITIES
CHAPTER 4:
Making it harder for attackers to conduct

post-exploitation activities
• Once attackers have initial access, their attention turns to post-exploita-

tion activities
• To continue operating under the radar, attackers prefer “living off the
land,” using legitimate tools and processes already present on the system
• One of the first goals post-exploitation is typically privilege escalation,

the process of gaining additional rights and access
• To achieve persistence, attackers can abuse system tools and functional-

ity to create various load points, including storing scripts in the registry
• A growing number of malware variants are designed to propagate auto-

matically, often by abusing remote administration tools
For attackers, gaining initial access to a machine is just the beginning. From there,
attention can shift to accomplishing a wide variety of post-exploitation goals, from
elevating privileges and moving laterally throughout the network to gaining persistence
and settling in for a long haul of surveillance, remote control, and data exfiltration. In this
chapter, we’ll cover some of the most popular techniques attackers use for each, and
ways you can spoil the party by taking away commonly-abused functionality and tools.
Making it harder for attackers to use your own

tools against you
If you’ve made it this far in the guide, you probably don’t need another reminder that
attackers prefer your tools to theirs. You already have a list of legitimate applications
Microsoft recommends that you block, and you understand the strategic benefits from
an attacker’s perspective of living off the land.

But there’s one more important thing you should

understand about this tactic — while it can be very LIVING OFF THE LAND
effective at evading certain security tools, it also
cedes a lot of power to you as a defender. After all, The strategy of abusing legitimate
if an attacker is relying on your toys, you have the programs and built-in functionality in
option of packing them up. Here are a few more you order to carry out malicious activities
should consider locking away. without raising red flags. Some of
the most commonly abused tools are
• PowerShell: We’ve already covered the risks as- PowerShell, Windows Management
sociated with PowerShell, but this bears repeating Instrumentation (WMI), and remote
— there are very few reasons why average users administration tools like PsExec.
should have fully functioning PowerShell. If you
haven’t already, consider either disabling it alto-
gether or restricting it with AppLocker. It’s simply not worth the liability.
• Windows Management Instrumentation (WMI): WMI provides admin-

istrators with a wide range of powerful capabilities, including locally or
remotely executing scripts via its command line tool (wmic.exe) or Power-
Shell. Those capabilities also make WMI an extremely useful tool for attack-
ers, of course, who can abuse it to trigger scripts to execute based on var-
ious events such at startup, specific time of day, etc. For more information
on how attackers abuse WMI, see this paper by researcher Matt Graeber.
One way to combat malicious WMI abuse is to… use WMI. As Graeber
explains, WMI event subscriptions can be created that log and respond to
suspicious WMI activities (examples here and here). In addition, if you don’t
need to use remote WMI, set a fixed port for it and block it.
• PsExec: Part of Microsoft’s Sysinternals suite, PsExec is another legitimate

administration tool that provides remote command execution. It does that
by connecting to the hidden ADMIN$ share on a remote system via Server
Message Block (SMB) protocol, and starting the PsExecsvc service. Unlike
PowerShell and WMI, it does not come pre-loaded into Windows by default,
so if it isn’t already present on a system it has to be installed.
Thanks to well-documented abuse (including the use of PsExec in the

NotPetya outbreak), many AV programs will now flag PsExec.exe and
PsExecsvc.exe as potentially malicious. Once again, however, attackers have
developed workarounds. By using a PowerShell-based version of PsExec in
Metasploit, for example, attackers can achieve the same functionality while
executing everything in memory instead of writing executables to disk (no
.exe to scan, no AV detection).

Blocking PsExec with blacklisting can be tricky, and a more effective

approach can actually be taking advantage of user account control (UAC)
token filtering. Ex: By enabling “Admin Approval Mode” for the built-in
administrator account, you can limit PsExec so all attempts to abuse it will
fail unless initiated by a domain account.
Making it more difficult for attackers to

elevate privileges
Speaking of UAC, taking full advantage of it can also help you derail several paths to
privilege escalation. That’s because, depending on settings, UAC can allow or deny a
program the ability to elevate its privileges by prompting users for confirmation.
There are many methods attackers have developed for bypassing UAC, but the majority
require dropping a file to disk (ex: dropping a DLL to perform a DLL hijack). That makes
them vulnerable to detection from strong endpoint protection software. To get around
that, attackers can instead attempt to hijack legitimate Microsoft programs and tasks
that are designed to auto-elevate — meaning they can be launched by unprivileged users
but will run with elevated privileges. In doing so, attackers can execute PowerShell scripts
and commands they otherwise couldn’t, and launch high-privilege programs without
triggering UAC prompts. Security researcher Matt Nelson has documented several of
these workarounds, including using SilentCleanup, eventvwr.exe, and sdclt.exe.
Preventing privilege escalation attempts with UAC settings

To mitigate these techniques, it’s recommended that you use the highest UAC enforcement
level whenever possible, including setting UAC level to “Always notify” (yes, this can
potentially be annoying), remove users from the local administration group, and enable
Admin Approval Mode to enforce UAC for the built-in Administrator account.
In addition to hijacking legitimate programs, another well-traveled route to privilege

escalation involves hijacking legitimate credentials. There are several places where
Windows stores credentials — LSASS process memory, the Security Accounts Manager
(SAM) database, and Credential Manager to name a few — and they can even include
credentials of domain users and admins who have logged into the machine. Attackers
and penetration testers have naturally developed tools and tactics to take advantage of
this. We’ll cover specific examples in more detail in the next section.
HOW BARKLY CAN HELP

In addition to the tactics outlined here, there are large varieties of local exploit techniques attackers can use to achieve privilege
escalation, including token stealing, exploiting NULL pointer dereference vulnerabilities, etc. Barkly provides wide coverage against
these techniques by blocking illegitimate attempts to elevate privileges and bypass barriers between user and kernel space.

Making it more challenging for malware to spread

Once attackers have gained initial access to a compromised machine, they rarely want to
stop there. It’s become increasingly common for attacks to leverage exploit techniques as
well as legitimate remote administration tools to spread throughout internal networks.
To leverage those tools, however, attackers often need credentials.
By using Mimikatz, an incredibly popular and versatile penetration testing tool, attackers
can scrape cleartext passwords and NTLM hashes from the memory of lsass.exe (the
process responsible for Windows authentication), or extract saved credentials from
Windows Credential Manager (even domain credentials). Thanks to this PowerShell
script, Mimikatz can be run entirely in memory.
Mimikatz isn’t the only option available to attackers. Metasploit’s Meterpreter payload
can be used to pull account info from the NTDS.dit file (the database for Active Directory),
including not only the current NT and LM hashes, but the saved history going back to
20 previous passwords. Windows Credential Editor is another option. This legitimate
penetration testing tool can be abused by attackers to grab NTLM credentials and
Kerberos Tickets as well as dump cleartext passwords stored by Windows authentication
packages. Additional techniques can be found here.
Harvesting credentials stored on a compromised machine can be extremely useful for

lateral movement, especially when password reuse is so high and there’s also a chance they
can include credentials of domain users and admins who have logged into that machine.
HOW BARKLY CAN HELP

Barkly detects and automatically blocks malicious attempts to access credentials stored in privileged areas of the system such as
the Windows Local Security Authority Subsystem Service (LSASS).
Guarding the keys to the kingdom

Techniques for credential dumping are constantly evolving, but (when possible) the
following basic steps can go a long way towards making many of them more difficult to
pull off:
• Disable credential caching
• Disable or restrict PowerShell with AppLocker
• Adhere to the usual best practices around least privilege and avoiding
credential overlap

When combined with network segmentation best practices, two-factor authentication

(2FA), and the UAC settings recommendations outlined above, these steps can help you
reduce the risk of infections jumping barriers and spreading throughout your network.
Making it harder for attackers to hide malware in

the registry
Landing on a machine is one thing. Once there, many attackers also want to make sure
they can stick around past a reboot and any removal attempts admins might throw their
way. To do that, they often attempt to gain persistence by creating load points that abuse
several built-in Windows features and functionality.
One of the most common ways of achieving persistence is by planting malicious scripts
in the Windows registry. Poweliks and later Kovter are two examples of malware that
has evolved to take that one step further by becoming completely “registry resident,”
spreading code across multiple registry keys and designing it to be extracted and run on
the fly whenever the machine restarts or a shortcut or batch files are triggered.
The good news is because registry contents are stored on disk they can be monitored.
Microsoft’s Sysinternals Autoruns program can help with inspecting registry keys and
even has VirusTotal integration to make identifying malicious entries easier.
Other ways of gaining persistence

Another basic way of establishing persistence is by creating scheduled tasks and using
them to trigger scripts and commands. The QakBot trojan is a good example. Not only does
it create a registry entry to automatically launch itself each time the infected computer
starts up, it also creates two recurring, scheduled tasks to ensure it’s still running and
hasn’t been removed. The first periodically attempts to launch QakBot, while the second
launches a downloader to reinfect the machine should the payload be removed.
You can mitigate this risk by monitoring for scheduled task creation (event ID 4698). This
PowerShell script from Netwrix can help make that more manageable by creating instant
alerts.
As mentioned at the beginning of this section, WMI can provide attackers with similar
capabilities, allowing them to trigger scripts to execute based on various events. For that
reason, monitoring WMI and/or creating defensive event subscriptions is recommended,
as well.
It should be noted that the theme of each of these mitigations is monitoring, which
unfortunately means malicious activity is already under way. While preparing for these
situations is critical, the goal should always be to prevent them in the first place.

MALICIOUS TECHNIQUES PREVENTION
• Use highest UAC enforcement level whenever

Abusing programs designed to possible
auto-elevate • Enable Admin Approval Mode
• Remove users from local admin group
• Endpoint protection software

DLL hijacking • Disallow loading of remote DLLs
• Enable Safe DLL Search Mode
Privilege escalation exploits (token

stealing, exploiting NULL pointer deref- • Endpoint protection software with user space,
erence vulnerabilities, setting security kernel space, and CPU-level visibility
descriptors to NULL, etc.)
• Disable credential caching

• Disable or restrict PowerShell with AppLocker
Dumping credentials • Practice least privilege, avoid credential overlap
• Endpoint protection software that protects LSASS
and other credential stores
Lateral movement techniques • UAC settings recommendations (see above)

(abusing remote administration • Network segmentation best practices
tools, etc.) • Two-factor authentication (2FA)
Hiding malicious scripts in the registry • Monitor with Autoruns
Creating malicious scheduled tasks • Monitor for Windows Security Log Event ID 4698
• Create defensive WMI event subscriptions

Abusing WMI to trigger script execution (examples here and here)
based on events (at startup, etc.) • When possible, set a fixed port for remote WMI and
block it

One last thing
It should go without saying that this guide is by no means exhaustive. There are plenty
of additional attack tactics that aren’t covered here, with more popping up by the day. To
top it off, attackers are also constantly developing bypasses around popular controls. That
said, it’s important to keep in mind that each one you put in place actively raises the bar.
In other words, following the advice in this guide won’t protect you from all malware
infections, but it will help protect you from the majority of campaigns you’re likely to face,
and it will give you a solid foundation to build on.
The overall idea is that you don’t need to have a foolproof answer for every single tactic
an attacker can throw your way. By simply giving them fewer openings and taking away
the tools they rely on most, you can make things significantly more difficult for attackers,
and in contrast, significantly easier for you. You’ll lower your risk, reduce the number of
alerts and noise you have to filter through, save your organization from downtime and
recovery costs, and ultimately get more time back in your day.

Block more attacks
with security that just works
Barkly offers the strongest, smartest protection against today’s attacks by blocking them at every
stage of the attack chain.
Barkly’s unique 3-level architecture provides unmatched visibility and control to see and block attacks
other solutions can’t. As a result, Barkly prevents the delivery and detonation of malware; identifies
and blocks malicious executables, scripts, and behaviors; and provides real-time protection against
fileless attacks and memory exploits.
• Block malware:
Barkly identifies and blocks malicious executables with unsurpassed accuracy, but also
prevents malware from landing on machines in the first place by blocking the most common
malware delivery and retrieval methods.
• Prevent attackers from abusing legitimate Microsoft applications: Barkly protects against
the misuse of valid Microsoft applications and scripting tools by dynamically observing system
behaviors and blocking usage patterns that are allowed by Microsoft but abused by attackers.
• Block malicious behavior:

By dynamically analyzing system activity in real-time, Barkly identifies and blocks malicious
behaviors at the earliest possible opportunity — before damage is done.
• Stop fileless attacks and exploit attempts:

Barkly utilizes unparalleled visibility across user space,
kernel space, and the CPU to protect memory and block the
fundamental exploit techniques that modern attacks rely on.
RE QUE S T A D EM O
About Barkly®
The Barkly Endpoint Protection Platform™ is advancing endpoint security by
combining the strongest, smartest protection with the simplest management.
Barkly is independently certified for antivirus replacement, HIPAA, PCI DSS
& NIST by Coalfire and AV-TEST. Barkly is formed by an elite team of security
and SaaS experts from IBM, Cisco and Intel, and is backed by investors NEA
and Sigma Prime. Learn more by visiting us at barkly.com or follow us on
Twitter @BarklyProtects.

Essential Guide To Blocking Malware Without A Soc

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Essential Guide To Blocking Malware Without A Soc

Hochgeladen von

Copyright:

Verfügbare Formate

THE ESSENTIAL GUIDE TO

6 Part 1: Keeping malware off your endpoints

6 ... Making it more difficult for malware to be delivered

11 ... Making it more difficult for payloads to be retrieved

21 Part 2: Making endpoints dead ends for malware

21 ... Making it more difficult for malware to run

28 ... Making it harder for attackers to conduct post-exploitation activities

34 One last thing

35 How Barkly can help

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 2

Embracing your role as

3 truths about how today’s cyber criminals

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 3

Your job as malware saboteur is to take those tools away. By disabling

Your job as malware saboteur is to break infection chains at the

Who this guide is for

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 4

What this guide will cover

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 5

Keeping malware off your endpoints

Making it more difficult for malware

• Securing email centers on email filtering and user awareness training

• Securing RDP centers on restricting access and setting account

The two most common ways of getting infected

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 6

• Infection via spam emails with malicious attachments

• Infection via malicious RDP access (brute-forced or via stolen credentials)

SECURING COMMON INFECTION VECTORS

92.4% of malware was delivered via email in 2017.

— VERIZON 2018 DBIR

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 7

Looking at that list, two things jump out. First, many

Where user awareness training comes in

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 8

SECURING COMMON INFECTION VECTORS:

Remote Desktop Protocol (RDP)

• Use strong passwords and two-factor authentication

• Limit users who can log in using RDP

• Implement an account lockout policy to help thwart brute force attacks

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 9

Quick review: Your to-do list

COMMON INFECTION VECTORS PREVENTION

• Block commonly abused file types (.vbs, .js, .exe,

• Restrict access via firewalls, RDP gateway, VPNs

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 10

Making it more difficult for payloads

THIS CHAPTER AT A GLANCE

• The majority of malicious email attachments are downloaders designed

• Preventing that retrieval stops the attack short

• Retrieval is typically carried out by abusing legitimate applications or

• Disabling or restricting those legitimate resources from downloading

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 11

REMOVING PAYLOAD RETRIEVAL OPTIONS:

Abusing Microsoft Office

1) Office files are almost universally accepted

2) Office files are easy to weaponize

How attackers abuse Microsoft Office to retrieve payloads

THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 12

WORD DOCUMENT USED IN A SMOKELOADER TROJAN CAMPAIGN IN DECEMBER 2017

Preventing macro abuse

• Disable macros across the entire organization: While it might be a nat-

• Whitelisting: What about only allowing authorized macros? Maybe. Macros

• Disable macros in certain scenarios: Microsoft ramped up macro protec-