The presence of domain names created by a Domain Generation Algorithm (DGA) is a telling indicator of compromise.  For example, the domain xeogrhxquuubt.com is a DGA generated domain created by the Cryptolocker ransomware. If a process attempts to connect to this domain, then your network is probably infected with ransomware.  Domain blacklists are commonly used in security to prevent connections to such domains, but this blacklisting approach doesn’t generalize to new strains of malware or modified DGA algorithms.  We have been researching DGAs extensively at Endgame, and recently posted a paper on arxiv that describes our ability to predict domain generation algorithms using deep learning.

In this blogpost, we’ll briefly summarize our paper, presenting a basic yet powerful technique to detect DGA generated domains that performs far better than “state-of-the-art” techniques presented in academic conferences and journals.  “How?” you may ask.  Our approach is to use neural networks (more popularly called deep learning) and more specifically, Long Short-Term Memory networks (LSTMs).  We’ll briefly discuss the benefits of this specific form of deep learning and then cover our simple yet powerful approach for detecting DGA algorithms.

If you are unfamiliar with machine learning, you may want to jump over to our three part intro series on machine learning before continuing on. 

The Benefits of Long Short-Term Memory Networks

Deep learning is a recent buzzword in the machine learning community.  Deep learning refers to deeply-layered neural networks (one type of machine learning model), in which feature representations are learned by the model rather than hand-crafted by a user.  With roots that go back decades, deep learning has become wildly popular in the last four-five years in large part due to improvements in hardware (such as improved parallel processing with GPUs) and optimization tricks that make training complex networks feasible. LSTMs are one such trick for implementing recurrent neural networks, meaning a neural network that contains cycles. LSTMs are extremely good at learning patterns in long sequences, such as text and speech. In our case, we use them to learn patterns in sequences of characters (domain names) so that we can classify them as DGA-generated or not DGA generated.

The benefit of using deep learning over more conventional machine learning algorithms is that we do not require any feature engineering.  Conventional approaches generate a long list of features (such as length, vowel to consonant ratio, and n-gram counts) and use these features to distinguish between DGA-generated and not DGA-generated domains (our colleague wrote about this in a previous post). If an adversary knows your features, they can easily update their DGA to avoid detection.  This requires us, as security professionals, to go through a long and arduous process of creating new features to stay ahead.  In deep learning, on the other hand, the model learns the feature representations automatically allowing our models to adapt more quickly to an ever-changing adversary.

Another advantage to our technique is that we classify solely on the domain name without the use of any contextual features such as NXDomains and domain reputation.  Contextual features can be expensive to generate and often require additional infrastructure (such as network sensors and third party reputations systems).  Surprisingly, LSTMs without contextual information perform significantly better than current state of the art techniques that do use contextual information!  For those who want to know more about LSTMs, tutorials are plentiful.  Two that we recommend: colah’s blog and deeplearning.net, and of course our paper on arxiv.

What is a DGA?

First, a quick note on what a DGA is and why detecting DGAs is important.  Adversaries often use domain names to connect malware to command and control servers.  These domain names are coded into malware and give the adversary some flexibility in where the C2 is actually hosted in that it’s easy for them to update the domain name to point to a new IP.  However, hardcoded domain names are easy to blacklist or sinkhole.

Adversaries use DGAs to evade blacklisting and sinkholing by creating an algorithm (DGA) that creates pseudorandom strings that can be used as domain names.  Pseudorandom means that the sequences of strings appear to be random but are actually repeatable given some initial state (or seed).  This algorithm is used by both malware that runs on a victim’s machine as well as on some remote software used by the adversary.

On the adversary side, the attacker runs the algorithm and randomly selects a small number of domains (sometimes just one) which he knows will be predicted by the DGA, registers them, and points them at C2 servers.  On the victim side, malware runs the DGA and checks an outputted domain to see if it’s live.  If a domain is registered, the malware uses this domain as its Command and Control (C2) server.  If not, it checks another.  This can happen hundreds or thousands of times. 

If security researchers gather samples and can reverse engineer the DGA, they can generate lists of all possible domains or pre-register domains which will be predicted in the future and use them for blacklisting or sinkholing, but this doesn’t scale particularly well since thousands or more domains can be generated by a DGA for a given day, with an entirely new list each following day.  As you can see, a more generalized approach for predicting whether a given domain name is likely generated by a DGA would be ideal.  That generalized approach is what we’re describing here.

Figure 1 demonstrates the discovery process used by many types of malware.  In this case, the malware attempts three domains: asdfg.com, wedcf.com, and bjgkre.com.  The first two domains are not registered and receive an NXDomain response from the DNS server.  The third domain is registered and the malware uses this domain to call home.

Building the LSTM

Training Data

Any machine learning model requires training data.  Luckily, training data for this task is easy to find.  We used the Alexa top 1 million sites for benign data.  We also put together a few DGA algorithms in Python that you can grab on our github site.  We use these to generate malicious data.  These will generate all the data needed to reproduce the results in this blog.

Tools and Frameworks

We used the Keras toolbox, which is a Python library that makes coding neural networks easy. There are other tools that we like, but Keras is the easiest to demo and understand.  Keras is stable and production ready as it uses either Theano or TensorFlow under the hood. 

Model Code

The following is our Python code for building our model:

Yup, that’s it! Here is a very simple breakdown of what we’re doing (with links to additional information):

• We create a basic neural network model on the first line.  The next line adds an embedding layer.  This layer converts each character into a vector of 128 floats  (128 is not a magical number. We chose it as it gave us the best numbers consistently).  Each character essentially goes through a lookup once this layer is trained (input character and output 128 floats). max_features defines the number of valid characters.  input_length is the maximum length string that we will ever pass to our neural network.
• The next line adds an LSTM layer.  This is the main workhorse of our technique.  128 represents the number of dimensions in our internal state (this happens to be the same size as our previous embedding layer by coincidence).  More dimensions mean a larger more descriptive model, and we found 128 to work quite well for our task at hand.
• The Dropout layer is a trick used in deep learning to prevent overtraining.  You can probably remove this, but we found it useful. 
• This Dropout layer precedes a Dense layer (fully connected layer) of size 1. 
• We added a sigmoid activation function to squash the output of this layer between 0 and 1, which represent, respectively, benign and malicious. 
• We optimize using the cross entropy loss function with the RMSProp optimizer. RMSProp is a variant of stochastic gradient descent and tends to work very well for recurrent neural networks. 

Preprocessing Code

Before we start training, we must do some basic data preprocessing.  Each string should be converted into an array of ints that represents each possible character.  This encoding is arbitrary, but should start at 1 (we reserve 0 for the end-of-sequence token) and be contiguous. An example of how this can be done is given below.

Next, we pad each array of ints to the same length.  Padding is a requirement of our toolboxes to better optimize calculations (theoretically, no padding is needed for LSTMs). Fortunately, Keras has a nice function for this:

maxlen represents the length that each array should be.  This function pads with 0’s and crops when an array is too long.  It’s important that your integer encoding from earlier starts at 1 as the LSTM should learn the difference between padding and characters.

From here, we can divide out our testing and training set, train, and evaluate our performance using a ROC curve.

Comparisons

We compared our simple LSTM technique to three other techniques in our arxiv paper.  To keep things simple for this blog, we only compare the results with a single method that uses bigram distributions with logistic regression.  This technique also works better than the current state of the art (but not as good as an LSTM) and is surprisingly fast and simple. It is a more conventional feature-based approach where features are the histogram (or raw count) of all bigrams contained within a domain name. The code for this technique is also on our github site.

Results

We are finally ready to see some results!  And here they are:

Nice!  An AUC of 0.9977 with just a few lines of code! All of this is featureless with a simple and straightforward implementation.  We actually did a much deeper analysis on a larger and more diverse dataset and observed 90% detection with a 1/10,000 false positive rate, and this can be combined with other approaches outside the scope of this post to improve detection even further.  With our LSTM, we even did quite well on multiclass classification, meaning we could classify a piece of malware just by the domains it generated.  

Conclusion

We presented a simple technique using neural networks to detect DGAs.  The technique uses no contextual information (such as NXDomains or domain reputation) and performs far better than state of the art. While this was a brief summary of our DGA research, feel free to read our complete paper on arxiv and explore our code on github.  As always, comments and suggestions are welcome on our github site! 

A new 0day against the popular browser Firefox was revealed yesterday which specifically targets the popular “Tor Browser” project, a favorite of Tor users. The Endgame Vulnerability Research & Prevention team quickly analyzed the exploit from the original post, as well as a clean version of reduced JavaScript. 

This vulnerability appears to be a fairly typical Use-After-Free (UAF) when animating SVG content via JavaScript. In general, when exploiting UAF vulnerabilities there are a few key steps to gain code execution, which also occur here. The code first must create a situation where an object is allocated and used. Next, the memory of the process must be arranged so that when the “use after free” happens, code execution is gained.

In this exploit the initial HTML page includes JavaScript to first set up some global variables used to communicate to the initial page as well as a Web Worker thread responsible for the majority of the exploit, including heap grooming, memory reading/writing, ROP creation, and payload storage.

In the cleaned version of the worker JavaScript it is evident that the exploit first creates three utility objects. First, the Memory class is used to precisely read and write arbitrary virtual memory. By exposing a few functions it gives the exploit writer a clean interface to bypass ASLR, as well as store the ROP and payload into memory. The PE class is next. This is designed to dynamically resolve import functions for use in the ROP chain. The final helper class is ROP. Its purpose is to dynamically scan memory for ROP gadget bytes and generate a ROP chain. This is done so the author can target multiple versions of Firefox without requiring version-specific information beforehand.

The bulk of the worker thread is designed to drive the exploitation in the following steps.

1. Prepare memory by allocating a large number of objects to address 0x30000030.

2. Trigger the usage of the free memory in the original exploit function which will corrupt the allocated heap blocks.
3. Use the memory class to leak the base address of XUL.dll.
4. Use the PE class to resolve the import address of Kernel32.dll!CreateThread.
   

5. Dynamically  construct the ROP chain using the ROP class.
   

6. Store the addresses of the ROP chain and payload in memory.
7. Trigger the control flow hijack that calls the stack pivot to initiate the ROP chain.
8. Gain code executation and execute the payload stored in the JavaScript variable “thecode”.
   
   
   

While this vulnerability was surely discovered while fuzzing, the exploit writer wasn’t a novice. The use of the helper functions to dynamically build the payload is of moderate skill. 

Prevention

After analyzing the exploit we quickly wanted to determine how our Endgame exploit prevention techniques would do against this never-before-seen vulnerability and exploit. 

Endgame has two distinct approaches to exploit prevention. One uses our novel Hardware-Assisted Control-Flow-Integrity (HA-CFI) that can predict when a branch misprediction is about to execute malicious instructions. The other consists of dynamically inserted checks that are performed during program execution.

When testing HA-CFI against exploits, we really want to catch the exploit before that ROP chain. This gives the defender an earlier place to determine whether something “bad” is about to happen. In this instance, because we know this UAF will eventually alter control flow, we were able to successfully detect that first change.  Using IDA, we have visualized the detection information straight from HA-CFI's alert. The source is the exact location of the control-flow hijack, and the destination is the beginning of the ROP chain. It is important to note that we block the destination address from ever executing.  

HA-CFI Source

HA-CFI Destination

Pretty neat! As an added bonus it helps us when reverse engineering exploits because we know exactly where the bug is.  

As mentioned earlier, we also have a dynamic ability to detect exploits as well. We call this DBI, for Dynamic Binary Instrumentation. When talking about exploit prevention, there is early and late stage detection. Late detection is typical of most exploit prevention software. For an experienced exploit writer, the later a detection the easier it is to bypass. This is why it is essential to detect exploits as early as possible with innovative techniques such as HA-CFI and new DBI checks.

Our recently released DBI prevention check has proven to detect early against this vulnerability. The new protection is designed to detect when an attacker is attempting to dynamically resolve PE imports, and construct a ROP chain. By doing this we actually catch the exploit in Step 4 above. Below is some output from a debug version of the software showing exactly what happened.

You can see that the exploit tried to read the header of xul.dll (base address 0x695c0000). And if we disassemble the source of the read we see an executable JIT page making the offending read.

Stay tuned for the next release, where some of our latest research is designed to catch exploits even earlier, in Stage 1.

Conclusion

At this point, 0days should not surprise anyone. They have been, and will be, a regular occurrence. However, in this case targeting Firefox and Tor is particularly unique, as Tor is often used for illegal purposes, and exploiting the user's browser is a quick way to “de-anonymize” the user. Also, unlike most exploit kits, this exploit doesn’t appear to be highly obfuscated, which also differentiates it from other 0days.

Mozilla should be releasing a patch today or tomorrow, and users are urged to upgrade if they are using Firefox. In the meantime Endgame users are protected, and everyone else should disable JavaScript.

Identifying outliers or anomalous behavior depends heavily on a robust and credible understanding of those baseline characteristics within a network. Normal behavior and attributes vary significantly and are unique to each environment. Any efforts to structure the baseline may include essential factors such as temporal and geographic considerations, number of users, file types, approved applications, and so forth. In the past, we have referenced baseline and gold image usage to reduce false positives. Since so much of outlier detection and hunting rests on a solid foundation of understanding these baseline characteristics, it is useful to devote some time to this and how to use gold images for hunting. When available, this is extremely important and impacts every aspect of the hunt.

Baselining the Hunt

So what is the most useful baseline for hunting? Most IT staffs start with an OS standard build, and expand it to include additional applications approved for internal company usage. The gold image is defined as this clean slate prior to any user interaction. By comparing workstations to the baseline image, you can simply perform the delta analysis to help hone your hunt. This is especially important if your users are unable to install new software or don’t commonly do so, as anything that deviates from that baseline gold image might be an anomaly worth investigating. Even if this analysis determines the file or application is benign, it may surface a policy violation. This sounds pretty simple, but like any hunting approach, there is a level of grooming that is required to reduce false positives in your environment. Baselining is straightforward in principle but can be very difficult within heterogeneous environments.

Tips to Help Baseline Your Environment

While there are numerous ways to baseline your environment, SANS wrote a great white paper on it which is still useful today. However, you can’t keep the same baseline forever, and it is imperative to keep this image updated to stay current and avoid noise in the analysis. For instance, if you aren’t updating your baseline with routine OS updates, you could end up comparing different Windows machines with varying updates – which will cause many false positives.

In the end, if are you able to keep an actively up-to-date baseline image, then what comparisons should be prioritized between the baseline and active image? It is far too complicated and inefficient to start comparing every system file and running process.  These comparisons are riddled with false positives, so it’s important to only compare artifacts worth investigating. As we’ve previously written, any discussion of malware quickly turns to the challenges of persistence. So why not compare only persistent files? This is a much more manageable approach which entails only collecting persistent artifacts in our baseline and then comparing differences. This will more broadly illuminate potentially suspicious persistence items. Even if you are worried about user installed applications, outlier analysis will assist you, assuming that there is some consistency in different business units at your company. As always this consistency may not exist, and introduces an additional factor for consideration when building your baseline.

From Baseline to Hunt

Now that you have established your baseline, there are many open-source methods for conducting in-depth delta analyses to help guide the hunt. While the list of approaches is long, it’s most useful to start with Powershell and SysInternals Autoruns. To do this, simply collect persistent files using sysinternals on your gold image and store those results. Next, you could execute remote scripts to collect additional autoruns collections in your environment (check out our previous blog for more information on Hunting on the Host). Compare the results of these scripts to your gold image and highlight the differences. You might get lucky and find something interesting without using any logic!

Here is a quick example of how to compare MD5 hashes from persistent files:

1. On the gold image execute: PS>.\autorunsc.exe –a * –h | select-string MD5 | sort-object -unique > baseline-autoruns-output.txt
2. On the target host execute: PS>.\autorunsc.exe –a * –h | select-string MD5 | sort-object -unique > target-autoruns-output.txt
3. Compare: PS>compare-object -ReferenceObject $(get-content .\baseline-autoruns-output.txt) -DifferenceObject $(get-content .\target-autoruns-output.txt

To optimize your chances of success, you should put some logical thought into what you collect. If you store too many variables, it simply becomes too unwieldy for manual analysis, while too few risks omitting some key concepts. In the above example, we simply looked at MD5 hashes and only examined unique occurrences of a hash, but you could expand this logic. Starting with the persistent location is a great first step, but you should also consider expanding to hashes, filenames, signer information, etc. as additional useful data to enhance your comparison. If you need to utilize outlier analysis, you may want to include counts as well. There are plenty of third party applications that may not be in your baseline, but will be installed by your users. Let’s just hope malware isn’t installed broadly to ruin our outlier analysis!

Baselining with Endgame

Manually constructing that gold image can take significant time, especially at the enterprise scale and if there are different environments across business units. Using Endgame, you can create a baseline by investigating a clean image. As our previous posts and videos have shown, an Endgame investigation is an aggregation of hunts or surveys to include persistence, process, network, applications, user surveys, and more. Now with this baseline investigation, we can survey those production workstations and compare.

Rather than using our UI, in the referenced video I’ll show how we can do all this using our RESTful API in a few simple steps. As we hunt with Endgame, each investigation is given a unique UUID. Using the UUID from the baseline investigation and our target system investigation, we can compare all the tasks and collections that were executed through the Endgame platform. All of our collection data is stored as JSON, which enables these simple comparisons. For instance, you can look for those pesky persistent files that were not in the baseline. Any differences you find may indicate something malicious.

Conclusion

A solid baseline is necessary to executing hunts based on finding deviations from an established baseline. This approach can quickly help identify those key areas that look suspicious and reduce false positives in relatively homogenous environments. Unfortunately, most of us don’t have the luxury of obtaining a snapshot of an enterprise environment, so we need a shortcut to creating this baseline quickly and precisely to get into the more interesting aspects of the hunt. Endgame’s Investigation feature provides this shortcut, intuitively allowing you to compare the baseline investigation against an investigation with the new tasks and collections, providing a quick means to exploring any differences. For us, the API turns into an analytic haven, helping us structure that baseline and quickly leading us to potential malicious activity.

Last month, as much of the world’s attention was elsewhere, the Chinese government announced their new cybersecurity law.  While the new law ostensibly was adopted to increase security, a range of features have been criticized by human rights and multinational corporations alike. Indicative of China’s push for cyber sovereignty— complete government control of the internet within their borders — the law requires (among other things) network operators to disclose the identities of users and corporations to adhere to data residence requirements, including potentially turning over source code or information on Chinese citizens.  

These objectives were reiterated a few weeks later at the World Internet Conference (WIC) held in Wuzhen, China on November 16, which provided another platform for President Xi Jinping to reiterate his push for cyber sovereignty, saying that the “internet is the common home of mankind”, while also arguing that “we should respect the right of individual countries to independently choose their own path of cyber development”. Increasingly, cyber sovereignty is simply a Trojan horse for greater censorship, surveillance, and an infringement on civil liberties.

The demand for increased state control is by no means limited to China. Russia’s new cybersecurity doctrine signed on December 6th articulates its strategy of disinformation, while also similarly tying the growth of security threats to the necessity for stronger management and segmentation of the internet within Russia. To a lesser extent, this is also occurring in democracies. The U.K.’s Investigatory Powers Bill or the United States’ Rule 41 both grant additional monitoring and search capabilities to the government, alarming many civil rights groups. These are far less extensive than China’s new law or Russia’s doctrine, but they are indicative of the growing trend toward internet segmentation and monitoring. In their 2016 Freedom of the Net report released in November, Freedom House found an increase in global internet censorship coupled with the sixth consecutive year of decline in internet freedom. It should come as no surprise that this has all occurred as the United States’ soft power has declined over the last two decades, and liberal democracy has increasingly come under threat.

Aspirations of a free and open internet have guided the development of the internet for decades. This has happened organically thanks to technological innovation, grassroots movements, and the natural human thirst for information. Unfortunately, we are at an inflection point, and all of this is under attack. The next decade will be critical as over half the world’s population go online for the first time, but may encounter increasing restrictions, disinformation, and government control.  Absent a major push by the United States government and corporations - who have historically been the global advocate for internet freedoms -  global internet Balkanization, surveillance, and censorship may well define the future of the internet. 

Global Expansion of Cyber Sovereignty

As I wrote earlier this year, internet Balkanization is threatening the multi-stakeholder model which has fostered internet freedoms. The growth of cyber sovereignty is not limited to certain countries or regions; it is a global phenomenon. Predictions of the demise of the nation-state’s power were yet again short-sighted, as governments increasingly assert their control of the internet. In many regards, 2016 may well be viewed as a tipping point toward a Balkanization of the internet. To be clear, the growth of cyber sovereignty is not limited to the usual suspects - China, Russia, Iran, North Korea. As events of 2016 alone have demonstrated,  governmental internet control and intervention is much more widespread.

• The attempted coup in Turkey: In an interesting twist, President Recep Tayyip Erdogan, known for pro-censorship leanings, took to social media to call his eight million followers to take to the street to protest the attempted coup. His online appeal via FaceTime impacted the various opposition groups in a way unattainable through other media. Simultaneously, Erdogan may also have clamped down on social media during the coup and invoked censorship following the coup as part of his purge. Last month, Erdogan was back at it again, censoring social media to help suppress protests.
• Brazilian ban of WhatsApp: For about 72 hours, fears of the increasing Brazilian censorship were confirmed with the ban on WhatsApp. This followed a similar ban in late 2015, as well as the imprisonment in March of a Facebook executive for refusing to hand over data.
• Ethiopian drought and protests: Facing one of its worst droughts in 50 years, Ethiopia’s government strategically shut down internet service across the country, both to prevent future protests as well as to prevent coverage of ongoing protests, such as those in Oromia.
• Global social media censorship: As the Freedom House report makes extremely clear, social media is under attack in various forms across the globe. In May, Vietnam blocked Facebook as a push to control protests over environmental damage caused by waste from a steel plant. Indonesia implemented its 2014 law to “promote safe and healthy use of the Internet” as justification for blocking both radical terrorist sites, as well as social media sites like Tumblr, and video sites like Netflix. The Bangladesh Telecommunication Regulatory Commission ordered the blocking of 35 news and social media sites, which followed the complete shutdown of the internet a few days earlier. And of course, Russia is an expert in this information control, but until blocking LinkedIn in November, had refrained from social media censorship.

• Expanding spheres of influence: Of course, it would be naive to assume that many of these tactics used domestically would remain domestic. In Ukraine, which remained a target of the Russian propaganda machine (often referred to as trolls), social media and journalists faced increasing censorship and harassment (and, in at least one case, death) due to their reporting. China similarly extended its domestic tactics abroad, releasing its censorship trolls into Taiwan around the January election to attack Taiwanese independence via Facebook and other social media.
• A Monopoly on (Dis)Information: A striking aspect across all of these examples is the integration of factual information with disinformation, as well as the blocking of information that projects negatively on the host government. The public now not only has to contend with gaining access to information, but once they do, it is increasingly difficult to separate fact from fiction (it’s perhaps fitting that Oxford Dictionaries names “post-truth” the 2016 word of the year). These governments are controlling the information narrative not only to solidify their own control, but also to increasingly extend their control of the narrative outside their own sovereign borders.

A Leadership Vacuum

We cannot take for granted that the internet will continue its trajectory of growth and expansion. As is increasingly evident, the internet is by no means void of interstate power politics, but is rather a growing venue for them.  The more plausible scenario is the billiard ball model of international relations, with self-interested states competing against each other. In fact, this is only going to grow in complexity as many state-proxies (including terrorist and criminal networks such as the Syrian Electronic Army) carry out state objectives, with a strong emphasis on control and censorship. Instead of a free and open internet, we are seeing the expansion of autarkic policies that not only impact human rights, but also harm the interconnected, global economy that spawned the largest decrease in global poverty in history.

All of this is occurring within a global leadership vacuum, leaving states with less than pure intentions rushing to fill the void. The US remains mired in decades-old conversations about encryption and information sharing, net neutrality is under attack, and global internet governance increasingly reflects the interests of the growing coalition of authoritarian states. All the while, US soft power continues declining, as many efforts purporting an open internet seem shallow at best and hypocritical at worst following the Snowden revelations and WikiLeaks.

This must change. Last month’s WIC was a missed opportunity for US corporations to speak out against China’s new law. There is simply too much at stake to allow authoritarian governments to fill this leadership vacuum with increased censorship, surveillance, and control. The United States cannot just mourn the demise of the internet, but must fight for it through international organizations, domestic policy, and, perhaps most importantly of all, by leading by example.

This is not only a concern for those two-thirds of the world’s internet users who are currently under censorship. Rather internet Balkanization is likely to shape geopolitics, the global economy, and human rights for decades to come. Unless the United States acts swiftly and forcefully to protect internet freedoms, cyber sovereignty may all too easily become the new norm. Despite its decline in soft power, the US has been the world’s strongest advocate for internet freedoms since the 1990s. If the US government and corporations do not advocate for the global diffusion of a free and open internet, who will?   

On October 7, 1996, the Pentagon publicly attributed – without repercussions – a vast digital data breach and espionage to the Russians, later dubbed Moonlight Maze.  Fast forward twenty years to the date, and President Obama publicly attributed the DNC digital attacks to Russia. Attribution is important as it publicly associates malicious activity with specific actors, while often providing evidence linking the offenders to a specific attack. Until today, there had yet to be any coherent retaliatory actions for Russian data intrusions and dumps targeting our democratic institutions.

Despite all the recent high-profile breaches, this was only the fourth time in recent years that the US government publicly attributed a digital attack. The first recent case of attribution occurred in 2014, and resulted in the indictment of five PLA officers for digital espionage. In 2015, following the Sony breach, economic sanctions were issued against North Korea. Earlier this year, the US government attributed attacks targeting banks and a dam to Iran, which resulted in the indictment of seven Iranians. Given these precedents, it seemed only a matter of time before the US responded to Russian intrusions into the integrity of our elections.

Earlier today, the Statement by the President outlined an executive order containing a multi-pronged approach to the sophisticated attacks targeting a bedrock of democracy. While likely just a first step, this is long overdue, and indicative of a whole of government, strategic approach to digital attacks. Let’s break down the key points of the statement, which comprise the key aspects of a declaratory policy – the offending behavior, supporting evidence, and the repercussions.

1. Identifying the Malicious Activity– Part of any declaratory policy requires clear specification of the offending behavior to justify the response, but it also aims to deter future behavior. The Statement by the President denotes Russian interference in the election process at the highest levels, including data breaches and dumps, as well as increased harassment of US diplomats in Russia.
2. Providing Evidence – Technical details outlining Russian activities were also released in conjunction with the Statement by the President. These range from spear phishing campaigns to exploitation of injection flaws and other vulnerabilities. DHS recommends a range of defensive measures against the Russian campaigns, helping specify how US organizations and those around the world can protect against the global campaign.
3. The Repercussions

• Sanctions– The US already imposed financial and economic sanctions against Russia due to the invasion of Crimea, largely focusing on Vladimir Putin’s inner circle and the defense, banking, and oil and gas industries. Today’s sanctions augment the Crimean sanctions, and target nine entities and individuals with links to the GRU and FSB, Russia’s largest intelligence agency and state security organizations.
• Disclosing Intel Operations– This next step appears unique when it comes to a response to malicious digital activity. The State Department will close two Russian compounds used for Russian-intelligence in Maryland and New York.
• Eviction– President Obama declared thirty-five Russian intelligence operatives persona non grata. Dating back to George Washington, this implies that the thirty-five operatives and their families have 72 hours to leave the United States. 

Many may argue that it is too little too late, but there is significant risk of escalation that must be weighed in conjunction with any response. The cyber domain does not occur within a vacuum. A digital tit-for-tat is not the only option. Depending on the magnitude of the attack, a government can unleash the entire arsenal of statecraft, including everything from diplomatic demarches to a military response. When major power politics (including nuclear weapons) are involved, it is essential to minimize risk escalation and explore all possible means to provide a deterrent effect without engaging in warfare.

Today’s statement not only specifies the initial US response to Russian hacking, but also is an attempt at global leadership in clarifying the appropriate standards of behavior within cyberspace. The Statement by the President emphasized the point that Russian activities are, “In violation of established international norms of behavior”. The US continues to seek to establish norms through international governmental organizations such as the UN and G20, as well as bilaterally such as last year’s US-Sino cooperative agreement. These various forums provide an opportunity to define which targets are deemed off limits (e.g. critical infrastructure, commercial IP), while reinforcing a focus on internet freedoms.

Unfortunately, establishing these essential norms does not occur simply through agreements, which alone are not enough as they suffer from collective action problems and compliance. They require leadership and repercussions when these norms are violated. The three most recent cases of public attribution set the foundation for the kinds of behavior which are deemed in violation of international norms, while illuminating the repercussions as well. Today’s statement further established this foundation by expanding upon Russian sanctions, while also including additional retaliatory consequences against intel operations and diplomats, and disclosing the technical attributes to help protect domestic entities and global allies.

While this is an essential step, the US must take stronger leadership in pushing forth these global norms, which are extremely nascent and ill-defined to date. This requires cooperation through various forum, but just as importantly involves clear specification and repercussions if those norms are violated. Absent any repercussions, nation-states and non-state actors alike will continue to escalate digital attacks unabated.

Looking ahead into 2017, democratic institutions and freedoms remain under attack. Our European allies (e.g., France, Germany, Netherlands) have elections coming up next year. Over the last month, many have already expressed concern over Russian intervention. Today’s Statement by the President notes additional steps will be taken to safeguard democratic institutions. This includes additional private and public activities, as well as a report to Congress that likely will provide additional insight into Russian activity, as may a special investigation into cyber warfare that Senators McCain, Graham, Schumer and Reed have demanded. It is essential to continue to build up and, when possible, disclose the evidence to help counter the information warfare that has become embedded within the fake news cycle, which is a key component of Russian strategy. Moreover, the US must continue to seek the dual-pronged approach of establishing norms, seeking to define acceptable rules of the road while further solidifying a declaratory policy when those formal and informal norms are violated. As these events continue to unfold, check back next week for further, technical analysis of the Russian attacks. I also will present more on this and the challenges but necessity of norm development at next month’s Enigma conference.

On December 29, 2016, the United States Department of Homeland Security (DHS) and Federal Bureau of Investigation (FBI) released a joint analysis report (JAR) detailing, in their words, “tools and infrastructure used by the Russian civilian and military intelligence Services (RIS) to compromise and exploit networks and endpoints associated with the U.S. election, as well as a range of U.S. Government, political, and private sector entities”.  While the report doesn’t name the DNC outright, it is clear that the technical information in the report is focused on data associated with the DNC intrusion and which was publicly attributed to two different state-sponsored Russian hacking groups. 

The report, which dubs the operation “GRIZZLY STEPPE”, has been consumed and analyzed by various members of the information security community at large. The report basically has three parts: 1) what I take as an official government statement that the tools and groups listed in the Alternate Names section are in fact RIS; 2) a set of indicators which FBI/DHS thought would help defenders detect some segment of the activity; 3) a set of guidelines to harden networks against RIS activity.

While the report has received some positive feedback, the majority of feedback has been negative.  Many of the critiques are valid, focusing on the indicators themselves. This is where the JAR fell short and could easily be improved.  It was lacking in several key technical and contextual details making it vague and difficult to derive substantial value.  To that end, and given that we are anticipating future JARs, I’ll walk through some reasons why the technical indicators were not useful and suggest small and hopefully achievable changes which would make the next public JAR more actionable for defenders.

Critiques of the Technical Indicators

While the report provides a clear statement of attribution, the technical information included was not very high-value. The most significant technical weaknesses were as follows.

Noisy IP addresses

The report included 876 unique IP addresses to search as “indicators of compromise” for malware command and control (C2) or data exfiltration infrastructure. The problem is that a substantial amount of the indicators belong to websites and online services that are used legitimately by a huge amount of people around the world, such as websites and services owned by Yahoo, Google, Dropbox, Tor, and various cloud providers.  This will create many false positives and potentially panic in organizations who look for connectivity to these IPs and jump to the conclusion that they’ve been hacked by the Russians.  If the Russian-sponsored hackers are using potentially high traffic IPs belonging to organizations like Yahoo for C2 or data exfiltration (which is completely feasible), then the report should include that as context (see below for more on that).  We are left wondering whether FBI/DHS were aware that some of the false positives (FPs) would be noisy and FP prone.

Included only one Yara signature, not specific to RIS activity

The report includes a single Yara signature.  Yara is universally used by security researchers to perform byte sequence analysis of binary files.  Yara signatures are often used to identify fingerprints of sorts for malware which are less brittle than using unique hashes, filenames on disk, or other IOCs.  The single Yara signature in the report appears to be for a PHP web shell (backdoor) likely used by an attacker once they’ve compromised an external-facing web server. There are certainly a substantial number of tools used by the RIS actors, and this signature was the only one included in the report.  Additional signatures would be welcome.  More problematic, the sample identified with this signature doesn’t even necessarily implicate RIS actors specifically.  It is used by a variety of actors and cybercriminals and can actually be downloaded here and used by anyone.  If this signature hits on a file on your webserver, you should be concerned and remediate, but it wouldn’t be conclusive proof that you were hacked by the Russians.

Lack of context

The majority of IP address indicators provided in the DHS report include nothing more than the sentence, “It is recommended that network administrators review traffic to/from the IP address to determine possible malicious activity.” The GRIZZLY STEPPE report does not include any sort of time window, description, or severity, making them less actionable by security teams around the world.  This is an especially big problem since, as mentioned above, many of the IPs seem to be multi-user or subject to changing ownership over time.  A hit outside of the time window when FBI/DHS believed the IP to be in use by the Russians would be a false positive.  

Areas of Improvement

The following are specific recommendations that would drastically improve the value of the technical details of the GRIZZLY STEPPE report.

Curate IOCs

The United States Intelligence Community (IC) has the resources and expertise to differentiate between high-value and useless indicators. All indicators handed to the public should be high value.  They could prioritize the indicators, explicitly calling out the indicators that will provide the most value and notate which high-value indicators are prone to false positives or shared infrastructure.  Future reports should also include which indicators may have been compromised infrastructure. That is, which ones are random servers on the Internet compromised and used as a means to an end towards the real target, such as the DNC.  Such actor tradecraft is quite common.  On the other hand, they should specify which indicators were believed to have been used solely  by RIS. The list provided in the report contains noise and seems to lack curation, which undermines confidence in the entire list, and has been used in attempts to refute the attribution. Confidence would increase with slightly more information.

Contextualize IOCs

Future reports would be greatly improved by including the time period the malicious activity would have taken place and the lifespan of each indicator. Is the activity ongoing or should security teams dig through historical netflow logs from 2012 to find malicious activity?  Did attacks take place via that infrastructure for a year or a week?  Which week?  Will attacks be coming from a VPS rented from a cloud provider or a compromised website? How many indicators are proxies or Tor exit nodes? The lack of context will make it difficult to understand how to interpret hits, sift out FPs, and discover actual evidence of RIS activity, which must have been the point of providing the IPs in the first place.

Actionize the nomenclature table

The alternate names table on page four of the GRIZZLY STEPPE report potentially confirmed years of claims from commercial threat intelligence providers, but in its current format is completely useless and possibly even counterproductive from a technical standpoint. A few pieces of information from the IC could be a force multiplier on the value of the naming convention table. Additional information should at a minimum: include a breakdown of which groups use what tactic or implant; cite existing commercial threat intelligence reports; provide insights on several key procedures each actor consistently employs; and link hashes and IPs to a group or toolchain.  Stating that a given group named by industry is RIS is great.  When possible, the report should specify what they think commercial threat intelligence got right in those reports so we can more confidently use those IOCs.  

Conclusion

To be very clear, I applaud the government’s efforts to get information about this activity into the unclassified realm.  This report is probably the result of significant effort by many dedicated and talented individuals.  The reception has been overly harsh and often focused on the attribution question, which I think is missing the point. The technical IOCs aren’t intended to provide evidence of attribution, but to enable detection of RIS activity.  

Government sources need to be kept secret for various very good reasons. The IC can’t always reveal specifically how they came to a conclusion when attributing an event or series of compromises. The United States’ IC pours billions of dollars into cyber security research and development and is the most sophisticated in the world, but is also conservative in revealing sources by nature. It is possible, for instance, that the sources of the information that led to the attribution claims are still being actively used.  It may even involve human sources who would be put in grave physical danger should the information come to light.  In some cases, it is more important to continue to observe an adversary than to arm the public with the irrefutable proof they used to declare with high confidence that it was Russian activity.  

However, if the IC is going to publish a technical report specifically calling out state-sponsored hacking activity, the report needs to be actionable. The technical details need to include context and be resilient to false positives.  They can empower the private sector further by citing or confirming specific reports and research already available in the open source. The GRIZZLY STEPPE report represents a welcome move by the IC to confirm and call out RIS hacking activity, but the report was lacking in several key technical details to provide substantial technical value to the private sector.  I look forward to the next JAR and hope it proves more actionable to better equip defenders against this global campaign.

There are many tricks to the tradecraft when analyzing unknown binaries, and it requires constant honing of skills to stay on top of the latest malware and campaigns. Solving reverse-engineering challenges is one way to keep your skills sharp. In our previous post, we discussed some tips from the Flare-On Challenge. Now we’ll take a deeper dive into one of the specific challenges (Challenge #2), walking through the “DudeLocker.exe” binary and a file called “BusinessPapers.doc”. This is a great use case for seeing how ransomware works on a basic level, and will provide some useful tips that you can implement next time you’re investigating an unknown binary.

Getting Started

When analyzing an unknown binary, you’ll usually be performing a dance between static and dynamic analysis. As a rule of thumb, always use separate virtual machines (VM) when doing these forms of analysis. Here’s an example of why it’s a bad idea to do both on the same VM. Imagine you have performed hours of static analysis and decided to run the binary. Oh no! It took a code path you didn’t account for and has now encrypted all the files on your box, including your static analysis notes/files. That definitely is not an ideal scenario!

Due to the nature of unknown binaries, only execute/run them in a dynamic analysis VM to prevent interference with your static analysis. This will additionally give you the freedom to run the binary, debug it, and revert to prior VM snapshots whenever needed. For instance, we reverted to prior snapshots after executing/running “DudeLocker.exe” a few times to get a feel for what its behavior was and to start with a clean system each time.

Pro Tip: Take advantage of how Windows recognizes file types and remove the file extension prior to transferring the binary into the static analysis VM. This will prevent Windows from executing it even if double-clicked.

With the infrastructure established, the initial step towards analyzing an unknown binary is to determine the file type or in our case what kind of files “DudeLocker.exe” and “BusinessPapers.doc” are. On Mac/Linux the ‘file’ command comes in handy:

The ‘file’ command determines the file type by looking for “magic bytes” within a file. These “magic bytes”, which are described in more detail elsewhere, are frequently unique to a specific file type and can usually be found at or near the beginning of a file.

The file “BusinessPapers.doc” is not recognized as any particular file type even though its extension is “.doc”; rather, it is shown to be “data”. However, “DudeLocker.exe” is recognized as a 32-bit PE executable. If you were to take a slightly closer look at the beginning bytes using the ‘xxd’ command, which displays a hex dump of a file, you can easily see the “magic bytes” are “MZ” or 4D 5A. 

To understand how the ‘file’ command knows other attributes about the file such as its architecture type (32-bit), you’ll need to understand the file format in more detail. In the reverse-engineering world, you likely need to become very familiar with files that execute. On Windows these are files that follow the PE format. On Linux they are files that follow the ELF format and on Mac, Mach-O. To get familiar with the PE format we highly recommend Iczelion’s PE tutorials as well as this Microsoft article.

Light Static Analysis: Quick Look

“DudeLocker.exe”

Generally, once you’ve established the type of file you’re working with, you can perform some light static analysis and look for interesting nuggets of information prior to running it dynamically. We know “DudeLocker.exe” is a Windows executable. Some tools to use for static analysis of Windows executables areCFF Explorer, Detect It Easy,Resource Hacker, and IDA Pro/Free.

A great way to start static analysis on any binary is the tried and true strings utility. There are many programs that can extract strings from a binary -- in Linux/Mac there’s even a ‘strings’ command. Strings found in a binary can sometimes leak precious information such as URLs, email addresses, passwords, packer names, registry key names, etc… and are worth exploring. We’ll use IDA Pro for the moment on “DudeLocker.exe” to view its strings.

Pro-Tip: When extracting strings from a binary, there will usually be a minimum length setting. Five characters are typically enough. Also be sure to specify all possible string types depending on what your strings utility is capable of extracting. In IDA Pro you can find: Ascii/C type, Unicode, and Pascal type strings.

Interestingly we see mentions of a “Briefcase” and an image name “\\ve_vant_ze_money.jpg”. Speculating early on, we know briefcases generally contain documents used for business purposes and “ve_vant_ze_money.jpg” sounds like some kind of ransom note as it resembles “we want the money”. We’ll see later on exactly how these come into play.

After viewing the strings of an executable, it’s a good idea to view its imports (part of the PE format). Imports are functions imported from external libraries that provide functionality to an executable and can shed some light on the binary’s potential behavior or capabilities. Let’s look at the imports for “DudeLocker.exe”, again using IDA Pro for the moment. 

From these imports we can get a feeling for some of the binary’s potential capabilities, including:

File enumeration

• FindFirstFileW
• FindNextFileW

System fingerprinting

• GetVolumeInformationA
• GetVersionExW

Resource access

• FindResourceW
• LoadResource

Read/Write files

• ReadFile
• WriteFile

Modify system parameters

• SystemParametersInfoW

Output debug messages

• OutputDebugStringW

Access specific folders via CSIDL

• SHGetFolderPathW

Use of encryption

• CryptDeriveKey
• CryptEncrypt

Perform hashing

• CryptCreateHash
• CryptHashData
• CryptGetHashParam

Pro-Tip: The ‘A’ vs ‘W’ at the end of import functions denotes whether the function uses ‘ANSI’ (typically ASCII) or ‘wide’ (Unicode) characters.

To the untrained eye these imports may seem innocuous, but if you look at the potential capabilities as a whole you can start to see how they might be utilized by “DudeLocker.exe” in general. For instance, what type of behavior would you suspect the following capabilities to express?

• File enumeration
• Read/Write files
• Use of encryption

These three capabilities are the minimum required to express some sort of ransomware behavior. While imports are not a guaranteed way of deriving behavior, as we’ve yet to execute “DudeLocker.exe”, it’s always good to think in terms of how the imports could be utilized, especially if used maliciously.

We could also have used a tool called CFF Explorer to view the imports of “DudeLocker.exe”. CFF Explorer is great for viewing an executable’s PE header information. Let’s use it to explore “DudeLocker.exe”. If we navigate to the “Section Headers” tab we can see it has a “.rsrc” section, which typically contains embedded resources. These resources can be anything from icons to images and in some cases even malicious files.

Whenever you want to know more about an executable’s resources, you can always turn to a tool called Resource Hacker. This tool is the one-stop shop for compiling, viewing, decompiling and recompiling resources for both 32-bit and 64-bit Windows executables. Let’s open “DudeLocker.exe” with Resource Hacker.

We see there is an “RCData”, or raw resource, with an ID of “101”. This might be the “\\ve_vant_ze_money.jpg” image we were hinted at in the strings. If we factor in the potential import capabilities -  file enumeration and encryption functions - “DudeLocker.exe” is starting to resemble some sort of ransomware. This would make sense, especially given the name of the executable which resembles “CryptoLocker”, a famous ransomware trojan introduced to the world in 2013 which was responsible for extorting millions of dollars from its victims.

“BusinessPapers.doc”

In the case you can’t determine a file’s type, it still has some useful properties you can observe. For instance, checking for the presence of strings, as we did for “DudeLocker.exe”, and the file’s entropy characteristics are good starters. High entropy (close to a value of 8 on a scale of 0-8) can be a sign of a packed/compressed/encrypted file.

A great tool for checking both strings and file/section entropy is Detect-It-Easy (also via github). It’s also useful for detecting file types, compilers used, potential packers, cryptographic functionality, and a lot more. Let’s see if it can recognize the file type for “BusinessPapers.doc” and view its strings as well as entropy.

According to Detect-It-Easy, “BusinessPapers.doc” has no recognizable file type, the strings appear to be gibberish, and it has high entropy. All of these are tell-tale signs of either packing/compression or encryption. Remember our initial observation of “DudeLocker.exe” being potential ransomware? Maybe this file was encrypted by it.

Light Dynamic Analysis: Run it and observe

Only so much information can be gleaned from light static analysis. To gain more insight into a binary’s behavior, it’s easiest to run it and observe what it does -- in a dynamic analysis VM, of course. In our case, we know that “DudeLocker.exe” is a 32-bit Windows executable and has some potential ransomware capabilities, so let’s run it and see if our current observations hold.

Some great tools to use when doing dynamic analysis are Process Monitor (ProcMon) and Process Explorer (ProcExp), both of which are included in the SysInternal Suite provided by Microsoft. Process Monitor provides a detailed event log of actions taken by the binary and Process Explorer provides a TaskManager type view of all currently running processes, making it easy to see if processes spawn or exit.

Additionally, since we saw the import “OutputDebugStringW” in “DudeLocker.exe”, we’ll also be using a tool called DebugView which displays any debug statements and is also included in Microsoft’s SysInternal Suite. Let’s begin the light dynamic analysis by using Process Monitor and DebugView to monitor the execution of “DudeLocker.exe”:

Pro-Tip: In ProcMon you can set up specific filters if you want to look for more details than are set by default. If you need even more detail about the execution flow of a binary, try API Monitor. It can get information regarding thousands of Windows APIs potentially called by an executable.

From ProcMon output it appears “DudeLocker.exe” accesses the Desktop, attempts to access a directory called “Briefcase”, and then exits. From DebugView output it seems we’re no longer reverse engineers, but more like software engineers taking a debug print statement approach to debugging.

The attempt to open the directory “Briefcase” on the Desktop failed, returning a “NAME NOT FOUND” error. Due to the almost immediate exit of the binary, we can assume that the binary requires a “Briefcase” directory on the Desktop to continue its execution. So let’s create an empty folder called “Briefcase” on the Desktop and re-run it.

Interesting. Now that we have the “Briefcase” folder on the desktop, “DudeLocker.exe” does something extra prior to exiting, it queries for system specific information (a technique usually called fingerprinting) as seen by the “QueryInformationVolume” event. In addition, the debug output says “I’m out of my element”. At this point we have no further clues as to what “DudeLocker.exe” requires in order to continue its execution.

Deep Static Analysis (Disassembler)

Once you’ve seen enough general behavior from an unknown binary or reach a dead end during light dynamic analysis you’ll typically want to take a deeper look into the binary statically. Let’s start our deep dive into static analysis of “DudeLocker.exe” via our disassembler of choice, IDA Pro.

Once in the disassembler you can choose to start your analysis generally one of two ways:

1. Start from the main/start function and work your way through the binary. This a top-down approach.
2. Start at an interesting string, code block, import function, or function and work your way backwards. This is a bottom-up approach.

Since we hit a roadblock after adding the “Briefcase” folder to the desktop, let’s find the string “I’m out of my element” seen from the DebugView output and work our way backwards through IDA.

Once you’ve found the string in IDA’s string view (shift + F12) you can double-click it to reach the string in the “.data” section. From here we can utilize the power of cross-referencing by pressing ‘x’ to see where this string is referenced in the binary. Following this backwards we can see how we would arrive at this execution path.

When doing a deep dive static analysis, it helps if you label functions and data as you go. In IDA this is done by pressing ‘n’ on a selected function or data name. Even if you don’t know what the function really does, a best guess label still helps as you can always re-label it with something more descriptive once you understand it better.

Pro-Tip: If you can’t understand the functionality of a function because there are other functions and data being referenced within it, it can help if you work your way bottom-up. This way, once you’ve labeled the lowest and simplest functions you’ll have a better understanding of what the functions above it do.

Going back to the observed execution path in “DudeLocker.exe”, we see there’s a function we’ve labeled “GetVolumeSerialNumber” that decides the fate of execution. Let’s see what the function “GetVolumeSerialNumber” actually does.

As the image above demonstrates, the function compares our VM’s File System volume serial number against 0x7DAB1D35. If our VM’s serial doesn’t match this expected value, the function returns 0 in EAX, causing the execution flow to go down the path that prints out the debug string “I’m out of my element” and exit. In order to make the execution continue, we’ll need some way to modify our VM’s volume serial number.

While we could jump over to our dynamic analysis VM and try to figure out what would happen if we forced our VM’s volume serial number to match, let’s stay in static analysis mode and try to figure it out ourselves.

If we follow the path that would be taken if the serial numbers matched, we notice a reference to some data blob and a function that has an XOR in it. Not always, but when you encounter a data blob and an XOR, there’s a good chance some XOR en/decryption is going on. This function, which we’ve labeled “DecryptSeedValue”, takes as parameters: a data blob, an output buffer, a volume serial number, and the length of the output buffer.

From the image above, we can see that the data blob is XOR decrypted using the volume serial number and stored in the output buffer. You could decrypt the data blob yourself now that you know the general algorithm and values being used via a script, or you could use dynamic analysis to see the decrypted blob -- we’ll use dynamic analysis later for this.

After this function you’ll start seeing other functions that utilize the following imports:  

 Diving into these could require a blog post in itself. We’ll leave it as an exercise for the reader to familiarize themselves with the Windows cryptography API, specifically how to use AES encryption in CBC mode. See this tutorial for some good code examples. An overview of these functions and this portion of program execution is as follows:

1. SHA-1 hash the decrypted data blob

2. Use the SHA-1 hash to derive an AES-256 key

3. Recursively encrypt each file (and each file in subdirectories) in the “Briefcase” directory:

         A. Derive a unique encryption key for the file:

             1. Get the file’s name (including extension) and convert to lowercase
             2. MD5 hash the lowercase filename
             3. Use MD5 hash as initialization vector (IV) for AES-256 encryption, thus creating a “unique key” per file

         B.  Encrypt the file:

              1. Open the file and read it in 16KB chunks
              2. Use the unique encryption key based on filename to encrypt each 16KB chunk
              3. Write the encrypted chunk of data back to the file

After all files have been encrypted in the Briefcase directory, “DudeLocker.exe” will look up a resource.  

Notice that the function FindResourceW is looking for a RT_RCDATA, or raw, resource with an ID of 101. Looking back at the Resource Hacker output, we can see the resource with ID 101 is the ransom note image we saw earlier! “DudeLocker.exe” will write this image to disk in the “Briefcase” directory and name it “ve_vant_ze_money.jpg”.

Then “DudeLocker.exe” will check if the operating system (OS) is Vista or higher by calling GetVersionEx and comparing the returned OSVERSIONINFOEX structure’s dwMajorVersion value against the value 5. A dwMajorVersion of 6+ indicates Vista+. Thus, if the current version is 5 or below, we’re not on Vista+. See this article for information about the OSVERSIONINFOEX structure and the differences in major vs minor version number. If the OS is Vista+, “DudeLocker.exe” will set the ransom note image as the desktop background and exit.

Recap

Let’s briefly recap what we know about “DudeLocker.exe”:

• The binary needs a directory on the Desktop named “Briefcase”

• The binary needs a volume serial number of 0x7DAB1D35 to continue execution and derive an AES-256 encryption key

• The binary will encrypt all files in the “Briefcase” directory using their filename as the IV for the AES-256 encryption algorithm

• The binary will look up the resource corresponding to ID 101 and write this to disk as “ve_vant_ze_money.jpg” in the “Briefcase” directory

• If on Vista+ it will set the ransom note image “ve_vant_ze_money.jpg” as the desktop background

The question now is what to do with the “BusinessPapers.doc” file. We suspect it’s been previously encrypted by this variant of ransomware, but how can we decrypt it?

Hopefully you’ve familiarized yourself with AES encryption and had the “aha moment”! AES is a symmetric encryption algorithm meaning that as long as we can derive the same key used to encrypt the file we can decrypt the file. Well, we know its filename and we know the expected volume serial number, thus we can derive the same key!

Additionally, if you also familiarized yourself with the Windows cryptography API, you’ll notice that both CryptEncrypt and CryptDecrypt share the same first 6 parameters:

The significance of these functions sharing the same 6 first parameters is that we can use CryptDecrypt in place for CryptEncrypt. Now we have a way of decrypting “BusinessPapers.doc”! To actually do this we’ll patch/modify the Import Address Table (IAT) of “DudeLocker.exe” by changing CryptEncrypt to CryptDecrypt.To patch a binary means to directly modify its contents either when it’s loaded in memory or on disk. This is easily accomplished using CFF Explorer and saving it as another executable.

 (CryptEncrypt in IAT)

(CryptDecrypt in IAT) 

Deep Dynamic Analysis (Debugger)

Once you’ve accomplished a deep dive in static analysis you’ll generally have a better understanding of the unknown binary. By performing dynamic analysis, you can validate your understanding of the binary. However, in some cases your static analysis might be too complicated to determine what a particular function does. Dynamic analysis can also be utilized in these situations to experiment with the difficult function by providing it various inputs and monitoring what output it generates.

We have a pretty solid idea of what “DudeLocker.exe” does and have patched the binary’s IAT to decrypt files instead of encrypt them. We could essentially run the binary and have it decrypt “BusinessPapers.doc” for us (making sure this file is in the Briefcase directory). However, there is still one last hurdle we must conquer -- forcing the volume serial number to be 0x7DAB1D35. To do this let’s open the patched binary with a debugger. We’ll be using x64dbg, which is an open source x64/x32 debugger for Windows.

Once opened, depending on your debugger and its preferences, it should hit a breakpoint either at the first system function that initialized the patched binary or at the entry point of the patched binary. If it doesn’t hit a breakpoint and continues to run, check your debugger’s preferences and make sure “Entry Breakpoint” is set and re-run it with the debugger.

The goal of opening the file in a debugger is so we can hit a breakpoint at the spot where the patched binary will compare the system returned volume serial number to the desired value 0x7DAB1D35 and dynamically modify the returned value to match.

However, before we start setting breakpoints it’s always good to know if the binary in question uses address space layout randomization (ASLR). If it does you might have to re-set your breakpoints each time you re-run the binary in the debugger and you might also have to rebase the binary in your disassembler to match the new image base address so your addresses match up in both the debugger and disassembler. An example of how to rebase your binary in a IDA Pro can be found here.

Pro Tip: If not using ASLR, the default base address for an .exe file is 0x400000 for 32-bit images or 0x140000000 for 64-bit images. For a DLL, the default base address is 0x10000000 for 32-bit images or 0x180000000 for 64-bit images.

Furthermore, some debuggers, like WinDbg, will allow you to set unresolved breakpoints. These are breakpoints that are defined by specifying an offset from the start of a function to break on. This bypasses ASLR because when a binary that uses ASLR is loaded into memory, even if the binary file is rebased, each instruction within the executable remains at the same offset from the base address. The only thing that changes is the base address the binary file is loaded at. To see if the binary uses ASLR check in the PE header:

• FileHeader -> OptionalHeader -> DllCharacteristics

And see if the following flag is set:

• IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE = 0x0040; //The DLL can be relocated at load time.

We can see in CFF Explorer that “DudeLocker.exe” does not use ASLR as “Dll can move” is not checked:

Since it doesn’t use ASLR we’re free to set breakpoints and rely on them. Let’s start by setting the following breakpoints: 

Pro Tip: Most debuggers let you set breakpoints via a breakpoint menu tab or by navigating to that address and manually setting it. X64dbg and Ollydbg both let you directly navigate to an address by pressing CTRL+g and manually setting a breakpoint by pressing the F2 key.

Once set, continue execution (typically F9 key) until a breakpoint is hit -- it should pause execution at 0x00401063. From here we can right-click and modify the topmost stack value (this corresponds to EBP-4 or the volume serial number returned by the system) to 0x7DAB1D35: 

If you single-step (typically F8 key), the following jump instruction should not be taken and EAX should be set to the value 0x7DAB1D35. Now if we continue execution (typically F9 key) until a breakpoint is hit we should pause execution at 0x00401AD1. We’re breakpointing here to point out the decoded data blob that is hashed and used as the AES-256 key. Specifically a pointer to this decoded data blob is in ECX at this point. If we right-click the ECX register and select “Follow in Dump”, we should see the value “thosefilesreallytiedthefoldertogether”. Pretty neat!

Let’s go ahead and let this binary run to completion by continuing execution (typically F9 key).

The background should be set to the ransom note image we saw in Resource Hacker previously (assuming you’re using a Vista+ OS) and if we extract the “BusinessPapers.doc” file and run the ‘file’ command on it again we should see it is no longer classified as “data”.  

That’s right, it’s a JPEG! Using command ‘xxd’ we can see it has the magic byte signature: FF D8 FF E0 nn nn 4A 46 49 46 00 01 (where “nn” can be any byte). If we rename the file to “BusinessPapers.jpg” and open the file we see the following image:

Awesome! We’ve been able to recover the previously encrypted file and found the flag for this challenge: cl0se_t3h_f1le_0n_th1s_0ne@flare-on.com

Conclusion

This blog post walked through the steps and mindset required to solve just one challenge within the 10-part 2016 Flare-On Challenge. Keeping in mind that this is only level 2, the later levels become much more difficult and present new challenges. By participating in reverse engineering and malware focused CTFs such as the Flare-On Challenge, you can quickly gain skills and expose yourself to different problem sets that you would otherwise only encounter in the real world by analyzing malicious binaries of the same complexity.

We covered the basic fundamentals that will serve as a useful starting point for anyone interested in developing or honing their reverse engineering skills. Some of the important concepts we discussed include learning how to differentiate between different file types, performing a combination of light and deep static and dynamic analysis, understanding how to use different tools to aid in each of these types of techniques, and using different analysis strategies (bottom-up vs top-down).

Reverse engineering is an art form. Even when analyzing more complex binaries, these core concepts are still applicable. The only thing that changes is the speed at which we are able to perform our analysis and understand what the binary does. As a reverse engineer gains more experience they also learn shortcuts and pick up additional tools and techniques that allow them to reverse faster and more efficiently. We will cover some of these additional tools and techniques in our next blog post.

Lastly, we would like to thank FireEye’s Flare Team again for putting together another solid set of challenges this year! There is great learning value in participating in CTFs like the Flare-On Challenge. If you have never participated in a CTF or related challenges, we highly recommend giving it a try.

You’ve used them for directions, to order pizza, to ask about the weather. You’ve called them by their names Siri, Alexa, Cortana... You speak to them like you know them, like they can understand you. Why? Because they usually can. Intelligent assistants are on the rise and increasingly supporting our lives. In large part, this is driven by the user’s desire for ever more efficient querying and frictionless action. Instead of muddling through bloated interfaces, simply speaking or typing your queries or commands through a bot is often easier, faster, and seamless.

Bots aren’t just useful for helping us plan our day and listen to music. They are increasingly implemented across a wide range of industries, and have been introduced by companies to market and provide customer/sales support and recommendations. They can automate large portions of many data-driven tasks, correlating data, and providing context.  They can go even further and suggest what you may want to do next.

In short, bots can take care of the data gathering, munging, and routine analysis that previously consumed significant resources. This is especially pertinent for the information security mission. Security operators and analysts encounter simple tasks and actions daily while executing their complex higher order work. Unfortunately, the elementary tasks currently consume an inordinate amount of time. With that in mind, we created Artemis, an intelligent assistant for cyber defense.

Background

In contrast to other fields where bots are ubiquitous, bots have yet to make a major impact in the information security industry. Due to the talent shortage and the vast and diverse array of data in information security, there is a unique opportunity for intelligent assistants to help improve the workflow of operators and analysts. Resource-constrained security teams may rely on alerts generated by security platforms, but these alerts often lack context and require additional collection and correlation to make a solid analytic judgement. Intelligent assistants can help automate repetitive tasks and provide a natural language interface to streamline workflows for interacting with endpoint data.

By removing friction inherent in accessing information during an investigation, we can free up the responder to focus on the core investigatory analysis which is difficult to automate. Questions like "Is this artifact present on other systems?”, "What does this file do?”, "Is this artifact malicious?”, and “What strings are present in this process’s memory?” require additional querying and collection as well as enrichment from other available sources. Today, this process often demands an intimate understanding of multiple data schemas to effectively derive meaning from the mountains of data available during an investigation.

Artemis, An Intelligent Assistant

Endgame introduces Artemis, a first-of-its-kind intelligent assistant for cyber defense operations with these challenges in mind. Artemis is the ideal enabler for an organization’s information security mission, allowing analysts, hunters, and forensic personnel to use natural language to perform precision-guided analytics on endpoint data. The following are some of the intelligent assistant’s key features.

A Conversational Interface to Your Endpoints

The user interface is simply a chat window we’ve been familiar with in tools from IRC to Slack.  The user merely asks a question and the intelligent assistant surmises what needs to happen next. This leads to a natural and fluid two-way conversation towards the analyst’s objectives without needing to learn a complex query language to formulate the perfect query in one go.

Expert Recommendations and Rapid Contextualization

Less experienced analysts may have difficulty knowing how to pivot through data in response to an event or alert. They may make the common mistake of pulling in so much data that it becomes overwhelming and the malicious activity is lost in the noise. Artemis solves this by helping answer questions about what to search for, during what timeframe, and from which endpoints to extract data. The experience of our subject matter experts who’ve worked as hunters and DFIR experts in government, military and financial sectors is baked directly into the technology and guides the workflow. For a given alert or issue, Artemis immediately suggests logical and effective next steps or actions.

Focused Collection and Efficient Operation

The conversational interface of Artemis creates the query logic that runs on each targeted endpoint, culling data there instead of returning mass amounts of data to be centrally processed. In this way, the results of an Artemis conversation turn a big data problem into a good data solution. This lessens the physical resource strain in storage and network bandwidth, as well as the mental strain on analysts who have a helpful assistant guiding them, as needed, through the process.

User Directed Workflows

The conversational interface of Artemis streamlines workflows and enhances junior level analysts as well as power users. Importantly, analysts do not relinquish control. They remain in the driver’s seat.  Furthermore, the power of Artemis’ advanced query and aggregation capabilities can be accessed via Endgame’s open API, allowing power users to derive many of the benefits of Artemis as they directly access their endpoint data programmatically.

                                                                                                                                             Artemis, the intelligent assistant for cyber defense 

Conclusion

Intelligent assistants offer great promise to expedite security analysis and operations, save time and resources, and help strengthen defense. Artemis is capable of doing all these things, ultimately reducing the frequency and impact of significant cyber intrusion. In an accompanying post, we will dig deeper into the bot architecture, including the natural language processing, algorithms, and user experience features. If you’ll be attending RSA, you can also swing by our booth #1739 and hear our talk about bots for security.

As we enter 2017, there has been one particular user experience (UX) trend that designers can no longer ignore: chatbots.

While some debate their practicality, others believe it to be the internet’s next wave of innovation.  And despite some noticably terrible attempts at chatbot implementation, there is a huge surge of virtual assistants coming your way in 2017, whether we like it or not.

The Original Digital Assistant

Most discussions on chatbots emphasize the underlying artificial intelligence aspect, but the UX component is equally important.  Chatbots need to be effective in capturing a user’s needs, and quickly deliver the expected results without added complication or the use of complex methods to input commands.  This is true of any successful application, where the ease of workflow is seamless. As Joe Sparano noted, ‘Good design is obvious, great design is transparent’. For designers, ‘a simple workflow’ is the result of countless hours of research, implementation, and expert feedback, repeated in an endless loop. If the chatbot is more of a nuisance than an assistant, ignoring instead of augmenting the natural workflow, users skeptical of chatbots will view the technology as yet another tech fad that is over-hyped and under delivers, and would be quickly cast aside.

Knowing well the promise but also potential landmines associated with chatbots, we began the journey of designing our new intelligent assistant for cyber defense, Artemis. I’ll briefly walk through our use case and decision to integrate a chatbot into our platform  (which will be expanded upon in a follow-on post), and the key design principles we implemented and researched along the way.

Is a Bot For You?

Infosec is non-intuitively a natural use case for a chatbot. Infosec operators and analysts generally are overwhelmed with data, often have limited time and resources, and need their questions answered ASAP. As UX designers, we understood the key pain points and requirements for the analysts and operators who would be using our platform. These included anything from alert fatigue to data navigation to eliminating the necessity to learn complex and proprietary machine languages to perform even the most basic of tasks. In addition to significant design innovations throughout the interface, a chatbot seemed like a logical component to augment the user’s workflow.

As we designed Artemis, we constantly sought best practices and design principles to ensure Artemis augments the SOC analyst. Let’s take a look at some of our key take-aways that are relevant for anyone who wants to jump on one of the year’s hottest tech trends and ensure it truly augments the user’s experience.

Creating a Successful Bot Workflow

Below are several notable design interactions and useful guidance our UX team has integrated while creating Artemis.

There’s no need to reinvent the wheel

Chat is a pretty well-defined medium. There are countless apps in the market today that pull from preexisting chat paradigms.  Every user is familiar with the basics of call and response: The chatbot asks a question and in return you provide a response.  We built upon this established foundation to instead focus our efforts on improving optimization to the user.

Provide your user guide rails

Chatbots can be characteristically ambiguous without proper guidance. Let’s imagine the user’s first interaction with an unprompted chatbot - they will either be confused about what exactly they should type or confused about what the chatbot can offer them. From the very start, provide your users a short introduction that bridges directly to quick call-to-actions. While we allow the user to engage in simple conversation with the Artemis, we purposely drive each starting conversation with contextual call-to-actions that map to and are relevant for the specific view within the interface. Start thinking of ways to subtly sprinkle ‘guide rails’ throughout your chat UI to enable your user to take action, such as those in the graphic below.

Guard Rails Provide Context for Users

Get to the point  

When designing a utility chatbot, the user will most likely have a goal in mind the moment they initiate a conversation.  Your user could be ordering flowers, booking a hotel, or in our particular case, gathering sensor information around active endpoints to look for anomalous activity in their environment.  It’s important to remember to avoid letting conversation get in the way of action.  We want to allow the user to drive as fast and efficiently as possible. The last thing they want to do is navigate through rhetorical questions and ‘cute’ persona-based responses. And unlike booking a hotel, our particular use case has users interacting with the chatbot throughout the day, gathering information on their endpoints or triaging suspicious activity in their environment. Having the chatbot initiate even just a few lines of human-like rhetoric can be quite annoying after your fiftieth query prompt. In cybersecurity, even seconds matter - there is no room for cuteness when the proper interaction may impact the dwell time of malicious activity.

This is Not the Time or Place for Small Talk

Don’t design for the edge case  

Designing for every interaction can be a cumbersome task when creating a chatbot. It can be quite daunting to try to account for every input from a user and provide a custom response back.  In fact, the more branches you open in a conversational tree, the higher likelihood your user will hit a dead end. For a utility model, structure your user’s expected input until you have reached safe place to explore in plain text.

Provide a way out of the rabbithole  

Expect the user to make mistakes. Your chatbot may have correctly guided your user down a logical path of action, but your user may not have started with a set of correct base facts.  Build in a set of interactions for the user to make changes, walk back up the conversational path, or completely restart the conversation over again.

Rethink the role of traditional design

Are you a designer working on a chatbot? Great! Now roll up your sleeves, because we are now going outside the comfort of pixel pushing and into writing conversational dialog. Most conversational chatbots try to mirror human speech, while assigning it an identity that pushes the company’s brand identity. For instance, our users are often purpose driven to a particular set of unique tasks. This required our designers to create a dialog that both educates the user on their system’s environment and optimizes the speed at which they can set tasks, while also maintaining our brand identity.  So it goes to show, as a designer, you should be heavily involved in the writing process. Your chatbot’s conversational skills are only as strong as your writing. Writing purposeful and engaging conversations to your user is now your UX. Lorem ipsum is no longer your friend (but really, it never was).

Beyond Lorem Ipsum

Incorporate feedback loops

As UX designers, we are always thinking how can we optimize the experience for the user.  Traditional user-research heavily involves understanding your customer’s need through a variety of user research methods.  Defining what works and what doesn’t is the sole foundation for great design.

Talk to Users and Identify What They Need

An easy UX win, when designing any chatbot, is to include a feedback loop at the end of every successful (or unsuccessful) interaction.  Your chatbot may save an entire history of conversational information, but providing a purposeful feedback outlet to the user can cut the root of the problem. After the user completes a successful query, the chatbot can prompt the user to optionally input feedback on the most recent conversational path.  A simple prompt from your chatbot could capture frustrations from the user, workflow gaps in our design or even bugs.  

To Bot or Not?

While some are betting on 2017 as the year of the chatbot, it is important to remember that chatbots take an extreme amount of thought and process. It’s easy to make a terrible experience for the user, and extremely difficult to get it right without the proper design principles. The most important first step is defining your business needs and deciding whether your user truly needs a bot. If the answer is yes, be sure to keep in mind the design principles summarized above.  

With those in place, the next step is to gather key lessons learned from those in other industries. In the upcoming weeks, I’ll address those lessons learned and apply them to our specific use case in endpoint security. And remember, as UX designers, we never compromise at the expense of the user. We know from experience that often times it takes a whole lot of effort to create the effortless.  

Last night, in collaboration with Foreign Policy Interrupted, we hosted a discussion addressing the key geopolitical trends and challenges in cybersecurity. We were fortunate to have a great group of experts with backgrounds in academia, government, and industry discuss some of the most important foreign and domestic cybersecurity policy issues.

We kicked off the panel discussion with a series of comments and recommendations on the President’s impending Executive Order (EO) on cybersecurity, a draft of which had been released earlier in the week. The role of the private sector dominated a range of the discussion. This wasn’t the normal public/private partnership information sharing discussion that by this point is passé at best. Instead, there was an emphasis on getting that relationship right across a range of areas, including incentives for the private sector to pursue better ‘cyber hygiene’ (everyone’s least favorite industry term). Since the draft EO references the need for these incentives, we addressed what these incentives may look like in practice.

Similarly, instead of focusing a large review effort on a well-known area such as the adversary landscape as the draft EO recommends, we analyzed the utility of a cross-sector review of those best practices and lessons learned from previous private-public sector responses to digital intrusions. Panelists argued that these should range from collaborative efforts such as FBI-Microsoft collaboration to bring down the global Citadel botnet, to incident response, such as the response to the Sony attack. There are numerous examples of these collaborative efforts, yet little insight has been gleaned and shared to improve defenses and responses.

 Our panel included experts from academia, government and industry

It was also noted that there is plenty of room to grow the relationship between the public and private sector, especially when it comes to innovative policy. Current US policies are decades old and still are reminiscent of the Cold War landscape. These desperately need to be modernized, and require private sector input to help avoid another Wassenaar Arrangement, which had good intentions but can decrease defensive capabilities.

Several members noted that in addition to the well-known cultural divide between DC and Silicon Valley, the actual lexicon further hinders policy progress in information security. The use of terms like ‘cyber bomb’ and grouping every kind of intrusion as a cyber attack does nothing but hinder collaboration, confuse the public about the nature and impact of various kinds of intrusions, and limits any advances in policy. Panelists also called for moving beyond narrowly defined concepts of deterrence (which confusingly import conceptual frameworks directly from nuclear deterrence). This lack of conceptual fidelity regarding terminology and common lexicon is well known, but yet remains largely under-addressed.

Fortunately, there also are plenty of efforts to build upon, and no need to reinvent the wheel. For instance, the draft EO notes the necessity of workforce pipeline challenges. In many regards, this reinforces former President Obama’s Cybersecurity National Action Plan (CNAP), and the $3.1 Billion for IT modernization, as well as an emphasis on protecting privacy and public safety, and the workforce. Our panel discussed the well-known workforce shortage, but also reinforced the necessity to think even broader than computer science and STEM. While those should absolutely be the bedrock of growing the workforce, we must not forget the socio-technical nature of information security. For example, there is a dearth of lawyers with expertise in this area, policymakers who can straddle tech-policy, or designers specializing in information security.

In addition, the draft EO addresses the need for a holistic review of vulnerabilities across the government. Again, this is an intuitive recommendation, and supports well some of the most innovative efforts in the government right now, including Hack the Pentagon and follow-on Hack the Army bug bounty programs. Instead of relying on reviews that are muddled in bureaucracy, the government should build upon agile, impactful, and cost-saving approaches to both identify vulnerabilities and strengthen defenses.

As often happens when you get a group of experts passionate about their work, it was a lively discussion, but by no means could we cover everything within such a short time-frame. There is plenty left to discuss for future events like this, including the global expansion of censorship, the impact of AI, declaratory policies, and the role of norms, just to name a few. Thanks to everyone who joined us last night, including Michèle Flournoy (CNAS), Nancy Youssef (Buzzfeed), Shannen Parker (Cyber Command), Nina Kollars (Franklin & Marshall), Emmy Probasco (JHU/APL), and Lauren Bohn (Foreign Policy Interrupted) for their contributions and participation.

In my recently released book Facing Cyber Threats Head On, I spend a lot of time discussing how contemporary cyber security is just as much about stopping people (the attackers) as it is about stopping malware.  When you look at it, stopping people is a different problem and requires a different approach than stopping malware.  At the end of the day, people create and adjust strategies based on what they experience.  Computer programs do not.

To illustrate this point, let’s take a look at how we should stop a malware-based attack verse how we should stop a person-based attack.  In the case of malware, when you stop it from executing, you have effectively ended its existence.  The malware is not aware of the fact that it was stopped nor does it learn anything from the fact that it was stopped. It simply ceases to execute. 

Contrast this to a person-based attack.  When a person is stopped, they are aware of that fact.  The person can also infer things from how they were stopped and use those inferences to adjust their strategy going forward.  In other words, the person can learn and change.  Malware does not do this.

So what?  Who cares?   Well, when your entire defensive strategy is based on automatically blocking all malicious activity, you do a great job stopping malware, but you inadvertently tip your hand to the people, the attackers.  By automatically blocking a person, you allow them to learn how they were caught. You allow them to interact with your defenses in real time. You allow them to change their strategy and even test those changes until they ultimately find a way around your automated defenses. 

In a person-based attack, it is critical that the defender has the ability to strategically detect and respond to an attacker.  It is also critical that the defender has the ability to very quickly change their detection and response strategies as the attacker changes their own strategy.  Having technology that can enable a broad and dynamic detection and response strategy paired with capable analysts that can direct that strategy is ultimately how people-based attacks need to be addressed.

This is where the Morphick + Endgame Managed Endpoint Detection and Response (EDR) partnership comes in.  Endgame’s EDR platform delivers unrivaled visibility and detection capabilities to Morphick analysts who are then able to create and adjust detection and response strategies based on what specific attackers are doing at specific customers.  It is this powerful combination of technology and people that has proven most effective when addressing advanced people-based attacks.

As I say in my book “we do not want to automate the decision-making process around whether or not an attacker is in the environment.  However, we do want to automate the gathering of the information that the analyst needs in order to make that decision…use of technology to increase the productivity of people in the cyber defense process is valuable.  Using technology to replace people in your cyber defense process is not.”

If you’ll be at RSA next week, be sure to swing by the Endgame booth (South Hall 1739) on the 15^th at 11:00. I’ll be presenting, “Facing Cyber Threats Head-On” and handing out signed copies of my book as well.

Sharing ideas, tools, and techniques among our community of defenders makes everyone sharper and safer. To that end, we previously received third party certification, joined AMTSO, have published and presented in peer-reviewed settings, and have otherwise participated openly in the broader infosec community.  Continuing this pursuit of community engagement, we are pleased to announce that we have integrated MalwareScore™, Endgame's proprietary machine learning-powered malware detection and prevention engine, into VirusTotal.

While MalwareScore™ has been available to Endgame customers since last year as the earliest deployment of machine learning in our security platform, its worldwide availability through VirusTotal merits a broader explanation of its scope and design.

Scope: Prevent and Detect Executable Malware with Machine Learning

Endgame’s approach to protecting the endpoint relies on unified and tightly-integrated layers of behavioral protection mechanisms that each cover a swath of an attacker’s life cycle.  These layers include exploit prevention, prevention of attacker techniques, detection of fileless attacks and signature-less malware detection.  Protection against malware is a foundational element of an endpoint security solution, preventing adversaries who may have gained access to an endpoint from establishing persistence, installing backdoors, or executing ransomware, for example.

Critical to a modern malware prevention and detection solution is independence from rules, signatures and IOCs that are inherently reactive since they are derived from post-breach forensics.  While these traditional practices have their place, holistic prevention and detection must rely on a less brittle solution.  As detailed in our whitepaper last year, we built MalwareScore™ as the foundation for preventative malware protection using machine learning because it provides many advantages, including:

• a unified way to generalize to never-before-seen malware samples, families and variants (signatureless);
• an automated means to adapt malware prevention to emerging trends observed in malware or discovered by researchers; and
• deep insights learned from complex predictive relationships in the data that might only otherwise yield weak hand-crafted indicators of maliciousness.

Design: Lightweight but Lethal

Our design philosophy in MalwareScore™ was to include a machine learning model as one piece of a suite of tightly-integrated protective layers, with no need for cloud connectivity, and with a unified user experience.  As such, from the get-go, we had three primary requirements in scoping our malware prevention models:

• extremely small footprint,
• rapid execution (low CPU utilization), and
• very high detection rate at extremely low false positive rates.

After rigorous competitive analysis, we believe we've punctuated each objective with an exclamation point. For a typical executable file, our model takes 5 ms to evaluate, with a memory footprint of roughly 5 MB. It reproduces malicious and benign labels of our holdout validation sets with an area under the ROC curve (AUC) of 0.9997.  In practice, this allows our customers to achieve a true positive rate exceeding 99% at false positive rates below 1:1000.  And, as our own harshest critics, we're continuously and relentlessly in pursuit of improvements to our models and methodology.

Deployment: MalwareScore™ in Action

MalwareScore™ prevents malicious Windows executables from running on customers’ endpoints using wholly on-sensor machine learning models.  In addition, Endgame computes a MalwareScore™  for each PE file that is created or modified on an endpoint and triggers an alert for executables with a sufficiently high MalwareScore™. Endgame provides several user-selectable settings for MalwareScore™ to allow customers to adjust their detection and prevention postures to be either more conservative or more aggressive.  

MalwareScore™ is a tightly integrated feature within our endpoint protection platform.  For deployment in VirusTotal, we extracted and wrapped the MalwareScore™ product feature as a standalone scanner that examines all incoming PE files.  As deployed in VirusTotal, MalwareScore™ currently outputs three categories: benign, malicious (moderate confidence), and malicious (high confidence).  

Strengthening Defenses through Machine Learning

Machine learning and artificial intelligence are exciting fields that have many applications to security.  In addition to MalwareScore™, Endgame is applying machine learning and artificial intelligence to other areas to help defenders detect, prevent and respond to malicious activity in other phases of the attacker’s life cycle.  

Our team at Endgame leveraged years of previous experience building data-driven products to research, develop, rigorously test and deploy MalwareScore™ into the Endgame platform.  Today’s inclusion into VirusTotal provides a tremendous opportunity to assist security analysts worldwide and is a validating step for MalwareScore™. But we’re not done yet! We’re continually improving MalwareScore™, aggressively seeking out corner cases and solving those problems through data collection and curation, engineering, and maintaining the perspective of an attacker.  Stay tuned as we incorporate updates to our endpoint detection and response product offering into the VirusTotal scanner in the months to come.

We welcome your input to continue helping us support the community. Please send any feedback to: vt_feedback@endgame.com 

Yesterday’s RSA keynote by Brad Smith, Microsoft’s President and Chief Legal Officer, has the industry finally buzzing about the creation of global digital norms. In his accompanying blogpost, “The Need for a Digital Geneva Convention”, Mr. Smith moves beyond simply reiterating the stats behind the breadth and depth of digital attacks. He provides concrete recommendations for pursuing law and order to the digital domain.

His keynote has garnered a lot of buzz across the media and within subsequent panel talks that I’ve already seen today. Importantly, as one key aspect, he highlights the necessity for digital norms, which at their most basic level are mutually agreed upon standards of appropriate behavior. In his blog, Mr. Smith notes, “This commitment to 100 percent defense and zero percent offense has been fundamental to our approach as a company and an industry.” He further expands upon his company’s collaboration with many other companies in helping ensure a safe and neutral internet, while encouraging governments to continue to build upon the nascent norm creation occurring at some international forums. As he accurately notes, the creation of norms will require greater attention and absolute conviction by both the public and private sector.

Already, we’re seeing many of the responses to his talk focusing too narrowly on the feasibility of a digital Geneva Convention, and overlooking the underlying necessity to establish the appropriate guardrails of digital behavior. This is unfortunate, as that is where a constructive discourse is required, exploring the feasibility of making progress towards establishing those norms that he outlines.  The challenges but necessity for the creation of digital norms was the focus of a talk I gave earlier this month at the Enigma Conference, some of which is summarized below. Despite the many challenges to digital norm formation, they must be a core component of a larger cybersecurity strategy.

As Mr. Smith notes, the current situation consists of attacks on critical infrastructure (e.g. Kiev power grid), automated bots wreaking havoc across social media sites and targeted geographies (e.g. Mirai bot), and massive IP and PII theft (e.g., US steel industry, OPM breach), not to mention the continued growth of global censorship, filtering and data manipulation.

Attempting to help reign in the impact of this wide range of digital attacks, nation-states have looked to global forums to formulate very nascent norms. Last year, former US Secretary of State John Kerry outlined five areas to guide appropriate offensive behavior in cyberspace, including prohibitions against attacking critical infrastructure or stealing intellectual property, as well as not impeding cybersecurity emergency response teams. These mirror those norms agreed upon by the UN’s Group of Governmental Experts and at the G20 summit. Similarly, many reference the Sino-American agreement at the end of 2015, which introduced the norm against cyber-attacks for commercial advantage, as indication that norms work.

National cybersecurity strategies are also advocating for norm formation. Both the US State Department’s International Cybersecurity Strategy, as well as the UK’s recently released National Cyber Security Strategy 2016-2021 address the essential role of norms. Surprisingly, the necessity of norms is one area where the tech community agrees with the policy wonks. Last summer, Microsoft published another white paper on the need for cyber norms. Similar to Mr. Smith’s keynote, they advocated for the establishment of norms to limit the impact of nation-state attacks, norms against the trafficking of vulnerabilities for offensive weapons by companies, as well as against forced backdoors in software. Jeff Moss touched on this during last year’s Vegas hacker summer camp, noting, “Are we at the beginning of a sea change in what the international community decides is acceptable behavior? It doesn’t have to be a treaty; it can just be a norm.”

“Just be a norm.” It sounds simple, but that there’s a reason why global digital norms have yet to be established in the twenty year since the first US public attribution of a digital attack, dubbed Moonlight Maze.                                                                                                     

First, and importantly, leadership is required to propagate norms globally. These leaders must be credible and convince a critical mass of states to embrace the new norms. Currently, global major powers are divided on what framework digital norms should reflect, those of a multi-stakeholder model or those indicative of cyber sovereignty. A previous post highlighted these distinct models, but to oversimplify, a multi-stakeholder model reflects a democratic view of a free and open internet and focuses on what targets are off limits, while cyber sovereignty focuses on governmental control within sovereign borders. This state of competition between these two models is currently underway, although there are areas of agreement such as those worked out at the global forums.

Second, even if leadership does emerge, there is an enormous collective action problem. Quite simply, the more actors involved, the harder it is to achieve cooperation and find common ground. There are roughly 200 countries in the current international system, many of which are building up their own digital arsenals. This is not limited to major digital powers, but is increasingly viewed as a necessity by regional powers and smaller countries, such as South Africa, Thailand, and Estonia. But digital capabilities are not only the purview of nation-states; they also are accessible to criminal organizations, terrorist networks, hactivists, and lone wolves, some of which are associated with state sponsorship, but many are not.

Finally, norms only become entrenched when there are visible signals of compliance, which involves a range of technical and social obstacles. The socio-technical aspects of attribution are especially challenging. On the technical side, dynamic C2 infrastructure, the potential for deception, and weapon reuse all create a fog of cyber war that renders it difficult to quickly and confidently identify malicious actors. Looking at the human element of attribution, it may be difficult to establish whether a non-state entity is linked to a state or acting on their own. There are numerous cases where military hackers may become lone wolves during off hours to make money, or where attacks are initiated by criminal groups and then taken over by state actors. In those cases, the government is complying, but state-associated personnel are not. Additionally, given the current dwell times of adversaries within targeted systems, it is hard to evaluate how well a state is adhering to a norm against targeting commercial entities, for instance. Sophisticated digital capabilities also remain state secrets due to their short shelf life and the necessity for the element of surprise. And of course there always is the risk of insincere compliance. Wassenaar is a great example of this. Just because states are participants, lacking any repercussions for failing to comply, many states opt to take the insincere compliance route, where their actions contradict their words.

Despite these challenges, the discourse that Mr. Smiths’ keynote has generated must continue past RSA, and will require both technical and policy innovation across the public and private sectors. The global race is underway to define acceptable behavior in cyberspace. Unless the vacuum is filled by those in favor of norms akin to Mr. Smith’s ‘digital Switzerland’, the alternative is a world where unrestricted digital attacks, unlimited censorship, and even physical destruction may well become the new global norm.  

­­­

Code deobfuscation and pattern recognition are as much an art as a science. In the past, we’ve talked about automating many aspects of proactive detection, such as through delta analysis, scripts, or crawling the web for exploits.  These are exceedingly useful, and take me back to my the days of hard drive (HDD) forensics and analysis, which was much more manual than automated.  Back then, suspicious artifact discovery and identification was also more manual.  Some artifacts came from the efforts of first line net defenders, others came from incident responders, while others still were those obtained through HDD forensics of compromised systems.  Regardless of the source, artifacts of suspicion were uncovered.  Some were readable, while others were encoded, obfuscated or encrypted.  

In general, during active investigations involving post-mortem (or dead box) forensics, it’s not always immediately known what produced the artifact in question, nor what algorithm or encoding scheme produced the artifact.  Despite the deadline or urgency of the mission, obfuscated artifacts often stalled investigations or were completely cast aside because nothing immediately appeared malicious.

Current day hunters undoubtedly need to deobfuscate or decode a particular artifact – quite possibly without the luxury of having the artifact’s parent binary.  But how does one go about figuring out that ‘A’ decodes to ‘B’ by basically eyeballing an artifact? The key is pattern recognition.  Pattern recognition is especially important when the original parent malware is not available. I’ll walk through some key elements and tips I’ve developed to expedite the manual pattern recognition and deobfuscation process, and conclude with a brief overview of some of the automated pattern recognition techniques, which are enhanced when combined with expertise gained through the manual deep dives into the artifacts.

VISUAL PATTERN RECOGNITION

Let’s warm up with a few quick examples where the obfuscation technique should be readily apparent. Since encrypted data is visually indistinguishable from random data,  I’ll be focusing on non-encrypted data, starting with how it pertains to Windows portable executable (PE) files. As a refresher, the diagram below is a useful reference for locating the various headers within a PD file.  As we proceed, keep in mind there are a lot of null bytes in a PE file, specifically in between the MZ header and DOS stub.

Image source: http://marcoramilli.blogspot.com/2010/12/windows-pe-header.html

For this reason, XOR keys are relatively easy to spot at times as any key byte XOR’d with a null byte (0x00) will produce the same key byte (e.g 0x85 XOR’d with 0x00 will produce 0x85).

The four diagrams below reflect four different hex editor views of the same PE file, with each of these keys easily seen at offset 0x20

The Original

1-byte XOR key applied

2-byte XOR key applied

4-byte XOR key applied

Not everything in need of deobfuscation will be a PE file though.  Take a look at the following ‘.dat’ file for example.  Does anything jump out?

If the first thought was that ‘.dat’ was encoded with the two-byte XOR key [0x88, 0x85], that would be a good thought. Let’s pursue that and see what we get (using the first 16 bytes).

0000000: 8885 8885 b7ad abac ada8 abb4 a8ab ae9b  ..............

XOR with [0x88, 0x85] becomes

0000000: 0000 0000 3f28 2329 252d 2331 202e 261e  ..............

Nothing apparent comes to light with this line of thought.  So let’s refer back to the previous figure and see where the 2-byte pattern (0x88 0x85) occurs.  We see it at offsets 0x00, 0x02, 0x81, 0x83, 0xb6, 0xc2, 0xc4, 0xc6 and 0xe3.  One question at this point is, “what 2-byte pattern can exist once, twice, thrice, etc?”  Having encountered my fair share of keylogged data files, my thoughts turn toward the 2-byte pattern of the ‘carriage return / newline’ or [0x0d, 0x0a]. Could this be what [0x88, 0x85] decodes to?  In order to pursue this line of thought, simply XOR 0x88 with 0x0d (resulting in 0x85), and XOR 0x85 with 0x0a (resulting in 0x8f). This gives us our potential XOR key.  If correct, the 2-byte XOR key is [0x85, 0x8f].  Let’s check it out.

0000000: 8885 8885 b7ad abac ada8 abb4 a8ab ae9b  ..............

XOR with [0x85, 0x8f] becomes

0000000: 0d0a 0d0a 3222 2e23 2827 2e3b 2d24 2b14  ....2".#('.;-$+

Something still isn’t correct.  There is some ASCII readable data, but nothing useful.  A rolling XOR key or byte for byte substitution scheme doesn’t seem to be the ticket, but I still like the [0x0d, 0x0a] theory.  What else can get [0x88, 0x85] to our ‘carriage return / newline’ or [0x0d, 0x0a]? Some typical encoding schemes include XOR, rotating left or right (ROT/ROL), addition/subtraction, so let’s explore if it could be a different math function.  Subtracting 0x0d from 0x88 equals 0x7b, but will taking 0x7b away from our next byte of 0x85 equal 0x0a?  You bet it does.  I think we’re onto something now.  Turns out this particular data block was encoded by subtracting 0x7b from every byte as shown below.

0000000: 8885 8885 b7ad abac ada8 abb4 a8ab ae9b  ..............

subtract [0x7b] from every byte becomes

0000000: 0d0a 0d0a 3c32 3031 322d 3039 2d30 3320  ....<2012-09-03

Here’s the decoded ‘.dat’ segment.  As we look at the ASCII representation, we can see the output includes the date and name of the application currently being displayed or used by the user.  This suggests the work of a keylogger.

The following is my python script used to do the math.

import sys

f = open(‘.dat’, 'rb')

contents = f.read()

f.close()

f = open(‘.dat_decoded', 'wb')

for x in contents:

       f.write(chr(((ord(x)+256) - 0x7b) % 256))

DOUBLE OBFUSCATION

At times a defender/hunter may obtain a suspicious artifact that contains an embedded (and obfuscated) executable binary.  There are various tools available to extract binaries from files such as DOCs, XLSs, PDFs, but I’ve come across some artifacts where a double layer of obfuscation was used. This forced me to deobfuscate it manually through "eyeballing" and deductive reasoning.  Let’s look at this excerpt from a such a malicious file.

At first glance, a possible XOR key of 0x87 jumps out as we see it repeated many times over between offset 0x8630 and 0x8680.  In an ideal world, we would see an MZ header with a DOS stub staring at us after we XOR decode the segment with 0x87.  That’s not what we get though, is it?

It’s important to recognize the visual ASCII pattern of an MZ header and DOS stub.  With this visual in mind, look over the ACSII display above, which includes all of the bytes that have been XOR’d with 0x87.  Do your eyes fixate on offset 0x8637 (first three bytes: 0xD4 0xA5 0x09)?  Even though this segment is not flush against the left margin of the ASCII view, the visual pattern of a windows PE file is still present. Unfortunately, something is still amiss.  There doesn’t appear to be an MZ header anywhere in sight, nor does there appear to be a DOS stub.  Or is there?  Let’s carve out this segment into its own file and inspect it a little further.  Below is the beginning portion of the carved out file, which is still obfuscated.

Look at the first two bytes.  Do they look familiar?  They are in fact nibble swapped.  A nibble is half a byte so with the byte 0xD4, ‘D’ is one nibble, the other nibble is ‘4’. Swapping those nibbles result in 0x4D.  Continuing with the next byte 0xA5, a nibble swap results in 0x5A, and 0x09 becomes 0x90, etc.  Let’s now nibble swap each byte of our sample.  What we’re left with is the immediately recognizable MZ header / DOS stub below.

ANOTHER DOUBLE OBFUSCATION EXAMPLE (because they’re fun)

This next technique involves a double layer of obfuscation, but with a few more interesting twists.  The segment below consists of 272 bytes extracted from a nefarious looking file.  As you can plainly see, the embedded binary begins at offset 0x6A16 with byte 0x3b, right?

Well, okay, maybe there isn’t anything ‘plain to see’ about this.  In fact, it probably just looks like a bunch of gibberish, but let’s look for a pattern anyway.  Do you see the repetitiveness of [0x61, 0x83, 0xa5, 0xc7]?  This appears to be a good candidate for a 4-byte XOR key so let’s use that and see what happens.  

It seems to have that ‘ASCII visual’ I look for - the general appearance or shape of an MZ header and DOS stub, but not necessarily the content.  There isn’t much to go on though so let’s review it byte by byte keeping in mind that the MZ header is ‘MZ’ and a common DOS stub is ‘This program cannot be run in dos mode.’  Notice the bytes at offsets 0x6a16, 0x6a18 and 0x6a1a.  They are 0x5a, 0x4d, and 0x90.  This should definitely jump out as the first three bytes of the MZ header, but they’re out of order.  Now look at the ASCII text beginning at offset 0x6a63, you can see all the letters of the DOS stub, but definitely out of sequence. 

To put this ‘humpty dumpty’ back together again, a "circular shift" loop of sorts is necessary.  Begin with the offset 0x6a16 (we’ll call it byte(0)), pop offset 0x02, and shift it left two bytes (or insert it at byte(0)).  This shifts all other bytes to the right by one.  Next, pop the byte at offset 0x04 and shift it left two bytes, and then pop the byte at offset 0x06 and shift it left 2 bytes. Reiterate this loop until the executable is completely assembled.  For visualization purposes, here is the play-by-play depiction of the first eight loop iterations. Now that we have the complete binary, RE efforts can begin.

MANUAL vs AUTOMATION

Of course, I’d be remiss if I didn’t mention that manual pattern recognition isn’t the end all or the only method one should try.  A wide array of deobfuscation tools are out there and should be used whenever possible.  Many of these strive to deobfuscate XOR, ROL, ROT and/or SHIFT keys, while others (such as FLOSS) attempt to uncover obfuscated strings.  ‘XORtool’ is another good one to try. Some tools, however, specialize in single-byte XOR keys such as ‘ex_pe_XOR’, ‘iheartXOR’ and ‘XORBruteForcer’, while others like ‘XORSearch’ goes beyond a single byte XOR key.  By default, XORSearch tries all XOR keys (0x00 to 0xFF), ROL keys (0x01 to 0x07), ROT keys (0x01 to 0x19) and SHIFT keys (0x01 to 0x07) when searching, but it also has a switch to search for a 4-byte (or 32-bit) key.  This works quite well, but it’s not effective for longer key lengths.  To illustrate this, calc.exe was XOR encoded with a 4-byte key, then with a 5-byte key as reflected in the following diagram.

The tool had no problem finding the 4-byte XOR key for the file ‘calc.exe_XOR.bin’, but it couldn’t find the 5-byte key used for ‘calc.exe_XOR.bin2’.  Each result is reflected below.

As shown above, the 32-bit XOR key 16E97642 (little endian) was found.  This correctly matches the visible XOR key (0x4276E916) in ‘calc.exe_XOR.bin’ at offset 0x20. Studying the byte combinations of calc.exe_xor.bin2 however, the 5-byte key (0x4276E9162B) can be first be seen at offset 0x19, repeating in its entirety several times.

There are other tools that try to ascertain longer keys, some through frequency analysis, but each tool is different so the results often vary.  For this reason it’s advisable to experiment with a wide array of deobfuscation tools to get familiar with their nuances before getting hit with an operational time crunch.  Also, keep in mind that many tools are designed for obfuscated PE files, meaning they’re looking for known PE file components and may not be effective for other types of non-PE obfuscated files.  Knowing the ‘target audience’ of the tool is important.

CONCLUSION

Pattern recognition analytics can be extremely beneficial, but must be viewed as one part of the larger hunter’s or analyst’s arsenal.  Pattern recognition is not for the inexperienced, as strong scripting chops are necessary to completely deobfuscate artifacts once the encoding scheme or pattern has been recognized. And remember, if confronted with an obscure one-off hunter-attained artifact (meaning all the moving pieces aren’t available to reverse engineer), and the tool of choice doesn’t provide the necessary output, a keen eye may just come in to save the day.

Last November, Microsoft released a security update for Microsoft Edge which included patches for vulnerabilities CVE-2016-7200 and CVE-2016-7201, which were discovered by Google Project Zero.  Earlier this year, a proof-of-concept (POC) exploit was published by Brian Pak, demonstrating that the two vulnerabilities can be used together to gain exploitation. Shortly afterwards, they were included in several popular exploit kits.  The exploit kit implementations appear to be largely a cut/paste of the POC.

The POC has weaknesses, which I will discuss, but in its primitive form, it managed to bypass all of Microsoft's exploit mitigations. The POC demonstrates how the right kinds of vulnerabilities can still neutralize very sophisticated anti-exploit technologies and gain execution. CVE-2016-7200 is a type confusion bug in the array.filter function of chakra.dll.  For the purposes of this post, it allows an attacker to determine the address of an object created on the heap. CVE-2016-7201 is another type confusion bug in chakra.dll, this time in JavascriptArray::FillFromPrototypes.  It is used to provide the attacker with read/write abilities on arbitrary memory.

Microsoft has a steady track record of implementing exploit mitigation technologies, ranging from EMET, at one time the industry standard in exploit prevention tools, to the built-in mitigations incorporated into Windows 10 and Edge.  An exploit – even an unweaponized one – that bypasses these technologies is interesting and can help us understand the current state of exploit prevention.

At Endgame, we constantly test our exploit detection and prevention capabilities against the latest threats to ensure we continue to provide the most robust defenses available.  We became extremely interested in this POC as it highlighted several areas where further research was required, and has already resulted in stronger protections for our customers.

In this post, I won't be looking at the vulnerabilities in depth, but instead will focus on the weak spots in current exploit mitigation techniques that are highlighted by the minimalist POC.  I will walk through a typical exploit attack chain as it applies to the Chakra POC, and illustrate how we must continue to raise the costs for in-the-wild exploits through more innovative approaches to prevention.

The Stages of Exploitation

Memory Preparation

Most exploits require a preparation step that puts something controlled by the attacker (e.g., ROP, shellcode) in memory in a known location prior to gaining execution.  This step can take many forms and is often referred to as heap grooming, or one of its subsets, heap spraying.  While most of these techniques are difficult to detect with high confidence, it often offers the first chance for defenders to detect that something malicious is happening.

Heap spray mitigations come in two main flavors – detectors and disruptors.  Detectors, like NOZZLE, monitor allocations and inspect memory for indicators of malicious behavior. Disruptors, like BuBBle and DieHarder, attempt to reduce the reliability of heap sprays by increasing allocation randomization, blocking NOP-sleds, or protecting addresses commonly used by exploits (0x0c0c0c0c, etc.).

An entire chain of blog posts can be dedicated to the cat-and-mouse game of preparing memory for exploitation and detecting such actions.  Let's leave that for another day and skip to the simplest method to bypass detection at this stage.  The solution enabled by CVE-2016-7200, and chosen by any attacker if given the choice – avoids memory preparation altogether.

Technically, CVE-2016-7200 does prepare memory in the broadest sense, but it does so with the precision of a scalpel, making it very unlikely that any current mitigation technique will notice.

The implementation of CVE-2016-7200 can be seen below:

PutDataAndGetAddr() is used once for the memory leak (discussed later):

And again to place shellcode:

As you can see, there are few allocations, no NOP-sled is required, and the data is mostly benign (the shellcode data could be detected as code, but would be very difficult to label as malicious).

Vulnerability Preparation

No mitigations to speak of in this step, and there isn't much to write about because actions taken here are dependent on the vulnerabilities involved and the path to execution chosen by the attacker.

The Chakra POC uses CVE-2016-7201 at this point to create read/write capabilities that will be used later.

Memory Disclosure

With the introduction of address space layout randomization (ASLR), and now near universal enforcement, attackers need to take one extra step in their path to exploitation. They need to orient themselves by finding the address of their target module in memory.

Since the Chakra POC already has the address of an object and read/write primitives, acquiring the base address of chakra.dll is simply a matter of grabbing the vtable from our object, finding the address of one of its functions, and subtracting the appropriate offset based on the dll version.

Payload Preparation

In order to be the most effective across a wide range of operating systems and target versions, many exploits dynamically determine the locations of functions necessary for exploitation (e.g, VirtualProtect, VirtualAlloc, etc.).  This lookup is most often accomplished by searching the export address table of a target dll.  A good example of this is the PE.as module often used in Flash exploits:

Mitigations, such as Microsoft EMET's EAF/EAF+, exist to detect this behavior by blocking access to DLL headers from unauthorized locations.

The Chakra POC avoids this check by using hard-coded addresses where a lookup would traditionally be required.

There is an inherent weakness in this approach.  The use of hard-coded offsets in an exploit is useful in defeating some existing exploit mitigations, but by and large, this practice is detrimental to widespread usage and effectiveness. Hard-coded addresses increase exploit development time and require constant updating to survive in a dynamic target environment.

Code Execution

Next up, an attacker must interrupt the intended flow of execution and begin executing his/her own agenda.  Traditionally, this has been done by pivoting the stack pointer to attacker-controlled memory.  A common mitigation at this point is for security products to occasionally verify that the stack pointer actually points to the current thread's stack.

The Chakra POC passes these checks by placing its ROP directly on the stack.

Endgame employs HA-CFI, which helps ensure the integrity of code execution, and has been very successful in preventing most exploits. HA-CFI can detect unusual control flow and stops most exploits before the stack pointer has been modified. Often, the stack pivot is the first gadget in the ROP (discussed next) and is usually the first abnormality in the flow of execution.  

Microsoft utilizes Control Flow Guard(CFG) with similar goals.  CFG adds an additional check to indirect calls to ensure they are being directed to valid targets.

The Chakra POC, thanks in large part to hard-coded addresses, hijacks the return address for ScriptEngine::ExecutePendingScripts and gains control of the stack when the exploit script completes.  No indirect calls are required, and unusual code flow is avoided, thus bypassing HA-CFI and CFG. 

Return Oriented Programming (ROP)

ROP is a standard method of transitioning to full control of execution. This step is most often required when the attacker's shellcode resides in non-executable memory.  

A lot of research has been conducted in detecting ROP, which has resulted in several techniques being deployed in security products.

1.  Sanity checks on critical functions.  The thought here is that if an attacker is forced to use ROP, he/she likely will need to use one of a short list of functions, such as CreateProcess or VirtualProtect to move on to payload execution.  Whenever these functions are called, a series of checks can be performed to detect badness.

      a. stack pointer integrity
      b.stack integrity
      c. return address is call-preceded
      d. VirtualProtect does not attempt to make stack executable

2.  Code simulation.  Mitigations employed by Microsoft's EMET and ROPGuard simulate execution beyond the current critical function for a short period to detect ROP-like behavior.
3.  Hardware.  kBouncer makes use of hardware performance monitors to detect ROP-like behavior.

Chakra POC ROP

The Chakra POC does use a ROP (shown above), but it has several characteristics that make it very difficult for any of these techniques to detect.  First, the ROP contains only two gadgets plus a return to shellcode.  This eliminates HW-assisted gadget-chaining detection, like kBouncer, which requires longer ROP chains to reach high enough confidence in malicious activity.  Second, the VirtualProtect call is made through a legitimate function that wraps VirtualProtect. This makes the stack appear normal when it reaches any checks at VirtualProtect.

The combination of the second ROP gadget and APIHook_VirtualProtect provide plenty of legitimate code for simulation techniques to inspect and feel good about as they inspect code following VirtualProtect.

Conclusion

The Chakra POC is a good case study in exploit mitigation evasion techniques, and I really only scratched the surface.  The techniques used in this POC are not new, and in fact, most have been around for quite some time.  They were used for two reasons: 1) The vulnerabilities themselves allowed their use; 2) The mitigations built into Windows 10 and Edge necessitated their use.  We know that vulnerabilities will continue to exist, which leads the defensive focus to exploit detection and prevention.  Software vendors like Microsoft, Google, Adobe, and many others have invested significant resources in the detection/prevention fight.  Hardware vendors like Intel are joining the struggle as well.  And security companies like Endgame offer even more capabilities to stop adversaries.  Every mitigation potentially adds some cost to an attacker.  Our job is to make that cost as high as possible.

The Chakra POC and the ongoing discovery of in-the-wild exploits highlights that the cost is not yet high enough, and the attackers are still getting through.  It demonstrates that Windows 10 and Edge do not provide the safe haven so many have claimed.  At Endgame, we continue to develop innovative exploit detection/prevention capabilities to raise the cost by analyzing the latest exploits and integrating prevention techniques to stop even the most creative attackers at the earliest stage of the attack chain.

Banking trojans have been around for years, but gained greater visibility in 2015 and into 2016 as they moved from targeting European banks to American banks. We previously discussed the Odinaff banking trojan, which was responsible for the SWIFT attacks, and the theft of close to $1 billion. Another banking trojan commonly known as Dridex steals consumer banking credentials and then makes fraudulent transactions using those credentials.  It is making the news due to a major upgrade in capabilities, including the first in-the-wild spotting of the AtomBombing technique. DridexV4 bypasses existing defenses and has already been spotted in campaigns aimed largely at the UK. We’ll take a look at DridexV4, the significance of the Atombombing technique, and demonstrate how Endgame’s multi-layer approach to prevention and detection proves effective at stopping attacks incorporating never-before-seen techniques.

Background

A new major version of the Dridex malware was recently spotted in the wild. This new version of the Dridex banking trojan marks the first known malicious implementation of the AtomBombing code injection technique, which was first identified in October 2016.

Dridex is a relatively sophisticated banking trojan that has been propagating since 2012. Dridex has been observed targeting online banking customers across Europe and the US, and is one of the dominant banking trojans used by criminals to access banking accounts. Dridex evolved from Cridex, adopting a substantial amount of functionality from the GameOver Zeus banking trojan, which was taken down in 2014 after a global effort led by the US government.

As first reported by IBM X-Force, the new Dridex version implements a novel stealth code injection technique called AtomBombing, which was described in detail in 2016 by researchers at enSilo. AtomBombing is a new code injection technique which doesn’t use any of the same API calls executed in traditional code injection, but rather relies on atom tables to deliver code into targeted processes.  In general, process injection is a good method to evade defenses because the attacker code hides within a trusted process.  API calls used by more common code injection techniques including VirtualAllocEx(), WriteProcessMemory(), and CreateRemoteThread() are often monitored by security products to detect code injection.  Avoiding these calls allows the attacker to bypass these security measures and successfully achieve process injection. 

DridexV4 in Action

The integration of the AtomBombing technique was a major upgrade for DridexV4, offering the banking trojan even more advanced capabilities to avoid detection. AtomBombing isn't the only interesting technique used by this malware. Upon looking at a DridexV4 sample, we saw a few interesting injection and persistence techniques. The sample utilizes the AtomBombing technique to inject code into explorer.exe, then performs a DLL hijack by copying a random legitimate Windows binary from the “System32” directory into another folder. It then drops a malicious .dll that the legitimate Windows binary loads on runtime. Finally, the sample creates a scheduled task to execute the legitimate Windows file on startup, knowing the malicious .dll will be loaded as well.  Additionally, the sample creates a firewall rule that allows the “explorer.exe” process (where the malicious code is injected) to communicate over the network and allow command and control.

The following screenshots depict some of the scripts temporarily dropped to disk and executed to copy system files, add firewall rules, and create scheduled tasks.

Detecting DridexV4

This new version of Dridex is a great example of how adversaries are constantly innovating to defeat the latest security measures. Because of their constantly evolving techniques, a layered approach will always be necessary to consistently detect and prevent attacks from adversaries. In this context, a “layered” approach refers to a multi-faceted solution that cannot be bypassed through any single point of failure. If the adversary bypasses one layer, it will be detected at one of the subsequent layers. Security solutions that do not offer layered behavioral preventions will break down and fail as soon as an attacker finds a creative workaround of the specific defensive technique, which has happened historically time and time again.  

Generic Detection

There are a handful of ways to detect and remediate Dridex running in your environment. None of these are guaranteed to detect Dridex, but rather they speak to generic defenses that are required to at least raise the attacker’s cost and time for compromise.  

• Audit Autoruns: Regularly audit all autorun items on all Windows machines in your environment using freely available tools such as Sysinternals Autoruns. Pay especially close attention to any unexpected autorun items that are signed by Microsoft, but not sitting in the same directory as usual.

• Antivirus: Ensure you have an anti-malware solution deployed on all endpoints in your environment and the definitions are up-to-date. Antivirus alone is rarely enough to detect a novel variant of malware and detection may be subject to the delays of antivirus signatures.

• Conduct Memory Analysis: If you suspect a machine may be compromised, conduct offline memory forensics with an open source tool like Volatility. This can be slow and time consuming but it is one of the few ways to find memory-resident code with open source tools.

Detecting with Endgame

While we offer numerous layers of detection, Endgame detects the latest variants of Dridex in the following places:

• MalwareScoreTM: Dridex drops a handful of .DLLs onto disk at runtime that are detected by Endgame’s machine learning-driven binary classifier.

• Fileless Attack Detection: Once the malicious code is injected into memory with the AtomBombing technique, Endgame’s fileless attack detection easily locates the malicious code running in memory.

• Persistence Locations: The new variants of Dridex drop persistence items as scheduled tasks and DLL side loading. Endgame enumerates every binary that can be executed on startup using all the known techniques from every machine in your environment. This persistence method would trigger our “masquerading” analytic, as seen in the video below.

The video below demonstrates how Endgame stops DridexV4 at each of these layers.

The Only Constant is Change

New offense techniques come and go constantly. Last week, a major new variant of Dridex was observed in the wild, weaponizing the new AtomBombing code injection technique. Security products and organizational procedures that rely heavily on detecting traditional code injection techniques will fail because AtomBombing uses completely different APIs to accomplish an identical end-result of injecting code into memory. A layered approach is the only way to consistently stay on top of the adversaries’ newest attack techniques. The new AtomBombing technique is not a one-off abnormality, but is indicative of the sophistication and ever-evolving nature of offensive tradecraft. Just as the attackers pursue multiple and never-before-seen pathways toward successful compromise, so too are multiple layers required to stop them.

Political psychologists are exploring whether efforts aimed to increase awareness of women’s under-representation in politics make women less likely to seek public office. Security seems to be in the same situation, with seemingly daily reports aspiring to increase awareness of the under-representation of women, and yet the numbers continue to slide to roughly 10% of the workforce. Clearly, this does not entirely fall on media portrayals, which for good reason highlight many of the real, data-supported and documented challenges women encounter in the field. But by focusing solely on the negative, we do a disservice to the women and men in the industry who are pushing for change. So what can be done? Here are a few tips for you on this International Women’s Day.

Elevate Women’s Expertise

Too often at security conferences the diversity panel is the only one with speakers who happen to be female. While attempting to do good, this focus on women as only experts on gender distracts from the technical expertise of the amazing women in the industry. And as I’ve written elsewhere, we’re tired of being asked to discuss diversity when we’ve gone through years or decades building up our expertise. In fact, it is not a terribly popular topic for speaking opportunities, but it won’t change by ignoring it.

Start by encouraging your female colleagues to submit technical talks to the various cons. This may be easier said than done. As I personally experienced when pulling together our Foreign Policy Interrupted panel, and which has been documented elsewhere, many extremely qualified women hesitate to present or may turn down invitations to present. It is on all of us to help provide that additional push and support. Internal practice talks and local meetups are useful steps to help transition to security’s conference circuit. This not only helps with retention – as it provides concrete professional development, not to mention corporate thought leadership – but it also helps recruitment and addressing the pipeline shortage. As a woman at Girls Who Code told me, and as research on role models supports, if they don’t see it, they won’t be it.

Diminish In-group/Out-group Dynamics

With extensive research stemming from political culture, cultural cohesion (at the most basic level) entails a shared identify. This shared identify cannot occur within an organization if certain social events, shwag, career paths, promotions, business departments, or really anything else, exclude specific demographic groups. Culture is extremely difficult to change and shape, with divisive behavior spreading faster than group cohesion.

Therefore, it requires both top-down and bottom-up strategies to achieve cultural change. At the leadership levels, executives must implement policies focused on diversity and inclusion, while hiring the most qualified candidates. Even simple rules of thumb such as looking for ‘cultural adds’ as opposed to ‘cultural fits’ can help ensure a more diverse workforce. This is possible, and must gain traction across all levels of the company. Even with the proper policies, they are by no means sufficient. Informal and formal leaders must work daily to shape an inclusive culture through daily interactions. Both visible cues and social cues are essential for bottom-up cultural impact, including website representation, interaction within social media, and simply by ensuring a team’s or departments’ social events include all members of the team. These are all common sense, but very rarely do corporations take the time to focus on these internal efforts to build cultural cohesion and increase parity, arguing that there isn’t “time to deal with all this other stuff.”  This myopic perspective ignores the wealth of research that not only highlights the positive impact of diversity at all levels on corporate revenue and profitability, but the impact of diversity on innovation as well.

Male Allies

It is well past time for viewing security’s gender gap as a woman’s problem. The gender imbalance within security is a corporate and industry problem, and men are necessary to help fix it. As a recent The Atlantic article noted, “You can’t drive change without men.” By placing the burden on the women in the company, an inherent gender tax is applied, wherein they are expected to do the same job as the men, plus the additional work of serving as the voice and advocate for all women in the industry. And as a reminder, we would much prefer talking about our area of expertise, not our gender. 

So what can men do? This gets asked all the time. Jessica Bennett has great insights on this, several of which I’ll paraphrase. Be a norm entrepreneur. Disrupt the status quo. Women are less likely to be cited, and more often to have other people take credit for their work. Provide credit where it is due. Structure equal career paths and promotion opportunities. Be an advocate or sponsor. Speak up. When men take to social media to call out specific misogynistic events or behavior at security conferences, it has an impact. When men refrain from participating on all-male panels, it has an impact. If you are in a position of leadership, be acutely aware of the kind of policies and work environments you foster. In short, be an ally.

Building stronger defenses cannot and will not occur without insights and innovation from half the population. A key component of instigating change is to move beyond (but acknowledge) the regressive statistics and challenges, and focus on supporting and elevating the voice of women currently in the industry.

In a few weeks, I’ll be attending the Women in Cybersecurity Conference with my colleagues in software development and design, and we’ll support our malware researcher Amanda Rousseau’s workshop on reverse engineering. Last year I attended solo, and it’s great to see what a difference a year can make. Clearly, there is much more work to be done, but the onus is on all of us to finally reverse this backward slide. 

At the end of January, Saudi Arabia’s telecom authority issued an alert warning about Shamoon 2, a wiper malware that hit several organizations, including three government agencies and four private sector companies. This latest attack is viewed as an evolution of the 2012 Shamoon malware that was responsible for debilitating gas giant Saudi Aramco, wiping three-quarters of its data. Saudi Arabia’s alert came over a month after the first resurgence of the new Shamoon variant, which hit Saudi civil aviation, the central bank, and other government agencies, erasing data and inflicting disruption across the country’s airports.

Shamoon 2 is not even the most sophisticated wiper malware currently targeting organizations. Stonedrill wiper malware has also been spotted in the Middle East and Europe, and is even more sophisticated in its ability to destroy infected targets as well as avoid detection and eradication. Stonedrill and Shamoon 2 wiper malware reflect escalation in technical capabilities, including the simultaneous detonation within several targets, enhanced evasion techniques, and the broader campaign style enacted over a few months at a broad range of targets. These attacks also mirror the evolving geopolitical landscape, and are increasingly employed as a response to heightened tensions between regional rivals and adversaries.  

We’ll briefly describe how Shamoon 2 and Stonedrill fit into the emerging trend of destructive attacks, as well as the status of global policy to counter these attacks. Next, we’ll get into the technical details of wiper malware, including how to catch and prevent it. In general, blocking wiper malware requires a strategy that is no different than that necessary to block other forms of digital compromise:  layered and signatureless defenses.

Destructive Attack Trends

The destructive attacks in Saudi Arabia, while still relatively rare, are by no means an anomaly. The destruction of Iranian nuclear centrifuges by the Stuxnet malware, first discovered in 2010, is largely seen as a turning point in the use of offensive digital weapons. The original variant of the Shamoon malware followed in 2012, wiping or destroying 35,000 computers. It took Saudi Aramco five months to fully return to business as usual. The Shamoon 2 malware appears to be the latest evolution in this regional rivalry. It also could be a response to the string of pipeline explosions in Iran last summer. While the Iranian government has not publicly attributed the explosions to cyber attacks, many experts believe the timing and frequency of the attacks were digitally induced.

The use of destructive malware is not limited to the Middle East. The Dark Seoul malware was part of a four-year campaign against the South Korean government, financial sector, and media. In 2013, the wiper malware erased data and permanently disabled thousands of infected computers. In late 2014, a German steel mill was the target of a cyber attack which hijacked a blast furnace, leading to a meltdown. Ukraine also has experienced digital attacks on their power grid in both 2015 and 2016, which are attributed to the BlackEnergy malware. There also is speculation that more recent variants of BlackEnergy contain KillDisk, wiper malware that may have made it more difficult to restore power. The Ukrainian and German steel mill attacks have been linked to Russia. Finally, within the US, Sony was the target of destructive malware stemming from North Korea, which rendered thousands of computers inoperable and caused enormous business disruption. The US was also the target of a failed attempt to take control of and damage the Rye, NY dam. This failed attack was linked to the larger Iranian campaign on financial institutions, which led to the indictments of seven Iranians in 2016.

Policy Landscape

This growing trend of destructive cyber operations has not gone unnoticed by the policy community. Over the last few years, a small group at the United Nations called the Group of Governmental Experts has led the global push for the creation of norms to halt the ongoing escalation of digital attacks across the globe. Intentionally damaging another country’s critical infrastructure during peacetime is a prominent norm that gained the most consensus. Similarly, the recently released Tallinn Manual 2.0 provides a consolidated overview of how current international law pertains to cyberspace. Written by nineteen international law experts, the manual’s first rule is that, “A State may exercise control over cyber infrastructure and activity within its sovereign territory.”

A key aspect of the revised Tallinn Manual is the emphasis on those digital activities that fall short of war, which is largely distinguished by the Law of Armed Conflict. Too often these are confounded, and international frameworks pertaining to cyberspace largely emphasize appropriate behavior in peacetime. But which activities constitute an act of war and what is acceptable in peacetime? For the most part, this remains vague. For instance, NATO’s Article V now includes digital attacks as capable of triggering collective security, but it is unclear what those triggering events would be. The US Law of War Manual is indicative of the current state of policy, and leans on any activity whose effect would be perceived as an act of war under more ‘traditional’ kinetic activities would similarly be perceived as an act of war if achieved through digital means. Additional clarity is needed, and the policy and legal frameworks must rapidly evolve to address the emerging use of destructive malware before some global event renders much of these discussions obsolete. 

What is Wiper Malware?

Destructive cyber attacks can take several forms, and not all of them integrate wiper malware. However, as the latest Shamoon and Stonedrill variants demonstrate, wiper malware is among the most straightforward for attackers to achieve destructive effects.  It is far easier to reliably destroy data on a hard drive than to create predictable effects such as power outages and pipeline explosions in the physical world via compromised computers.  While reliable prevention of cyber attacks against the power grid may require very specific tools, skills, and analysis such as detecting modified programmable logic controller (PLC)  firmware, defenses which prevent wiper malware without requiring any specific prior knowledge of an attack are within the reach of all organizations.  

Wiper malware is similar to file-encrypting ransomware, as each have a similar intent of preventing the ability to read or recover critical data.  In the case of ransomware, the malicious action can often be reversed once the user pays for the cryptographic key or recovers the key through other means such as reverse engineering.  But with wiper malware, the damage is irreversible.  Data is usually overwritten or encrypted, sometimes offering the operator configuration options to select the desired effect. For example, Shamoon 2 offers an encryption mode and an overwrite mode, either encrypting files or alternatively overwriting them with an image of a dead Syrian refugee child.  Shamoon 2 (as well as the original variant) also includes a raw disk access driver to allow the malware to modify the partition table and Master Boot Record to create further damage.  

Detection and prevention of wiper malware should not focus on the end effect.  Wiper malware has a similar attack lifecycle to other categories of malware.  Similar techniques are used to deploy code to systems, evade defenses, and persist.  This provides many points for detection and prevention, just like other types of malicious cyber activity.

Protection against Destructive Attacks

Our signature-less, layered preventions stop both Shamoon 2 and Stonedrill without specific tuning, signature creation, or any prior knowledge about the malware and its behaviors. The latest version of Endgame’s MalwareScore immediately designates the initially loaded Shamoon 2 binary as malware, preventing the attack at its outset.  In other words, Shamoon 2 would be detected when dropped to disk, execution would be prevented, and the destructive attack averted.  

But, malware won’t always be used and some malware will evade even the best signatureless malware detection product.  Layered defenses are necessary safeguards for high confidence detection and prevention. The initial Shamoon 2 malware extracts two other files to c:\windows\system32 and immediately runs them.  Each will also be detected by MalwareScore. However, even if Shamoon 2 previously infected a system before Endgame was deployed, or if MalwareScore was inactive or failed, Shamoon 2 would still be discovered.  The clearest place this stands out is via Endgame’s malicious persistence detection, which depicts the Shamoon 2 malware as a very suspicious file waiting for the prescribed attack time.  As we’ve discussed before, hunting for persistence is one of the best ways to find resident malware, including wiper malware, which persists as a scheduled task on compromised systems.  

While Shamoon 2 is higher profile, Stonedrill actually incorporates more advanced evasion techniques which, for Endgame, offer additional opportunities for detection.  As with Shamoon 2, Endgame’s prevention layer with MalwareScore would block the initial loader malware.  Even if we allow execution, as with Shamoon 2, Endgame would still easily spot, block, and remediate Stonedrill before damage occurs. After allowing this bypass, the malware spawns several versions of two additional malicious files via Windows Management Instrumentation. The malware then injects into the system’s default web browser to hide from file-based preventions, a fast growing technique to evade defenses. In this case, Endgame’s prevention blocks the injection.  Additionally, even if Endgame came into the compromised environment after the injection, our fileless attack detection capability would catch the in-memory injection in seconds.  Finally, we wanted to see what would happen if we intentionally let the attack get to the point of initiating destruction. Our behavioral ransomware protection capability provided a final point of prevention. Our behavioral ransomware protection detects Stonedrill’s destructive activity as resembling ransomware activity in real-time, stopping it immediately after it begins but before significant damage occurs.  

The video below demonstrates how Endgame’s layered approach catches both Shamoon 2 and Stonedrill, even post-compromise, to prevent destruction.  

Different Effects, Same Prevention

While destructive attacks - especially those on power grids and other critical infrastructure - are rare, the what-if scenarios of destructive malware are no longer theoretical. Shamoon 2 and Stonedrill demonstrate the application of wiper malware integrated into a larger strategy as geopolitical tensions rise.  Shamoon 2 has had destructive effects within Saudi Arabia, and now both Shamoon 2 and Stonedrill are spreading beyond the Middle East and into Europe.

This emergence of destructive malware occurs simultaneously with rising geopolitical tensions between major powers and within regional rivalries. As states seek greater capabilities and new means to achieve their objectives, destructive malware has proven effective as a response to growing tensions, while remaining short of war. The pace of diffusion of destructive malware is likely to far exceed the pace of global policy change and embedded norms, which currently have little impact on its propagation.

Fortunately, Endgame’s approach to protection demonstrates that our layered and signatureless defenses against non-destructive forms of cyber intrusion also prove capable of stopping these latest and most sophisticated forms of wiper malware. Organizations, especially those within these geopolitical hot spots, should heed these latest warnings about Shamoon 2 and Stonedrill, while understanding that it does not take nation-state resources and capabilities to stop them.

Reverse engineering already sounds like black magic, when in reality it simply entails lots of practice and strong foundations in computer science concepts. Think of it like learning a new language. First, you must know the building blocks to a sentence, and then keep practicing until you can speak fluently. Reverse engineering works the same way. Malware analysts and researchers use reverse engineering as a tool to understand the behavior of the malware sample in order to detect, prevent, or get rid of it.

So what do reverse engineers do? At their core, reverse engineers:

• Take things apart to figure out how they work
• Love puzzle solving
• Develop experiments and tools
• Can think outside the box
• Constantly learn new things 

If that sounds like you, reverse engineering malware may be your calling.

Unfortunately, the perception that reverse engineering is a black magic keeps many people from giving it a shot.  And too often you may not fully understand what you learned in computer science courses, or it may not be intuitive to apply that knowledge to the real world.  So I created a workshop that is easy to understand and easy to follow along, and presented it last week at the Women in Cybersecurity Conference in Tucson, AZ.

Women in Cybersecurity Conference Reverse Engineering Workshop

The best way to learn is by getting hands on practice. In this workshop, the main take away is learning how to set analysis goals. By using tools and computer science concepts you can work step by step to those analysis goals. The executable provided at the workshop link contains many malware-like techniques for you to work through, and also includes a secret image to discover at the end of the analysis. The workshop is broken up into six sections:

1) Setup and Fundamentals

• Setting up a baseline analysis environment
• Anatomy of a Microsoft Windows PE program
• X86 Assembly

2) Malware Techniques

• Attack Flow
• Malware Classes
• Techniques

3) Reverse Engineering Tools

• Disassemblers
• Debuggers
• Information Gathering

4) Triage Analysis (Lab 1)

• Using Information Gathering Tools
• Lab 1

5) Static Analysis (Lab 2)

• Reading disassembled code
• Lab 2    

6) Dynamic Analysis (Lab 3)

• Manual Debugging
• Lab 3
• Finding the secret image

Over the course of the workshop, you’ll get step-by-step guidance on the fundamentals of reverse engineering, and learn the various techniques and tools. You’ll then get a chance to reverse engineer on your own in both static and dynamic analysis environments. For those of you with a background in reverse engineering, this should be a great refresher, and for those new to the field, enjoy!

As tensions rise between North Korea and the United States, Secretary of Homeland Security, John Kelly, proclaimed North Korea currently is a more probable cyber threat than a kinetic threat. Given North Korea’s inclination to use digital weapons over the past few years, this is not a controversial statement, but it should not be assumed that this is a matter simply contained to the governments. If past behavior is any indication, should North Korea opt for a digital response, the private sector, not the public sector, may be disproportionately targeted.

Abridged Summary of North Korean Digital Behavior

The Sony attack is perhaps the most well-known public attribution of a North Korean digital attack, and more specifically the hacking group Lazarus. In late 2014, a combination of targeted spear phishing - including scraping social networks and password reuse of even those with low-level privileges -  and technical vulnerabilities resulted in significant reputational as well as financial losses for Sony. For many, Sony served as an inflection point, manifesting the real-world and existential impact a digital attack can have on a corporation. A 2015 60 Minutes segment summarized this perceived inflection point triggered by the Sony attack, noting,“you don't have to be a superpower to inflict damage on U.S. corporations.”

In addition to the Sony attack, North Korth has also been blamed for digital attacks targeting South Korean corporations, including media and financial institutions. South Korea also has blamed North Korea for an attack on the energy sector, including nuclear reactors run by the Korea Hydro and Nuclear Power Co, again often using large-scale phishing campaigns targeting thousands of employees to gain access. North Korea has also been accused of digital attacks targeting defense and high-tech companies in both South Korea and Japan.

More recently, North Korea has been linked to the 2016 digital attacks targeting the SWIFT payment system, which resulted in an $81 million heist from the Bangladesh Central Bank. Some of the code used in the Bangladesh heist appears to have been repurposed from the Sony attack. It is currently believed that the attackers gained access using stolen credentials, again demonstrating the various fileless attack vectors increasingly employed.  Recently, several North Korean banks, which were already blacklisted by United Nations sanctions, have been banned from the SWIFT system as well.

Diversifying the Economy and Targets

Pyongyang continues to be impacted by international sanctions and the limitations of a centrally planned economy, forcing the government to diversify tactics and revenue streams. Digital attacks are an efficient revenue stream and means to achieve strategic objectives against larger powers. The group most-frequently associated with North Korean high profile attacks, Lazarus, is affiliated with North Korea’s elite hacking group, Bureau 121. Largely believed to be located in China, the size of Bureau 121 is not certain, but may be comprised of 1800 specialists according to one defector, while others estimate the overall size of North Korea’s hacking groups to closer to 6800, with a revenue of $860 million prior to the SWIFT heist.

They also have global reach. In addition to targeting the United States and South Korea, North Korea is also targeting institutions in eighteen different countries, largely in developing economies across the globe. However, while globally North Korea remains focused on the banking system, within the United States and South Korea the target set is much broader, focusing on media companies, financial institutions, and critical infrastructure.

Geopolitical Spillover

State-sponsored and affiliated attacks are increasingly targeting the private sector and thanks to both social and technical vulnerabilities, are likely to successfully compromise networks. While missiles and nuclear capabilities have understandably garnered the most attention in the rising tensions between the United States and North Korea, it would be myopic to overlook the potential impact of digital attacks.

Past behavior strongly indicates North Korea’s propensity to employ digital weapons given the asymmetric advantages and their growing expertise. The recent initial reports speculating that the North Korean missile test failed due to sabotage by the United States is only amplifying the situation. With the regime increasingly cornered by an existential threat, North Korea may well lean on past success and ratchet up targeted digital attacks at a range of corporations as tensions persist with the United States.