Testing Endpoint Security: An Introductory Guide

A Sophos technical paper January 2018 Testing Endpoint Security: An Introductory Guide

Contents

Preface 3 Exploits 14 Introduction 4 Definition 14 Why Conduct Endpoint Security Testing 4 Why Exploits Matter 14 Attack Chain and Modern Attacks 4 How to Test Exploits 15

Disclaimer 6 Active Attacks 17 Prerequisites 6 Definition 17 Testing Overview 6 Why Active Attacks Matter 17 Testing Checklist 7 How to Test Active Attacks 18 Portable Executables (Malware) 7 False Positives 18 Definition 7 Definition 18 Packed/Compressed Files 7 Why False Positives Matter 18 Potentially Unwanted Applications 8 How to Test False Positives 19 Why Portable Executables Matter 8 How to Test Portable Executables 9 Additional Resources 20 Packed Files 9 Testing Lab Environment 20 Potentially Unwanted Applications 10 Overview 20 Ransomware 10 Virtual Testing Lab Architecture 21 Definition 10 Where to Get Samples 22 File Encryptors 10 Conclusion 24 Disk Encryptors/Wipers 10 Why Ransomware Matters 11 How to Test Ransomware 11

Weaponized Documents and Malicious Scripts 12 Definition 12 Weaponized Documents 12 Malicious Scripts 12 Why Weaponized Documents and Malicious Scripts Matter 12 How to Test Weaponized Documents and Malicious Scripts 13

A Sophos technical paper January 2018 2 Testing Endpoint Security: An Introductory Guide

Preface The endpoint security market includes numerous vendors with various powerful technologies designed to keep IT assets safe, yet organizations of all sizes are still susceptible to even the most basic attacks, such as a phishing email with a weaponized document or embedded malicious macro.

In general, there is a disconnect between the standard processes by which the industry tests security products to validate their efficacy and the broad spectrum of rapidly evolving real-world threats. What’s worse, the endpoint security market has become shrouded in a fog of acronyms, vendor-specific terminology, and forward-looking marketing. The risk to IT organizations is that they place the security of their endpoints and servers in the hands of a product that has not been effectively tested beyond a few basic scenarios.

Perhaps due to varying availability of malicious file samples, ill-understood saliency of threat types, or the costs associated with construction of a versatile testing environment, there is a tendency to measure performance of endpoint security across only a single threat vector. As a result, tests are often not holistic, and disproportionally focus on file-based portable execution detection (we'll expand upon this later).

As a result, we at Sophos decided to provide a resource for those who wish to become excellent testers of endpoint security, to provide an aid in conducting unbiased, extensive, and effective testing on any endpoint security product.

We did not wish to produce yet another exhaustive "How to Test" guide, but rather a guide on how to become a world-class tester. There are ample resources for those that need a simple step-by-step guide on how to download some malicious .exes and double-click on them. There is, however, a distinct lack of resources catering towards helping a tester establish the connections between how attacks upon networked infrastructure are performed in the real-world and the various capabilities of endpoint security products to defend against them (and how to validate their efficacy). We hope you find this resource both enlightening and useful.

A Sophos technical paper January 2018 3 Testing Endpoint Security: An Introductory Guide

Introduction Why Conduct Endpoint Security Testing No organization can afford ineffective endpoint security that fails to provide protection against the wide array of ever-increasing and mutating real-world threats. Worse still is that many organizations must rely on third-party tests, vendor-biased or influenced tests, or simply no tests at all. In the age where attackers can learn their skills in a matter of hours watching tutorials on YouTube, the importance of knowing, with some degree of relative certainty, how effective your endpoint security product is couldn't be greater.

In the past few years, there has been a movement among security professionals and hobbyists to empower themselves and take the matter of testing into their own hands. The old adage "the proof of the pudding is in the eating" comes to mind. While it is commendable that an increasing number of individuals wish to supplement third-party and first-party testing results with their own, the industry has been awash with advice and guidance typically focused on how to test antivirus and antivirus alone, often via a single attack vector (such as double-clicking on a malicious file or a scripted equivalent).

Attackers are well aware that the majority of testing of endpoint security products is focused on this single attack vector, typically of portable executables. This has given rise to a number of antivirus evasion techniques, and the prevalence of their use, such as code caving an executable or exploiting vulnerabilities within software, all the while (ineffective) testing would appear to indicate that the endpoint's defenses are strong.

Best phrased by Bruce Schneier, "Security is a chain; it's only as secure as the weakest link.”¹ Testing is essential to find out, for ourselves, how strong our defenses are, for if they are weak, we are only a matter of a misplaced click away from making tomorrow’s news headlines. Attack Chain and Modern Attacks With modern attacks, it is rare that a single event or malware component constitutes the entirety of how an adversary attacks an organization to complete an objective. Most attacks involve multiple steps or stages and not all attacks will use the same techniques to achieve their objective. When observing opportunistic, real-world attacks, it is important to understand that breaking any link in the chain of events that the adversary must complete is often sufficient to thwart the attack in its entirety.

The more capabilities a security product has to prevent and detect elements across the length of the attack chain, the more opportunities it has to defeat the attack.

Often in testing, organizations focus on a single aspect of an attack, like the detection of malicious executables or the prevention of data theft. While this focus is valid in determining a product’s ability to stop that step of the attack, it is also important to realize that not all attacks will be detectable if the protection software only focuses on only some techniques and not others. For example, having software that is great at detecting malicious executables will do an admirable job in detecting attack campaigns that use malicious executables, but will be completely useless if the adversary is able to complete their objective while never delivering an executable file.

¹ https://www.schneier.com/books/secrets_and_lies/pref.html

A Sophos technical paper January 2018 4 Testing Endpoint Security: An Introductory Guide

Web and email have become common vectors of delivering an attack as they specifically target humans to socially engineer them. While this document focuses on attacks post- delivery, these are two pivotal stages of the attack chain that should be considered when conducting testing.

A product that can block access to the malicious URL or IP address, from which the attack is launched or controlled, breaks the entire chain of the attack at its earliest point. Equally, a product that can block an inbound email or provide heightened scrutiny of email clients and web browsers (context-aware behavioral monitoring) will add an invaluable layer of additional security alongside typical anti-malware capabilities.

When evaluating a protection product, it is important to understand how it will address attacks from multiple perspectives. Some of this can be done with testing but often it is just as easy to read the product literature to understand if the product is offering a point solution that targets a single technique or is more comprehensive. Some things to consider and test for include:

ÌÌ Attack Surface reduction, preventing users from going to known dangerous locations on the internet or plugging in uncontrolled devices to their computer

ÌÌ Ability to detect or prevent the deployment of malicious executables

ÌÌ Ability to detect or prevent interaction with malicious documents, image files, and other non-executable files

ÌÌ Ability to prevent legitimate applications from performing malicious actions

ÌÌ Ability to detect and take action on malicious code or scripts loaded directly into memory that do not require a file to be written to disk

ÌÌ Ability to prevent the exploitation of known and unknown vulnerabilities in applications already deployed on the device

As a real-world example of the nature of a modern attack, let’s look at NotPetya, the ransomware attack from early 2017. It should be noted that NotPetya was a supply chain attack – the attackers compromised the updating system for a popular software package so that, when the users of the package updated to the latest version, they downloaded and installed NotPetya. An interesting part of NotPetya was that the ransomware mechanism appears to have no intention of collecting the ransom, instead seemingly focused on causing nothing but destruction – a stark contrast to the original Petya variant whose orchestrators would provide a decryption key upon payment of the ransom.

After NotPetya was installed via the supply chain attack, it overwrote sections of the master boot record and leveraged exploits in system components to spread laterally to infect more machines. At the same time, it harvested user authentication credentials and scanned the local network for other devices to attack and ultimately encrypt files on those devices.

Protection software that stopped any one of the aspects of the attack would either completely prevent the attack or significantly reduce the damage. An endpoint security product that could stop all the aspects is more effective than a product that depends upon a single protection method to do all the work.

A Sophos technical paper January 2018 5 Testing Endpoint Security: An Introductory Guide

Disclaimer This guide is for informational purposes only. Please consult with local laws, regulations, and your corporate policies before conducting any tests. The testing of potential malware and other cybersecurity threats carries a series of substantial risks that you should thoroughly consider before conducting any tests. Any testing that you undertake as a result of this informational guide, or otherwise, is solely at your own risk. Sophos disclaims all responsibility for any tests you may conduct. Prerequisites Given that you are reading this, we are going to assume you have an interest in testing endpoint security software. While we will strive to explain any topics that are likely to be alien, we will assume you have experience in software deployment, anti-malware solutions, and virtualization/virtual machines.

There is no reason to be concerned if you think this task may be too complicated. There is plenty of useful knowledge in this guide on the topic of malware and how to protect against it. There are multiple resources available that can supplement the guidance given here and, together with this guide, you should be ready to take on the task of testing your endpoint security product, or at least understanding what should be tested if you choose to enlist help. Testing Overview Before we can start testing, we're going to need to get our testing environment in order. Conducting thorough endpoint security testing requires a secure testing lab environment where we can safely perform the tests without risk of infecting or affecting other computers on the network (for further reading, see the "Testing Lab Environment" section at the end of this document).

There are lots of ways to evaluate the threats that an organization will face and no one method of evaluation is necessarily better than the other. What we want to ensure is that we cover more than just one tactic or technique used by adversaries.

Instead of providing a guide on how to test the effectiveness of a product against malicious executables only, we will try and address the full threat landscape. Malicious executables only account for 41% of the malware that is delivered to an endpoint² and there are many other techniques that do not require a file to reach the machine at all.

Gathering large numbers of malicious samples and scanning them with a security product provides only a partial indication of a product's effectiveness. Among the pieces of information lost by this method is the context of the infection propagation or attack. The chain of attack – how a malicious portable executable reached your endpoint – is sometimes more important to consider than the executables themselves. Increasingly, the security industry and SophosLabs are seeing file-less malware – attacks that do not rely on malicious executables – becoming the norm.

² Based on VirusTotal statistics covering December 31, 2017 to January 6, 2018. https://www.virustotal.com/en/statistics/

A Sophos technical paper January 2018 6 Testing Endpoint Security: An Introductory Guide

To better measure the effectiveness of an endpoint security product, it is helpful to operate from the perspective of an attacker; to think like them and act like them. Don't panic if some of the below terminology is new to you, as we'll expand upon everything in the coming pages. What's important to note is that the avenues of attack a malicious actor will take are much wider than just a malicious file/portable executable and that misidentifying artefacts as being malicious when they are benign (false positives) can generate so much noise that a solution becomes unmanageable.

This guide will cover the threat space with the evaluation criteria featured below. Testing Checklist

ENDPOINT THREAT ATTACK TECHNIQUE DEFINITION PORTABLE EXECUTABLES Malware Malicious software programs Packed Files/Polymorphism Malware that has been modified to make it harder to identify Potentially Unwanted Applications that are not technically malware, but are likely not Applications (PUA) something you want to run on your machine (aka adware) RANSOMWARE File Encryptors The most common type of ransomware, this encrypts the victim’s files and holds them for ransom. Disk Encryptors and Wipers Encrypts the victim's entire hard drive (not just the files) or wipes the hard drive completely. DOCS AND SCRIPTS Weaponized Documents Typically, a Microsoft Office program that has been crafted or modified to cause damage. Malicious Scripts Malicious code often hidden in legitimate programs and websites. EXPLOITS Exploit-based Attacks Attackers use techniques to take advantage of software bugs and vulnerabilities to gain access and control of a victim's computer. ACTIVE ATTACKS Credential Theft Stealing authentication information (usernames and passwords) to gain access to sensitive data. Privilege Escalation Methods used by attackers to gain additional access in a system. Code Caves Technique where attackers modify legitimate software to hide a malicious application. FALSE POSITIVES N/A Anti-malware solutions may incorrectly identify legitimate software as malicious, impacting end users' ability to work.

Portable Executables (Malware) Definition Portable Executables, or PEs for short, are a common Windows file format for executable files – files that can run and do things on your computer. In laymen's terms, they are referred to as "programs." Malicious programs are of course known as "malware." PEs can have a variety of file extensions but the most common of these are .exe, .dll, and .sys files – executables, shared libraries, and drivers. Most software packages that we install on our computers are effectively a collection of PEs.

Packed/Compressed Files “Packing” a file or executable is effectively using a utility to compress and or obfuscate it. It is common for a software developer to want to compress their software so that it can be downloaded over the internet quickly, as well as minimize the storage space and bandwidth needed to host and serve that file. Developers also wish to obfuscate their executables so that they cannot be reverse engineered, revealing how they function, especially if they are proprietary. Packing is a simple and often effective form of Digital Rights Management (DRM). Many of the most widely used packers are completely legitimate and should not be viewed as malicious.

A Sophos technical paper January 2018 7 Testing Endpoint Security: An Introductory Guide

A downside to these packing tools is that they are also used by malware authors to cloak their malware and make it look like it has never been seen before. When an adversary creates a new malware executable, they realize that it has a very limited life time for use before it becomes known to the community. Once a particular executable has been identified as malicious, the threat intelligence feeds used by most security vendors will feed it into their protection systems so that a signature (or other detection technique) for the new malware can be created.

Potentially Unwanted Applications A PUA can also be known as “grayware” or sometimes PUPs (Potentially Unwanted Programs). This is a file that is not technically malware but is probably not something you want to run on any computer.

Typical examples are spyware and adware – software that tracks your browsing and computer usage patterns, and software that displays adverts on your computer. These are often bundled within installers of legitimate software (and thus users technically opt to have this software installed thanks to click-happy next-next-nexts).

Other forms of PUA are tools like PSExec and PSKill from Sysinternals, or remote access tools. While they are legitimate tools typically used by IT administrators, detecting one on an endpoint might cause some concern. PSExec and PSKill are used for remotely executing and killing processes on computer, while other remote access tools enable users to remotely control a computer. Why Portable Executables Matter PEs are frequently used by malicious actors as the payload for their attack – the part of the attack that performs the malicious actions like encrypting your files or stealing your banking details. As the default Windows executable file format, it is to be expected that malware will also come in this format.

When testing, it is important to delineate between techniques that stop malware pre- execution (before it runs) and techniques that identify malware behavior as it is executing (post-execution).

Blocking malware from executing significantly reduces (if not eliminates altogether) the chances it can cause any damage. Antivirus products typically have at least one feature with the ability to scan PE files and determine whether they are malicious or safe before they execute. This is achieved via various technologies, including machine learning, deep learning (an advanced form of machine learning), antivirus engines (using hash-based signatures or static and dynamic analysis using emulators), and so on.

Some endpoint security products on the market today only focus on the PE attack vector – a user double-clicking on a malicious PE file or a PE file executing via another method (such as a browser exploit or a malicious script). While a key part of endpoint defense, malicious PE detection alone is not enough to keep an endpoint safe.

As the primary attack vector for an operating system, and often the easiest, it is important to ensure your endpoint security product can identify malicious PE files as well as identify safe PE files. Far too often, false positive rates from endpoint security products are not evaluated (we will expand upon this later on).

A Sophos technical paper January 2018 8 Testing Endpoint Security: An Introductory Guide

How to Test Portable Executables You will first need to collect a library of samples that you can test with. See "Where to Get Samples" in the "Testing Lab Environment" section at the end of this guide.

There are two common approaches to testing PE files, both of which are defined by the Anti- Malware Testing Standards Organization in their guide, Best Practices for Dynamic Testing³. There are many test types and we recommend you investigate and develop a testing approach that fits your needs and provides you with the level of insight you need.

One of the two approaches is "one at a time." The goal here is to test each malware sample individually, reviewing the testing machine's state after it has been executed and validating whether it was blocked or let through. This approach is precise, but it can be quite time consuming.

The other major approach is "many at a time." Here, a volume of malicious files are dropped onto the testing machine at the same time to test the real-time anti-malware scanner's ability to detect and cleanup the samples. This is far less precise but it does take much less time to perform.

There is some merit to performing both an "online" and an "offline" test for each security vendor you are testing. Various endpoint security technologies rely on an internet connection to get threat telemetry, false positive information, and more when performing analysis to provide the best level of protection. A real-world attack will typically occur while the machine is connected to the internet. However, to validate the efficacy of an anti- malware scanner alone, performing the test with the internet connection disabled will allow you to see how the product fairs when offline. We recommend changing the firewall rule, or the firewall within your virtual environment, to block outbound network connections so that you can review any attempted network connections in the firewall logs.

Packed Files Many guides for endpoint security testing make heavy use of packed files or re-packed files. As there are still a few security vendors who rely purely or heavily on hash-based detections (signature-based is too generic a term here as it means different things to different vendors), packing a file effectively changes the hash, or fingerprint, of a file.

There are many different packers out there, such as Themida, Obsidium, UPX, and Hyperion. Many security vendors will detect a file as malicious entirely based on the fact that it is packed with a questionable packer (as some packers are more often encountered when used to pack malware than legitimate applications).

For packed files, we recommend that you try packing, separately, both malicious files and benign files. For thoroughness, try packing files with a reputable packer such as 7-zips's SFX (self-extracting) module and with a disreputable packer such as UPX.

If the security product throws a detection purely based upon the packer alone, especially when the contents are benign, this will highlight that the product you are testing may not have the advanced capabilities to inspect executables and identify their true nature (malicious or benign). False positives like these often result in false negatives for genuine malware that doesn't display simple traits such as being packed by a disreputable packer.

³ https://www.amtso.org/download/amtso-best-practices-for-dynamic-testing/

A Sophos technical paper January 2018 9 Testing Endpoint Security: An Introductory Guide

Potentially Unwanted Applications Knowledge of whether the product you are testing is capable of discerning the good, the questionable, and the bad from each other will aid you in understanding both the utility of the product in a large network where an array of applications, not always malicious in nature, will be executed, and whether the product offers the capability to manage these in safety.

In the event a PUA is detected as malware, yet you have downloaded it from a legitimate source and it is the tool you were looking for (PSExec stands as a great example of this), how are you to discern whether this detection is legitimate, or that the file is truly malicious, or a false positive?

While we recommend you seek out adware and other PUAs yourself, we maintain a feed of our latest PUA detections that you can use to help you understand what kind of applications often fall into this category: https://www.sophos.com/en-us/threat-center/ threat-analyses/adware-and-puas.aspx

Ransomware Definition While ransomware could be considered just another type of portable executable, script, macro-embedded document, or another non-PE based attack, we have broken them out due to their unique attack methodology and the prominence of these attacks.

There are two main types of ransomware – those that encrypt files, and those that either wipe or encrypt the entire hard drive. Ransomware typically enters via a phishing attack, although multiple attack vectors can be used.

What makes these attacks so effective is that they use asymmetric encryption where two keys are generated – one key to encrypt and another to decrypt. The attacks generate these keys and strive to ensure the decryption key is not accessible to the victim. Once the victim has been infected, this decryption key is what they are pushed to purchase as part of the ransom. Without the key, decryption is often impossible.

File Encryptors File encryptors are the most common types of ransomware. During these attacks, as the ransomware is executed, it silently encrypts the victim’s files on their hard drive as well as any network mapped drives. Once they are encrypted, the user is presented with a screen or notepad file with instructions on how to decrypt inaccessible files by first paying a ransom to the attackers in digital currency (such as Bitcoin) to retrieve the decryption key needed to decrypt their files.

Disk Encryptors/Wipers Wiper attacks go beyond just encrypting files, often encrypting the entire hard drive or even going as far as wiping the victim's hard drive completely. More recent versions modified wiper attacks by scrambling the MBR Master Boot Record (MBR). In these attacks, when the MBR is tampered with, machines become virtually inoperable. Often, as was the case in the 2017 NotPetya ransomware, a ransom was still demanded. The 2014 Sony Pictures hack and the 2012 Shamoon Saudi Aramco attack were examples of attacks that used wiper malware and did not request a ransom.

A Sophos technical paper January 2018 10 Testing Endpoint Security: An Introductory Guide

Why Ransomware Matters Ransomware has grown to one of the largest worldwide threats. 54% of organizations were hit with ransomware over the past year, with the median cost cost of dealing with an attack (including downtime, work hours, network costs, and ransomware payments) being approximately US$133K (£100K)⁴. On average, victims paid $2,500⁵ to get their files decrypted, with 30% of victims never getting their encryption keys after paying⁶.

However, costs go well beyond the payment to the attacker. The disruption of business due to ransomware can have a massive financial impact. For example, due to the NotPetya ransomware, FedEx claimed $400 million in losses⁷, while pharmaceutical giant Merck had to shut down production of one of its drugs costing them close to $300 million⁸. How to Test Ransomware When testing a product's ability to detect ransomware, you need to consider at what point it may detect the ransomware, be it pre- or post-execution, but also what kind of damage the ransomware was able to make before it was detected and, if possible, remediated.

Crucial to evaluate the impact of a file encryptor ransomware sample, you need to prepare a realistic file system before you start testing – a My Documents folder with documents in it, a Pictures folder with photos, and so on. You can duplicate the same file and rename it so that you have image01.jpg, image02.jpg etc., but it's important you have a large volume of files in every directory. This will enable you to evaluate how quickly into the encryption process a detection is made, but also whether the product has the ability to roll back the encrypted files to the state they were in prior to the infection.

It's safest to test ransomware using the "one at a time" approach, explained in the Portable Executable section. This will allow you to observe the activity on the testing machine, how long it takes for a detection to be made, and to compare the file system before and after the detection (so you can evaluate how many files were encrypted before detection, as well as whether or not they were rolled back to their original, unencrypted state).

Most ransomware samples are packed, which means that the sample may have a unique hash. Once executed, it will unpack itself, revealing several components that may be reused between attacks. This enables security vendors to create static detections, usually based upon a hash of one of the components, to detect the ransomware. Perform a test where either the cloud lookup capabilities of the product are disabled or the machine's internet connection is disabled (note that some ransomware variants may not encrypt files unless a live internet connection exists). With these lookups disabled, you will be able to evaluate the product's ability to detect the sample without referencing hashes.

Given the financial incentive for attackers to conduct a successful ransomware infection, we cannot rely on pre-execution detection alone to identify and block ransomware. Assuming a variant will find a way to get to the point where it can execute (WannaCry leveraged an unpatched vulnerability to evade detection by more traditional security vendors), we want to observe how a product can behaviorally identify ransomware that is running and block/remediate the damage it has caused. Disable file scanning and leave the behavioral detection capabilities on (our ransomware detection capability is called CryptoGuard, for instance) and conduct testing.

⁴ The State of Endpoint Security Today - An independent survey of 2,700 IT managers in mid-sized organizations, sponsored by Sophos ⁵,⁶ Ponemon Institute ⁷ https://securityledger.com/2017/12/notpetyas-cost-fedex-400-million-counting/ ⁸ https://securityledger.com/2017/10/notpetya-infection-left-merck-short-key-vaccine-gardasil/

A Sophos technical paper January 2018 11 Testing Endpoint Security: An Introductory Guide

Disk encryptors or wipers is best tested using known samples (such from theZoo – see the Where to Get Samples section at the end of this guide) with cloud lookups and file scanning disabled. Their prevalence in the wild is low yet their impact if they successfully infect a machine, is high. Locating samples in the wild can be tricky and are likely to be older samples that have just been repacked and finding a new variant that hasn’t been seen before could require extensive searching. By disabling cloud lookups and file scanning, you can evaluate the product’s capabilities to identify a disk encryptor post infection and post execution which will give you an indication of its effectiveness against a zero-day or new and unknown disk encryptor variant.

Weaponized Documents and Malicious Scripts Definition Not all endpoint attacks rely solely on malicious files. Many attacks are file-less, meaning the attacker does not write any files to the user’s system. Some begin as file-less but use these techniques to later drop malware. Two common examples of file-less attacks are weaponized documents and malicious scripts.

Weaponized Documents Weaponized documents are typically Microsoft Office documents such as a .ppt, .doc, or .xls that take advantage of legitimate functionality (such as macros) to cause damage. Weaponized documents are often used as part of a spear phishing attack with carefully crafted emails. The emails use crimeware and ransomware. Alternatively, they can be fully file-less, delivering their payloads directly in memory.

Malicious Scripts Malicious scripts are pieces of code that can be used to cause damage. They are often hidden in legitimate programs and websites. For example, a user can visit a legitimate website that has been compromised which would allow an attacker to execute malicious code. This can be used to exploit other programs, drop malware, or gain persistence. Why Weaponized Documents and Malicious Scripts Matter Many attacks, including the 2012 Shamoon Saudi Aramco, utilize weaponized documents as their entry point. In fact, 26% of malware attacks used weaponized Office files, where attackers used macros in files like Word docs as part of their attack⁹. Malicious scripts are also a very popular attacker tool. Malvertising campaigns, where legitimate ads deliver malicious code, is a common example of an attack type that uses this technique.

Weaponized documents have been widely utilized in email-based social engineering attacks, or phishing campaigns, as email is one of the primary ways in which users share data with each other. An email, seemingly sent from the head of HR, with an attached payroll document is an example of a simple way to trick a user into opening an attached file. Once opened, if macros are enabled, the code will execute the next step of the attack. Even with macros disabled, users will often click the button in Word to enable them and the weaponized document may even include instructions on how to do this.

While these documents and scripts are often not the payload of the attack, they are often a key part of an attack chain. When the document is opened, it might download and run a PowerShell script which, in turn, performs the next stage of the attack.

⁹ Verizon Data Breach Investigations Report 2017

A Sophos technical paper January 2018 12 Testing Endpoint Security: An Introductory Guide

How to Test Weaponized Documents and Malicious Scripts When evaluating weaponized documents, it is important to note that these are not only Office and PDF documents but include media files and other document types that are not themselves executable. If we are going to test just weaponized Office and PDF documents, it is a fair test but not complete, so you may want to ensure you also find, create, and otherwise test with more than just Word macros.

Fortunately, for testing purposes, a number of penetration test tools exist that can facilitate the creation of weaponized documents. Tools like luckystrike¹⁰ are open source, and you can find a number of videos online on how to use such tools.

Different security vendors take different approaches to detecting weaponized documents. While testing, you should try and clarify not just whether the attack is blocked or not but how the block was achieved (which may require referencing product documentation). To help, here are some examples of how they can be detected:

1. Heuristics that evaluate the macros or Visual Basic Scripts in the document as part of static analysis using a file scanner

2. Behavior monitoring of the file being executed in a sandbox or emulator

3. Lockdown tools that prevent the use of PowerShell WScript, CScript etc

4. Context-aware run time behavior monitoring that can detect a malicious combination of activity like a Word document received from an email that, when opened, runs WScript or PowerShell to download and install another executable

In many cases, administrators think that simply disabling macros and preventing the use of Visual Basic is sufficient to protect against weaponized documents but that is not always the case¹¹.

Whether you are generating your own weaponized documents with a penetration test tool or collecting weaponized documents from an online malware zoo, you need to understand what portion of the protection product is providing protection. If the document is caught on initial delivery before it has been opened, then a scan or sandbox technique may have been used. To confirm that additional protection techniques are also in place you should disable the file scan or sandbox protection capability and test once more. With this approach, you are able to evaluate other aspects of protection in the product and can examine if the protection product can detect the malicious use of scripts at run time or detect the combination of malicious behaviors that the document reader is performing.

For some additional reading on weaponized documents check out Sophos Naked Security.

ÌÌ Rise of document based malware https://www.sophos.com/en-us/security-news-trends/security-trends/the-rise-of- document-based-malware.aspx

ÌÌ Why Word malware is BASIC https://news.sophos.com/en-us/2015/09/28/why-word-malware-is-basic/

¹⁰ https://github.com/curi0usJack/luckystrike ¹¹ https://www.csoonline.com/article/2937980/malware-cybercrime/weaponized-word-docs-spyware-and-malvertising-sprouting-in-may.html

A Sophos technical paper January 2018 13 Testing Endpoint Security: An Introductory Guide

Exploits Definition An exploit, or exploitation technique, is the underlying way in which an attacker can abuse a software vulnerability to make a computer execute something unintended. Exploiting vulnerabilities enable adversaries to carry out actions that would not otherwise be allowed.

There are a limited number of fundamental exploit techniques, such as buffer overflows, heap sprays, and return-oriented programming (ROP) attacks. To successfully deliver an attack, one or more of these techniques is customized to exploit specific vulnerabilities.

An exploit kit allows automatic discovery, usually via a malicious or compromised web page, of the vulnerabilities present on a victim's system. The kit can then deliver code that is customized to effectively exploit that system. Why Exploits Matter From the point of view of an adversary, a crucial step in the attack chain is to get the target computer to do something the user (or the business) doesn't want done. This could include installing malware, running a script, writing data to the registry, or reading data from memory.

There are two main ways for the attacker to achieve this. One is social engineering— tricking the user into opening or installing something that looks benign but is, in fact, malicious. The second is to use an exploit. By leveraging a software vulnerability, the attacker gets access without depending on the user.

Of course, these two techniques can be, and often are, combined. As described earlier, a weaponized Word document could depend on social engineering to be opened but then use an exploit to run a script that downloads and installs a backdoor or ransomware.

It’s common to find exploits used as part of cyber attacks; in fact, an exploit is used at one or more points in the attack chain. Examples of how exploits are used by attackers include:

ÌÌ Downloading and installing malware

ÌÌ Moving laterally from one system to another within a targeted organization

ÌÌ Gaining elevated access (e.g., administrator or system privileges)

ÌÌ Maintaining persistence within the victim's environment

ÌÌ Exfiltrating stolen data

The ability to prevent, detect, and/or block exploits—independent of detecting malicious files—provides numerous advantages to the organization. First, it can stop file-less attacks that do not rely on malware – these can include both attacks involving an active adversary (e.g., a hacker attempting to conduct reconnaissance in real time) and automated attacks that run in memory. Second, it reduces the risk of malware being delivered to endpoints via browser or document exploits. Third, in the event that a malicious file was missed during pre-execution scanning, the exploit detection can alert to the presence of malware and disrupt its execution.

A Sophos technical paper January 2018 14 Testing Endpoint Security: An Introductory Guide

How to Test Exploits When testing an endpoint product, you'll want to learn whether, to what extent, and how the product protects against exploits. Sophos Intercept X, for example, focuses on core exploit techniques, such as heap sprays and stack pivots, so it needs no prior knowledge of a vulnerability to protect it. Another product might use signatures or heuristic rules to detect known exploit code or focus on certain telltale behaviors. It’s also helpful to determine which applications or processes are protected. Some of this information may be available in the vendor’s technical documentation; other capabilities or limitations may be revealed only through detailed testing.

To ensure you're testing exploit protection instead of other defenses, it's helpful to disable features such as real-time file scanning, online lookups, and reputation-based detection.

You will have to set up your testing machine with a variety of applications known to have a number of vulnerabilities. Older, pre-patch versions of Microsoft Office, Adobe Reader, Internet Explorer, Firefox, and Flash Player make good targets. There are more known exploits that will be successful against 32-bit applications and versions of Windows (esp. Windows 7) than their 64-bit counterparts. With that said, you may prefer to test against an environment that mimics the most vulnerable of your in-house endpoints.

There are two main approaches to testing exploit protection. The first is to use malware samples or malicious URLs that make use of exploit code. The advantage of these is that they're relatively easy to use – run an executable or browse to a URL from a vulnerable browser, and let it do its thing (again, ensuring file detection is disabled). The disadvantage is that it can be difficult to reliably find samples. Malware sources like VirusTotal or Malshare do not consistently and accurately identify samples that incorporate exploits. Even if they do, they may not specify which exploit or technique is in use, which makes it difficult to ensure it will work properly in your test environment. Similarly, drive-by download URLs that you find online may not be live; if they are, they may not function as expected without specific parameters (e.g., a specific referral string); and, again, you won't know which exploits are in use.

The second approach is to use a penetration testing tool, such as the Metasploit Framework (MSF), to deliver exploits to your target system. This requires a bit more research and learning on the part of the tester, but it also provides more control over the testing process. It also allows you to check protection against newly publicized proofs of concept, which you may find on researcher or security vendor blogs (such as Sophos’ NakedSecurity¹²).

Metasploit is most easily used by setting up a second VM on the same virtual network as the victim VM. Kali Linux is a distribution that includes Metasploit and other exploit tools, making it an ideal OS from which to launch your attacks.

How to use Metasploit is beyond the scope of this document, but the free online book Metasploit Unleashed¹³ is a great resource. In addition to the many exploits within MSF itself, you'll find that some web searching will turn up a number of helpful proof-of-concept scripts. There’s even a guide to adding new exploits from The Exploits Database into Metasploit.¹⁴

¹² https://nakedsecurity.sophos.com/ ¹³ https://www.offensive-security.com/metasploit-unleashed/ — see especially the Metasploit Fundamentals and Client-Side Attack sections ¹⁴ https://kakkulearning.wordpress.com/2014/07/06/add-new-exploits-metasploit-exploit-db/

A Sophos technical paper January 2018 15 Testing Endpoint Security: An Introductory Guide

Delivery of the exploits will often take one of two forms. The first is an exploit-laden document (.pdf, .docx, etc.) that you’ll copy to the victim system and then open. The second is a web server set up by Metasploit that enables you to browse to web pages from the victim computer. Often, a successful exploit will create a communication channel back to Metasploit, which can then be used to run shell commands, attempt further exploits, or query information about the victim system. Note that some exploits, especially memory exploits, can be inconsistent; it may take several attempts to get them to work successfully.

Regardless of the tools you use to test, you should seek out a variety of different exploits. This includes different target applications, as well as different techniques. Look for exploits that emphasize evasions (the description might say “evades ASLR,” for example) or those that detail the specific exploit technique (“return-oriented pointer,” “APC,” etc.) The broader your exploit test set, the more accurate a view you will get of a product’s abilities.

Once you have your environment configured, a typical testing process might look like this:

1. Test exploits on an unprotected victim system to ensure they work and that you know how to verify successful exploit.

2. Working from a snapshot of the unprotected VM, install and configure the endpoint protection product. Ensure that exploit protections (including “memory protection”) are enabled. Disable file detection and other features that detect different parts of the threat chain.

3. Take another snapshot with the product fully configured.

4. Test each exploit against the victim VM, ideally rolling back to the “clean” snapshot version each time.

5. Assess each exploit attempt:

a. Did the exploit succeed?

b. Did the endpoint protection software raise an alert within the user environment?

c. Did the endpoint protection software raise an alert within the admin console?

i. What triggered the detection? Was it the Metasploit Meterpreter module? A specific exploit technique? A signature recognizing specific code?

ii. What action, if any, did the endpoint software take to block or disrupt the exploit?

iii. What action, if any, did the endpoint software take to clean up the source of the exploit (e.g., malicious document)?

d. Did the exploit fail but without any alert from the endpoint protection product?

i. Are you sure the exploit works reliably without the endpoint protection software installed?

ii. Does the endpoint protection software enforce preventive exploit mitigations, such as ASLR, that could protect against the attack without triggering an alert?

A Sophos technical paper January 2018 16 Testing Endpoint Security: An Introductory Guide

Depending on the policy configuration options in your endpoint software, you might also consider running the same exploit multiple times, enabling and disabling different protection features. This might reveal that the product would have detected the threat using three different technologies or, conversely, that it is dependent on detecting a single signature/technique/behavior.

Active Attacks Definition We’re defining an “active attack” as an operation in which one or more people are directly engaged in controlling the attack. In other words, as anti-malware has improved, hackers are increasingly attempting to go undetected by entering systems as a legitimate user. Most of these attacks involve multiple stages. After penetrating the endpoint via malware and/or an exploit, adversaries use backdoors and other tools to steal credentials, escalate privileges, move laterally, and exfiltrate data. While some attacks are "smash and grab" operations, attempting to steal as much as they can as quickly as possible, more sophisticated attackers will stay unnoticed and active inside an environment for months and even years. Why Active Attacks Matter While widely-distributed malware is more commonplace, some of the most dangerous threats are those that are manually controlled by one or more attackers. Data breaches, sabotage, and blackmail are some of the end goals that lead attackers to take an active interest in a target organization.

Adversaries have an arsenal of techniques at their disposal which they can use to carry out their attack. A few examples of these techniques include:

ÌÌ Privilege escalation: When an adversary has gained access to a system, they are often not running at the privilege level they want or need to complete the rest of their attack. Several methods exist for the adversary to elevate privileges from credential theft to process migration. For example, stealing the authentication token for a privileged process and inserting it into another process to elevate privileges.

ÌÌ Code cave: Code cave utilization, akin to file infectors, is a technique used by adversaries where they modify a legitimate application, such as Notepad or Putty, so that it contains an additional application, like a remote shell launcher. This additional application is inserted into what is called a code cave, a section of the target application’s file that is unused by the program. If the application that has been modified is a legitimate business tool that the administrator expects to be on the device, they are likely to ignore or override an alert from the malware scanning component of their endpoint protection software.

ÌÌ Credential theft: Stealing usernames and passwords (and other forms of authentication) to gain access to sensitive data. Dozens of different tools are available for the adversary to achieve this. A common one is mimikatz, a credential extraction tool that targets Local Security Authority Subsystem Service (LSASS) memory.

A Sophos technical paper January 2018 17 Testing Endpoint Security: An Introductory Guide

Detecting and blocking active attack techniques can not only disrupt the attack, but also alert the IT security team to malicious activity in progress. As a comparison, if a bank robber breaks into a bank, he still needs a way to open the vault, take the money out, and escape in a getaway car. Blocking any of these steps would stop the attack, while activating an alarm would alert the police so they can respond appropriately. How to Test Active Attacks The active attack techniques described in this section typically follow a successful exploit or malware delivery. Therefore, you can use the testing environment described above in the Exploits section. Kali Linux will again be an ideal platform, as it contains quite a few tools used by both real attackers and penetration testers.

The Metasploit Framework, which is described in more detail in the Exploits section, contains several commands that reproduce active attack techniques. Typically, you would start by opening a reverse shell using one of the MSF exploits, and then follow up with one or more active attacks.¹⁵

Shellter is another useful attack tool. Shellter can inject code similar to the code cave technique described above and can also use additional obfuscation techniques to help malware evade detection.¹⁶ It’s a great way to probe a product’s ability to detect unknown malware, as well as malicious behaviors from a process that wasn’t identified as malware pre-execution.

Once again, it is important to exercise different protection features within the endpoint product you are evaluating. Any number of protection layers could come into play in identifying these techniques. Sophos Intercept X, for example, has explicit protections against code caves and privilege escalations, as well as more generic techniques such as machine learning for detecting malicious files pre-execution. Ideally, your simulated attacks would be stopped by multiple features, giving you confidence that a real attack that evaded one layer of protection would be caught by another.

False Positives Definition Incorrectly classifying something that is benign as malicious. For example, flagging a legitimate program as malware. Why False Positives Matter In all predictive models there is a tradeoff between true detections and false positives. Sometimes testers forget to test for false positives. This means the tool they are evaluating can be tuned to detect most everything as malicious and would look quite accurate. However, the tool might also be detecting benign files incorrectly, producing a result that does not reflect a real-world experience. This would have a large negative impact once deployed into a production environment.

Security products should be ranked by comparing their true positive rate (correct identification of malware) against their false positive rate (incorrect identification of benign files as malware). Commonly a receiver operating characteristic curve is plotted from this data (a form of graph).

¹⁵ See the MSF Post Exploitation section of https://www.offensive-security.com/metasploit-unleashed/ ¹⁶ https://www.shellterproject.com/introducing-shellter/

A Sophos technical paper January 2018 18 Testing Endpoint Security: An Introductory Guide

A high number of false positives is a good indicator of an overly sensitive product and one that often does not have the depth of functionality and capability to clearly distinguish good files from bad files. This is furthered if the product also requires you to specifically tell if what files are good, or “train” it. There are many simple indicators that a file may be malicious (such as it is packed, as discussed in the Portable Executables section) which does not require any in-depth analysis of the file. By whitelisting large volumes of files, this allows the product to continue to use its simple logic to flag potentially dangerous files. How to Test False Positives False Positives should be evaluated throughout all testing activities in the same way that False Negatives, e.g. malware that was not detected and thus failed to be detected as malicious, are evaluated.

Akin to how you gathered a large volume of malicious samples for PE detection, you should similarly gather a large volume of clean / safe files. Sources for this data can be copied from:

ÌÌ The file systems of several live, production machines that you have established to be clean of infection or dormant malware

ÌÌ The Program Files directory for all the applications you commonly use in your environment (be they on your endpoints or your servers)

ÌÌ Files from your network shares, representative of the various file types you have stored

ÌÌ Any software that has been developed in-house (if they exist)

ÌÌ Tools and utilities used to administer the network

Many products require extensive “training” periods where you must whitelist large volumes of files that are safe and commonly used in your environment. This training period is a good opportunity to identify how false positive prone the product is as the training, in this context, is typically a whitelisting exercise to stop the product raising these false positives again in the future. If the product you are testing does require a period of training, take the opportunity to see how many detections it makes upon your collection of safe files.

In addition to determining if an endpoint protection product has an acceptable or unacceptable rate of false positives, it is recommended that you analyze what an administrator would need to do to reduce the impact of false positives. Management consoles should offer the ability to easily whitelist specific programs and behaviors to ensure business is not negatively impacted. This can be done in advance of a full deployment to ensure the process is seamless for the end user.

A Sophos technical paper January 2018 19 Testing Endpoint Security: An Introductory Guide

Additional Resources As we have already iterated, this guide is by no means an exhaustive, comprehensive guide. Fortunately, there are resources that go into great depth if you want to dive deeper into the world of endpoint security testing. Here are few resources we recommend:

ÌÌ The Anti-Malware Testing Standards Organization (AMTSO) are an international non- profit focusing on producing standards for objective and relevant standards for anti- malware testing. They have a quick checklist to confirm your endpoint security product has all the basics to keep you protected, and a number of documents covering how to conduct quality testing: https://www.amtso.org/feature-settings-check-for-desktop-solutions/

ÌÌ "Building Virtual Machine Labs: A Hands-On Guide" by Tony V. Robinson is an essential read for those who wish to use virtualization to build home labs or testing labs for any purpose. If you're new to virtualization and don't know where to begin, this is a great start.

ÌÌ "Metasploit: The Penetration Tester's Guide" by David Kennedy, Jim O’Gorman, Devon Kearns, and Mati Aharoni covers the Metasploit framework (a vital tool for leveraging pre-written exploits to test exploit detection and mitigation features of endpoint security products) in great depth. The section "The Joy of Exploitation" stands as a great overview of the Metasploit Framework's console and how to use it to pick and leverage a vulnerability and pre-written exploit.

ÌÌ MITRE, who maintain the Common Vulnerabilities and Exposures (CVE) system, host ATT&CK, a curated knowledge base and model for cyber adversary behavior, reflecting the various phases of an adversary’s lifecycle and the platforms they are known to target. ATT&CK is useful for understanding security risk against known adversary behavior, for planning security improvements, and verifying defenses work as expected. https://attack.mitre.org/wiki/Main_Page

Testing Lab Environment Overview The absolute best environment for conducting these kinds of tests is on machines that are physically isolated from any part of your live/production network. By this we mean on dedicated machines on a dedicated network with a dedicated internet connection. Physical isolation like this ensures nothing can infect any of your computers that you use for work or personal use. You should never, ever, ever, test on a production machine.

That aside, it’s not always possible to have a completely physically isolated network due to budget restraints and so on. If this is true for you, building a virtual testing lab may be your only choice. If you must do this, you need to be extremely careful when building your lab and take every precaution you can to keep the network traffic from your testing machines away from your ‘real’ machines.

Most virtualization solutions will allow you to take "snapshots" of the virtual machines. When a test has been performed, like executing a piece of malware, you can afterwards roll the machine back to the state it was in before running the malware, effectively undoing the infection of that machine. This is far easier than attempting to clean up a physical machine, especially if the product you are testing doesn't completely clean up the infection.

A Sophos technical paper January 2018 20 Testing Endpoint Security: An Introductory Guide

There are many different virtualization solutions on there. To name just a few: VMware Workstation, Oracle VirtualBox, KVM, and Xen. As long as it has configurable virtual networking so that the machines can be isolated from the rest of your network, it should be sufficient. Virtual Testing Lab Architecture Below is a diagram that details a viable testing lab architecture. Feel free to make changes or to use your own architecture if you are confident the configuration provides sufficient protections against unwanted propagation or communication.

Internet

Virtualization Host Firewall Router Production Network

Virtual Network

Virtual Firewall

Testing Guest Testing Guest

Using either a dedicated VLAN (if sharing the same network switch as the rest of your network) or physically separated from your production network (such as directly connecting your virtualization host to your firewall), create a firewall rule that isolates your virtualization host so that it only has access to the internet and zero access to your production network.

If you wish to allow internet access to your testing lab, look to only allow basic network services such as HTTP (80/TCP), HTTPS (443/TCP), DNS (53/UDP), NTP (123/UDP, TCP) through the upstream firewall.

We recommend that you create an internal network, within your virtualization host's hypervisor, and add all virtual machines to this internal network rather than giving them a bridged or NAT network adapter to the host's primary network interface. The will ensure that executed malware can only see the machines within the virtual network and is thus isolated.

A Sophos technical paper January 2018 21 Testing Endpoint Security: An Introductory Guide

To gate access to the virtual network, a virtual firewall should be employed, using similar firewall rules as the primary firewall, only allowing a limited number of network services out of the virtual network. This will add an additional layer of separation for your testing lab, giving you a level of fail safety should the primary firewall for your network be misconfigured, giving your virtualization host more access to the network than it should. Note: This is an optional precaution, and it could affect the way certain malware samples behave.

Ultimately, all guest virtual machines, which will be used for the actual endpoint security testing, should only have a single network adapter, for the internal virtual network. The only exception should be the virtual firewall which should have a bridged or NAT adapter, for communication to the primary firewall, and an adapter for the internal virtual network, for communication with the other guest virtual machines.

Finally, disable all sharing features between the guest virtual machines and the hypervisor/ host – features like file sharing, drag-and-drop, copy and paste, VNC. While it's unlikely these features will be abused by malware, disabling them will protection you against accidentally dragging a file from the guest to the host and other similar mishaps. Where to Get Samples Acquiring samples is a key element to properly test endpoint security. Below, find a selection of sites to find test data (however, there are many others out there that we may have neglected to add to this list):

ÌÌ VirusTotal https://www.virustotal.com/

ÌÌ theZoo https://github.com/ytisf/theZoo

ÌÌ Malshare https://malshare.com/

ÌÌ Virusshare https://virusshare.com/

ÌÌ PhishTank https://www.phishtank.com/

ÌÌ Malware Corpus Tracker http://tracker.h3x.eu/

ÌÌ Malpedia https://malpedia.caad.fkie.fraunhofer.de/

ÌÌ Internal data Using your own file shares and desktop machines will help you collect benign files used for false positive detection (use as many custom applications as possible). Your spam folder is also a good source for phishing emails.

A Sophos technical paper January 2018 22 Testing Endpoint Security: An Introductory Guide

Samples should be collected and grouped based on several criteria (as defined by the Anti- Malware Testing Standards Organization¹⁷):

ÌÌ Functionality Ensure that the samples that you have collected are functional and are not corrupt in any way. It is a good idea to test the samples out and verify whether they perform any malicious actions or not.

ÌÌ Diversity Try to collect samples from a variety of different sources to avoid sample bias (some sources may identify and collect more of one type of malware than another), and also ensure that you have an array of different types of malware. Having a large collection of ransomware but a small collection of banking trojans (for example) would not give a clear indication of the breadth of detection capabilities an endpoint security solution has.

ÌÌ Relevance There is little benefit for testing out old malware samples that can only infect MSDOS computers. Ensure that the samples you are collecting are prevalent and seen in the real world.

ÌÌ Freshness While difficult, it is important to collect and test samples while they are still "fresh" and, if possible, have yet to be submitted to a security vendor. Consider performing more rigorous tests with samples you have collected over a period of time and supplement your tests with another sample set of brand new samples that have only just been submitted to the sample collection and sharing platform of your choice.

The samples should be downloaded directly onto a dedicated guest virtual machine (or "malware server") that has a network share available to the other guest virtual machines that you will conduct the endpoint security product testing on.

Once you have gathered an ample amount of samples to test with, ensure you take a snapshot of the malware server so that you can always revert back to that snapshot after conducting a test.

¹⁷ https://www.amtso.org/download/amtso-best-practices-for-dynamic-testing/

A Sophos technical paper January 2018 23 Testing Endpoint Security: An Introductory Guide

Conclusion Diligent, holistic testing of an endpoint solution extends beyond typical file-based portable execution tests. Testing a wide range of features in multiple scenarios is the best way to have clarity on how effective an endpoint security product can be against the advances that attackers have made in recent years. Testing the single threat vector of PE detection rates alone is simply not enough.

Not only is it important to evaluate a product’s ability to protect against the bad, you must also test it against the good. High false positive rates and drawn out product “training” can be an indicator of a product that has limited detection capabilities or a product that will be difficult to manage and maintain within larger networks. True positive detection rates should be compared against false positive rates to see the bigger picture of a product’s effectiveness.

When testing, we must both think and act like the attackers we face, broadening our usage of the tools and techniques they use. This will aid us in validating the capabilities of an endpoint product’s ability to detect, protect, and remediate against these threats. A modern endpoint security product must be capable of breaking the attack chain at multiple points along its steps to compromise an endpoint in order to be prepared against the threats of tomorrow, today.

A Sophos technical paper January 2018 24 Testing Endpoint Security: An Introductory Guide

United Kingdom and Worldwide Sales North American Sales Australia and New Zealand Sales Asia Sales Tel: +44 (0)8447 671131 Toll Free: 1-866-866-2802 Tel: +61 2 9409 9100 Tel: +65 62244168 Email: [email protected] Email: [email protected] Email: [email protected] Email: [email protected]

© Copyright 2018. Sophos Ltd. All rights reserved. Registered in England and Wales No. 2096520, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, UK Sophos is the registered trademark of Sophos Ltd. All other product and company names mentioned are trademarks or registered trademarks of their respective owners.

18-01-28 NA-TP (2921-DD)