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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 3 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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 4 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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 5 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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 6 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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 7 PART 1 | CHAPTER 1: MAKING IT MORE DIFFICULT FOR MALWARE TO BE DELIVERED
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
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 8 PART 1 | CHAPTER 1: MAKING IT MORE DIFFICULT FOR MALWARE TO BE DELIVERED
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 9 PART 1 | CHAPTER 1: MAKING IT MORE DIFFICULT FOR MALWARE TO BE DELIVERED
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
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 10 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
CHAPTER 2: Making it more difficult for payloads to be retrieved
THIS CHAPTER AT A GLANCE
• 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 ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 11 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 12 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 13 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
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\
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 14 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
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\
Note: This will prevent Excel spreadsheets from updating dynamically, so it may not be a practical mitigation for everyone.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 15 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
To disable DDE in Outlook (Office 2010 and later versions):
[HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\OFFICE\
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 programCVE-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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 16 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
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
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 17 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 18 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
• 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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 19 PART 1 | CHAPTER 2: MAKING IT MORE DIFFICULT FOR PAYLOADS TO BE RETRIEVED
Quick review: Your to-do list
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 20 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
THIS CHAPTER AT A GLANCE
• 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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 21 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.”
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 22 PART 2 | CHAPTER 3: MAKING IT MORE DIFFICULT FOR MALWARE TO RUN
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 23 PART 2 | CHAPTER 3: MAKING IT MORE DIFFICULT FOR MALWARE TO RUN
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,
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 24 PART 2 | CHAPTER 3: MAKING IT MORE DIFFICULT FOR MALWARE TO RUN
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 25 PART 2 | CHAPTER 3: MAKING IT MORE DIFFICULT FOR MALWARE TO RUN
Quick review: Your to-do list
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
EXAMPLES: • 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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 26 PART 2 | CHAPTER 3: MAKING IT MORE DIFFICULT FOR MALWARE TO RUN
Quick review: Your to-do list
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
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 27 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
THIS CHAPTER AT A GLANCE
• 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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 28 PART 2 | CHAPTER 4: MAKING IT HARDER FOR ATTACKERS TO CONDUCT POST-EXPLOITATION ACTIVITIES
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).
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 29 PART 2 | CHAPTER 4: MAKING IT HARDER FOR ATTACKERS TO CONDUCT POST-EXPLOITATION ACTIVITIES
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 30 PART 2 | CHAPTER 4: MAKING IT HARDER FOR ATTACKERS TO CONDUCT POST-EXPLOITATION ACTIVITIES
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
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 31 PART 2 | CHAPTER 4: MAKING IT HARDER FOR ATTACKERS TO CONDUCT POST-EXPLOITATION ACTIVITIES
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 32 PART 2 | CHAPTER 4: MAKING IT HARDER FOR ATTACKERS TO CONDUCT POST-EXPLOITATION ACTIVITIES
Quick review: Your to-do list
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
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 33
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.
THE ESSENTIAL GUIDE TO BLOCKING MALWARE WITHOUT A SOC 34 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.
REQUEST A DEMO
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.