Security Now
Security is top-of-mind everywhere, especially right here where Juniper experts share their thoughts on the latest security breakthroughs and product advancements
Showing results for 
Search instead for 
Do you mean 

Automating Cyber Threat Intelligence with SkyATP: Part One

by Juniper Employee ‎10-17-2016 09:55 AM - edited ‎10-17-2016 10:25 AM

Each year, the economics of "fighting back" against Hacktivism, CyberCrime, and the occasional State-Sponsored attack become more and more untenable for the typical Enterprise. It's nearly impossible for the average Security Team to stay up to date with the latest emerging threats while also being tasked with their regular duties. Given the current economic climate, the luxury of having a dedicated team to perform Cyber Threat Intelligence (CTI) is generally out of reach for all but the largest of Enterprises. While automated identification, curation, and enforcement of CTI cannot truly replace human Security Analysts (yet), it has been shown to go a long way towards increasing the effectiveness and agility of your Security infrastructure. 


The idea of a lone hacker maliciously tapping away in a dark room is an antiquated one. The business of cybercrime is now a multibillion-dollar enterprise with highly organized entities looking to exploit vulnerabilities and scam businesses and consumers in our increasingly networked world. According to a Juniper commissioned report from the RAND Corporation:


The cyber black market has evolved from a varied landscape of discrete, ad hoc individuals into a network of highly organized groups, often connected with traditional crime groups (e.g., drug cartels, mafias, terrorist cells) and nation-states. It does not differ much from a traditional market or other typical criminal enterprises; participants communicate through various channels, place their orders, and get products.


Today, attackers are much more efficient in their efforts than ever before, driven by the ability to work with others in the criminal underground. Left unchecked, I worry that the ability to defend against these organizations will be more challenging.


Traditional cybersecurity approaches involving perimeter-only protection are no longer enough to prevent data breaches and potential data exfiltration. Our cyber adversaries have grown in sophistication with very little training and inexpensive equipment. The standard attack anatomy is changing. Protection against state actors, lone wolf actors, and insider threats is becoming increasingly problematic. The evolution of threats has necessitated a change in the security mindset from high-trust (trust what’s inside) to zero-trust (trust nothing) posture. So, the traditional methods of high-trust security have created a type of architected fragility that is inflexible and unable to adapt quickly or at all to protect against the constant barrage of cyber threats.


In his keynote speech during the RSA conference of 2011, the former director of the NSA, Gen. Keith B. Alexander made an interesting statement: “Securing our nation’s network is a team sport”. It is cleared now than ever, that no-one can fight the cyber war alone, and community efforts sharing cyber threat intelligence could benefit all participants, even in a competitive environment.


When referring to modern cyber threats, the attackers seem to have the upper hand. Regardless of their motivation, their engagement with the target has many asymmetric characteristics which work in their benefit, creating the need for new defense concepts deployed is a seemingly never ending arms race.

One of those new concepts is the sharing of real-time actionable cyber threat intelligence (CTI) - the exchange of dynamic feed of threat or attack related objects utilized for enforcement or analysis at the receiving end. Sharing CTI between different organizations, represents a collaborative effort to improve cyber defense posture by leveraging the capabilities, knowledge, and experience of the broader community. Such deployments may take different technological and structural forms, eventually reducing duplication of effort while enabling one organization’s detection to become another organization’s prevention.


In recent years, a growing number of sharing alliances have emerged, either between individuals using social networks, within the same vertical market, across different sectors in the same geography, between commercial and government bodies, and even among countries. In many cases these sharing initiatives represent a shift in the organization’s legacy IT paradigm, and create a complex, multifaceted challenge to technology, law, organizational culture, privacy and more[1]. These challenges are bigger when the parties are direct competitors or have other conflicts of interests, as demonstrated in my research-in-progress conducted at the Blavatnik Interdisciplinary Cyber Research Center (ICRC). The research analyzes threat intelligence sharing between cybersecurity vendors, with the goal to create visibility and understanding of the formed ecosystem within this industry. Since the shared information is closely related to the core business of the firms, it presents clearly the challenge of combining collaboration with competition named as coopetition.


Security vendors have already embraced CTI as a defense concept providing their customers with a viable solution, but the disaggregation of the solution elements described in  Figure 1, allows them to mutually use feeds from each other, or provide their threat intelligence using another vendor as a sales through channel. These three elements may belong to one or several vendors, and deployed as a single or multiple products either on customer premises or in the cloud. The source point of the information flow is a threat intelligence feed, and the destination is a policy enforcement or decision point. In between, an optional element called Threat Intelligence Platform (TIP) may act as an exchange point tying several sources and destinations together. Integration between all elements is based on either proprietary API’s or evolving standards such as STIX™, TAXII™, and CyBOX™.


Figure 1 – Disaggregated elements of threat intelligence sharingFigure 1 – Disaggregated elements of threat intelligence sharingThe key findings of the research suggest that cooperating with competitors is a winning strategy, showing correlation between market-related success indicators of a vendor, to its number of sharing relationships. Furthermore, the industry as a whole is a coopetition fit environment divided into social network communities, where successful companies attract new relationships more, following the ”rich-gets-richer” phenomenon. In addition, intelligence sharing can result in better security coverage, direct and indirect financial gains, and benefit to the greater good.


Given the possible advantages to companies, and the challenge of fighting the cyber war alone, many organizations are reconsidering their policy on sharing cyber related information with outside parties, literally demonstrating that crowd wisdom is applicable in the cybersecurity domain. For more on the topic from both academic and industry perspectives, join my presentation “101 to Threat intelligence Sharing”, at the (ISC)² Security Congress EMEA in Dublin 18-19 October 2016, or at the CSX 2016 Europe conference in London 31 October-2 November 2016.


[1] Zrahia, A. (2014). A multidisciplinary analysis of cyber information sharing. Military and Strategic Affairs, 6(3), 59-77. E-ISSN 2307-8634. The Institute for National Security Studies (INSS), Tel-Aviv University.

Far from a back room, IT-centric issue, cybersecurity is now front and center as organizations of all sizes work to define and execute strategies that mitigate risk and defend and combat against attacks. In order for companies to be as prepared as possible, a strong and effective cybersecurity strategy requires active board participation. Cybersecurity is no longer the sole responsibility of the Chief Information Officer or technical focused employees. Industry-leading companies understand this and are planning and executing accordingly.


Back in the day, the first thing you did to protect your organization from cybercrime was get a network firewall. Then, maybe, you would get some anti-virus software for your endpoints. You looked at specific traffic from specific places outside your network and with brute-force access lists and policies you controlled users and traffic. You thought your business was secure. And it used to be.


Return-oriented programming, or ROP, is a clever technique used to get around the NX (No-eXecute) and DEP (Data Execution Prevention) mitigations in modern CPUs and operating systems. Traditionally, exploiting a vulnerable program has consisted of the following:


  1. Find a programming error in the application (for example, Adobe Flash) that allows specially crafted input to overflow or otherwise corrupt an allocated region in memory.
  2. Inject executable code (shellcode) into the program’s memory
  3. Transfer control to this new code by overwriting control information such as a return address on the call stack. 

With this technique, simply opening a document or media file results in arbitrary code being executed on the target’s system. The attacker has control and can download additional malware, exfiltrate information, install spyware or hooks for persistence, etc.


Here's a simple example of a program vulnerable to a memory corruption attack. The attack takes advantage of the insecure gets() function, which reads a string from the console and writes it to a specified location in memory without checking whether there is enough space available.




When the function buggy() is called, the computer stores the return address (the next instruction in main() following the function call) on the program's call stack in memory. After buggy() finishes, the program execution should return to the address 0x00401047 (seen reversed here in the program's memory because x86 is a little-Endian architecture).



The name entered by the user is also stored on the stack in the 8 characters allocated for 'str'.


But if we enter more than 8 characters, the gets() function will happily overwrite adjacent memory:



Note that the final two characters -- the final 'n' in Langton and the null character used to indicate the end of the string -- have clobbered half of the return address. The result is a crash as the control jumps to the garbled address 0x0040006E. But an attacker can go further by including executable shell code in the input string and overwriting the original return address so that program control now jumps to the attacker's own code.


NX (No-eXecute) and DEP (Data Execution Prevention) counter this type of exploit by ensuring at the hardware level that a given section of memory is writable or executable, but not both. Even if the attacker finds a memory vulnerability and injects shellcode, the CPU will refuse to execute those instructions. Return-oriented programming gets past this limitation by (mis)using the existing code in the application in ways that were not intended.


To understand how this works, we’ll start with an analogy. In Wisconsin, there is an executive power known as the Frankenstein veto, which allows a governor to selectively reject individual words of a proposed bill. Here’s an example:



By selectively vetoing single words and phrases, the proposed law was changed from:


[...] the secretary of administration shall lapse to the general fund or transfer to the general fund from the unencumbered balances of the appropriations to state agencies, as defined in subsection (1w) (a), other than sum sufficient appropriations and appropriations of federal revenues, an amount equal to $724,900 during the 2006−07 fiscal year [...]




[...], the secretary of administration shall transfer from the balances of the general fund  an amount equal to $330,000,000 during the 2005−06 fiscal year and the 2006−07 fiscal year [...]


By selectively repurposing the existing text, the governor changed an appropriation by nearly three orders of magnitude. (An earlier incarnation of this executive power allowed governors to “veto” individual letters in a bill!)


Similarly, return-oriented programming reuses existing snippets of the vulnerable application’s instructions for purposes that were not intended. By overwriting portions of the call stack, the ROP exploit jumps around the program, each time selectively executing a small number of instructions preceding a function’s 'ret' statement (hence the name).


As we saw above, we can exploit a programming error to overwrite a function's return address on the stack. This allows us to transfer program control to an arbitrary location. Consider the following function fragment:



By setting the return address to 0x0040A4BB while overwriting the stack, we jump into the end of this function, setting the register eax to 0 by XORing it with itself. The return instruction at 0x0040ABD expects to find another return address on the stack, but this too can be overwritten along with the previous address. A chunk of code (mis)used in this fashion is called a ROP gadget, and a ROP exploit is formed by a chain of such gadgets called in sequence due to the intentionally corrupted stack memory. Due to the difficulty of constructing a suitable sequence of bytes to overwrite the stack and control program flow through a sequence of function fragments, this technique is used only as long as necessary; a common approach is to use ROP to bypass DEP, and after that to use more traditional techniques to complete the exploit.


With an understanding of the mechanism behind ROP exploits, we get to the question that prompted this post: does Sky ATP attempt to directly detect ROP exploits? The answer is no, for the following reasons:


  1. ROP detection is redundant in an anti-malware sandbox. ROP is only used as a stepping stone to run malicious code on a device. The purpose of malware is to do something malicious: ransomware, a backdoor to add the victim's computer to a botnet, data exfiltration, etc. Sky ATP's dynamic analysis engine detects a rich set of malicious indicators, whether or not the malware's initial foothold came from a ROP exploit.
  2. ROP exploits are system-specific and fragile, so detecting them in a sandbox is highly unlikely. As we saw previously, ROP exploits target programming errors in an installed application, and so the sandbox must also be configured with the same vulnerable version. Beyond this, since ROP exploits jump around raw executable code, small changes to a sandbox's configuration (different versions of system libraries, hardware variations, etc.) frequently render an attack as inert, resulting in -- at most -- an application crash, not a successful exploit. One should ask anti-malware vendors touting their ROP detection how many times they have detected an actual ROP exploit in the wild.
  3. ROP detection is very resource-intensive. Monitoring system activities at the hardware level needed to observe ROP patterns in the program flow is both very slow and much easier for evasive malware to detect.

The low probability of actually detecting a live ROP exploit must be balanced against the high cost of CPU-level emulation. Multiply this by the number of systems a sample must be run on to ensure some likelihood of an exploit/vulnerability match, and the cost-benefit ratio is abysmal at best. And because a successful exploit would also be detected by behavioral indicators, most anti-malware solutions -- including Sky ATP -- do not perform direct ROP detection.

Improving Cybersecurity - Back To Basics

by Juniper Employee ‎10-03-2016 09:00 AM - edited ‎10-03-2016 01:21 PM

In recent years, high profile cyber events such as the Office of Personnel Management (OPM) data breach and the SONY hack have received significant public and media attention, which in turn has increased the level of attention given to larger issues of cybersecurity. With such attention, it is easy to understand why government officials and many others continue to focus on the consequences of major cybersecurity events.


SVM separating dataSVM separating data

What are the typical mistakes people make when training/evaluating machine learning models? How do we avoid making these mistakes?


In this month's blog, we'll look at one example from a simple but evasive dropper family that we saw frequently in August, with a focus on techniques used to actively evade analysis and detection. This sample retains some of the author's debugging information, which helpfully labels the project as "ResourceDropper":



The executable code is obfuscated to deter static analysis, and the final payload is encrypted. The compiled code resolves many dependencies at runtime with GetProcAddress, which is often used to obscure the underlying functionality from static analysis.



The malware also checks for a number of indications that it is being analyzed in a sandbox or a debugger. It begins by checking directly whether a debugger is attached.



The sample then accesses the Process Environment Block to look for indirect indications of debugging or analysis, followed by specific checks for a number of popular anti-malware products (using obfuscated product names):



The malware exits quickly if any anti-anti-malware checks succeed. Otherwise, it drops and executes another malicious file, this one masquerading as a Java updater. The dropped/injected file copies then deletes itself on launch (another strong indicator of maliciousness!) and it too checks for signs it is being analyzed. In its process memory, we find that it checks for a DLL associated with Sandboxie.


The malware goes on to look for Window product IDs known to be associated with particular sandboxes or antimalware products.  keys.png 

Once past all of these precautions, the malware attempts to harvest user credentials (including FTP logins, as seen below) and opens a persistent backdoor. 


The evasion techniques seen here are not particularly sophisticated; we've seen malware check for all sorts of indicators that a human user is present (mouse movements, for example), check the system specifications to see if the machine looks genuine (is the hard drive big enough and are there enough processor cores?), or require specific command-line parameters to ensure it is not being analyzed separately from the script that should have downloaded it. The result is a cat-and-mouse routine between malware authors and the anti-malware industry as the malware authors attempt to delay detection for as long as possible to ensure maximum return on their efforts. In Sky ATP, we search for dozens of indicators that a sample is trying to identify an analysis system and evade detection, and we continue to add new features. In addition, our machine-learning engines are trained on a constantly updated set that includes the newest evasive malware, enabling us to detect evasive behavior as these techniques evolve.


Once again, thanks for reading! Check back soon for an upcoming post about return-oriented programming (ROP).

We hear a lot about being “always on” and having “100 percent uptime.” While this is a reasonable expectation, it’s a difficult task to accomplish when an outage occurs due to a disaster or some other unavoidable circumstance. What to do in such a situation is a dilemma that keeps IT professionals on the edge of their seats and reaching for the latest technology that can keep their workloads backed up and secure in a time of need.


New threats in July 2016

by Juniper Employee ‎08-26-2016 06:16 PM - edited ‎08-29-2016 06:00 PM

(This post is the first in a monthly series highlighting some of the new threats detected by Sky ATP's deep analysis engines.)


In July, Sky ATP detected tens of thousands of malicious applications and documents as they passed through SRX firewalls. While most of these were known threats, Sky ATP also detected new malware strains, including multiple forms of ransomware as well as assorted trojans, droppers, spyware, and other potentially unwanted programs. In this post, we'll look at two new ransomware variants, plus an old threat that has evolved into highly-evasive (almost) fileless malware.


Early in the Sky ATP analysis pipeline, we run each new sample against a suite of anti-virus engines. AV engines are a fast and efficient way to catch and filter out known threats and their close variants. Removing these known threats from the analysis pipeline as early as possible reduces the load on the more computationally-expensive parts of the pipeline, which includes static analysis engines and full sandbox detonation. But for new threats, hashes and signatures are not enough. In this post, we’ll look at some of the threats we saw in July, which were undetected by numerous AV engines but caught by Sky ATP’s deep analysis.


Zepto ransomware

We discussed Locky in previous posts. Zepto is a new variant, but looks and behaves much like Locky, except it uses ".zepto" as the file extension for the encrypted files:


zepto_files.pngAs with Locky (and most other ransomware), the victim is notified by pop-up images, text files, and a new desktop background with instructions on how to convert the ransom payment to bitcoin and deliver it via a site on the dark web.




Cerber ransomware

Sky ATP’s deep analysis detected a number of variants of the Cerber ransomware that evaded traditional antivirus engines. The ransom process includes an automated voice announcing the infection.



Kovter's (almost) fileless malware

Some of the most interesting samples detected by our deep analysis pipeline in July were several variants of the Kovter click-fraud malware. This malware strain has become increasingly evasive and maintains almost fileless persistence on a victim’s machine.

Kovter’s foothold begins with obfuscated Javascript and binary content saved in the Windows registry.




Kovter's authors use a clever trick to achieve persistence without leaving any of their malware on the actual Windows filesystem. The malware drops a randomly generated file with an arbitrary (but important!) file extension, along with a batch file and a shortcut.




The batch file "opens" the garbage .fcb676eie file with the start command




Instead of opening the file, a registry key associated with the .fcb676eie extension instructs Windows to execute an altogether different command.




This uses Microsoft's mshta engine to execute the obfuscated Javascript stored in the registry. The bulk of the payload is a 5000+ character hexadecimal string, with is decoded and executed with the Javascript eval() function. This produces another Javascript program, this time with a very long string encoded in Base64




This, in turn, is decoded to form a Powershell script containing raw shellcode that is injected and launched to create a malicious Windows process, using a technique taken from an old Metasploit template.




With this convoluted process, the malware can remain on the victim's computer without leaving anything on the filesystem besides the garbage file and its associated batch file and shortcut. Its malicious behavior, however, is still detected by Sky ATP's deep analysis techniques.

Until next month...

As mentioned above, these threats are just a few of many detected by Sky ATP's deep analysis engines. Thanks for reading, and please check back next month for another installment in this series!

Juniper Networks expands its portfolio of US Department of Defense certified devices.


What ransomware does to animals..What ransomware does to animals..

Can ransomware attack cloud data? Are you safe if you use online backups or backup services like Dropbox or Google Drive?  It depends...


About Security Now

Discussing a wide range of topics impacting enterprises and
data center security.

Subscribe RSS Icon

Our Bloggers

Jennifer Blatnik
Vice President
Enterprise Portfolio Marketing

Profile | Subscribe

Ritesh Agrawal
Software Engineering

Profile | Subscribe

Scott Emo
Product Marketing

Profile | Subscribe

Bill Shelton
Director Field Sales

Profile | Subscribe


Juniper Innovators Circle