Category Archives: Palo Alto

  • 0

Decline in Rig Exploit Kit

Category : Palo Alto

Starting in April 2017, we saw a significant decrease in Rig exploit kit (EK) activity after two major campaigns, EITest and pseudo-Darkleech, stopped using EKs. Figure 1 shows the hits for the Rig EK from December 2016 through May 2017, highlighting this trend.

This blog reviews recent developments in the EITest and pseudo-Darkleech campaigns that have contributed to the current drop in Rig EK. We also explore other causes for the overall decline of EK activity as others have noted in recent reports. Finally, due to the anemic nature of today’s EK scene, we review some methods criminals are focusing on for malware distribution.


Figure 1: Hits for Rig EK from December 2016 through May 2017.

Two Major Campaigns Stop Using Rig EK

At the very end of March 2017, researchers stopped seeing indicators of the pseudo-Darkleech campaign. Pseudo-Darkleech was a long-running campaign that switched to Rig EK in September 2016. Since September 2016, pseudo-Darkleech accounted for a significant amount of Rig EK seen on a daily basis. When pseudo-Darkleech disappeared, Rig EK activity dropped approximately 50 percent from previous months.

Three to four weeks later, another long-running campaign cut back on its use of Rig EK. Near the end of April 2017, the EITest campaign began pushing tech support scams. Previously, EITest had also generated a great deal of Rig EK traffic, but as the criminals behind this activity began focusing on other techniques, Rig EK levels dropped another 50 percent in May 2017. As we enter June, EITest is primarily pushing tech support scams, and it does not appear to be utilizing EKs at this time.

Figure 2 shows the hits for Rig EK from March 1, 2017 through May 31, 2017 in more detail. Note on the chart when pseudo-Darkleech disappears and EITest shifts focus and their impact on Rig EK traffic.

Although researchers still find Rig from other campaigns like RoughTed or Seamless, recent levels are their lowest since we began tracking this EK.


Figure 2: Rig EK hits from March 1st through May 31st, 2017.

Not the Threat They Once Were

Rig is not the only EK suffering in today’s threat landscape. All EKs have been affected. So why aren’t EKs as active as they once were?

One contributing factor is that the target surface for EKs is getting smaller.

EKs typically use browser-based exploits targeting Microsoft Windows systems. They are primarily focused on Internet Explorer, Microsoft Edge, and Adobe Flash Player. EKs are largely ineffective against more popular browsers like Chrome, a product that has gone through four major version updates this year alone.

Users (potential victims) are moving to other browsers, and this has greatly reduced the number of possible targets for current EKs. As shown below in Figure 3, as of May 2017, only 19 percent of the desktop browser market was taken by Microsoft Edge and Internet Explorer 11 combined.


Figure 3: Desktop browser market share in May 2017 from

With a declining target base, EKs are not aging gracefully. In previous years, we saw a variety of EKs used by various campaigns. But by the end of 2015, notable EKs like Sweet Orange and Fiesta had disappeared. As 2016 progressed, other prominent EKs like Nuclear and Angler also shut down. The graveyard of expired EKs has several dozen names by now.

This lack of diversity has impacted EK development. According to Proofpoint, more than a year has passed since any major EK has featured a zero-day exploit, making EKs far less effective compared to previous years.

Furthermore, the security community has been much more active against EKs. Recent efforts by Cisco Talos in 2016 and RSA Research in 2017 have seen researchers coordinating with hosting providers to take down servers used in domain shadowingschemes favored by EKs. The resulting setbacks have not been permanent, but they have significantly impacted operations for criminals using EKs.

Ultimately, a declining browser target base, lack of new exploits, and recent efforts by the community to fight domain shadowing have all contributed to an overall decline in EK activity.

What Are Criminals Turning To?

As EKs become more ineffective, criminals are focusing on other methods like malicious spam attacks, or social engineering schemes like HoeflerText notifications  like shown in Figure 4. Whether through spam or a browser popup, criminals trick potential victims into double-clicking a file that infects their computers.


Figure 4: A fake HoeflerText notification in Google Chrome that leads to malware.

In some cases, URLs will redirect to an EK one day and then on following days will often redirect to a fake installer for something like Adobe Flash Player like shown in Figure 5. These social engineering schemes are becoming more common, and researchers often run across them as they search for EKs.


Figure 5: Fake Flash installer distributing the same malware Rig EK did the day prior.

In some cases, criminals have turned away from malware entirely, and are focusing on apparently more lucrative activity. For example, the EITest campaign has switched to pushing tech support scams. At first, this seemed to be location-based, targeting the US and UK. However, as we go into June 2017, this type of activity is all we have found from the EITest campaign in recent days.

Figure 6 below shows a page viewed on June 7th, 2017 from a website compromised by the EITest campaign. The highlighted portion is a URL that redirects to a tech support scam website shown in Figure 7 that states your computer has been infected.


Figure 6: Injected script in page from a site compromised by the EITest campaign.


Figure 7: The tech support scam site.

This particular campaign also has audio continually reinforcing the same information. You cannot simply click okay or close the browser. The windows will immediately reappear. In order to close the browser and stop the audio, you must use the task manager to kill the browser process.

These tech support scams have been so successful that they are now a constant feature of our threat landscape. The EITest campaign has been pushing them for more than a month now.


Although EK activity levels are down, we still see indicators of Rig and Magnitude on a near-daily basis. But EKs are a relatively minor factor in today’s threat landscape compared to social engineering schemes and malspam. Users who follow best security practices are much less likely to be affected by the EK threat.

However, this situation could change as new exploits appear and updated techniques are used in malware distribution. It always pays to be prepared. Threat detection, preventions, and protection solutions like Palo Alto Networks next-generation security platform are a key part of any prevention strategy.


  • 0

MNOs Want Better Security: Achieving Threat Prevention in a Hyper-Connected 5G Environment

Category : Palo Alto

Only a few years ago, the world was buzzing with the term “4G.” While many mobile network operators (MNOs) are still rolling out their 4G infrastructures, the world is already buzzing about “5G.” Year 2020 is the suggested timeline for when MNOs are predicting to be ready for 5G. Development is already in the works with IETF,  3GPP5G-PPPETSIand NGMN, to name a few. Many government bodies, such as the European Union, are funding 5G rollouts pre-2020 using pre-standard technologies.

But what’s in it for an average user to be hyper-excited about hyper-connected 5G? How do MNOs view 5G? What are the security challenges that MNOs will need to face with a 5G rollout?

From an average user’s perspective, 5G will bring ultra-low latency, high speeds reaching up to 10Gb/s per user equipment and richness of services on-demand, as well as ultra-high availability, reliability, and interconnectivity with everyone and everything through connected devices, nowadays commonly referred to as the internet of things (IoT).


Source: 5G Vision, 5G-PPP

For MNOs, 5G implies the introduction of new service models; deep technical modifications in radio and optical technologies; network infrastructures transformations to software-defined networks (SDNs) and network functions virtualization (NFV); and unprecedented demand for preventive security.

Nowadays, MNOs are quickly realizing large gaps in their security posture, even within their 4G infrastructures – no longer can security be treated as an afterthought. Security needs to be part of overall infrastructure design from its outset; instead of asking, “How much would it cost to have security?” we need to ask, “How much will it cost if there is inadequate security?”

Think of the recent massive WanaCrypt0r ransomware attack (You can read about Palo Alto Networks protections against WanaCrypt0r, and see a detailed breakdown by our Unit 42 threat research team). The attack hit many organizations globally, including quite a few MNOs. What is the price tag to bridge that security gap? Could the attack have been prevented? Think further … what is the price tag associated with signaling attacks, such as S1-AP paging floods, Diameter 3GPP Update Location Request (ULR) and Authentication Information Request (AIR) floods, or GTP Control plane floods? Just imagine billions of zombie devices requesting to be attached at the same time, as instructed.


MMEs/vMMEs and HSSs/vHSSs simply cannot sustain such “misbehavior,” and die. That forces MNOs to overprovision their 4G – and soon 5G – infrastructures. What is the price associated with that? In addition to “killing” a few core elements, zombie IoT devices’ batteries won’t last long, breaking the desired IoT protocol’s behavior, targeting to preserve device battery life … well, as more infected devices get robotized, killing battery life becomes an extra bonus of the hacking exercise, doesn’t it?

One might think that positioning crypto on S1-MME and S6a interfaces would be good enough to provide signaling plane protection on those interfaces. Is it really? IPsec is the right approach to deploy for transport security. One of the interesting side-effects of IPsec is that it ensures everything is sent securely, including malware, signaling storms and other “interesting” things.

Sure enough, 5G’s hope is to deploy SDN- and NFV-based technologies, where MNOs will be striving to reduce their CAPEX. Using the example of signaling storms, we need to question how easy will it be for MNOs to achieve that goal if proper security measurements are not implemented. Taking control of IoT, connected cars, compromised e-health and compromised infrastructures will result in zero connectivity to the “hyper-connected” world.

Stay tuned for more! In the next blog, I’ll address preventive measures for hyper-connected 5G world to remain connected. For more imformation, download the white paper, The Need for a Network-Based Platform Approach in Mobile Networks.



  • 0

Accelerating Security Innovation: Introducing the Palo Alto Networks Application Framework

Category : Palo Alto

At Palo Alto Networks, we strive to provide the most compelling security to our customers, delivered with the utmost consistency across the network, endpoint and cloud. We are trusted by more than 39,500 customers to protect their organizations, prevent cyberattacks, and help maintain trust in the digital age. Our decade-long journey was founded on two words: innovation and disruption. The time has come to once again help change the future of the security industry, but this time we aren’t forging the way by ourselves – we are building on everything we have done and dramatically changing the consumption model for the most comprehensive security achievable. It is time to unleash security innovation, entrepreneurship and better protection for our customers.

The Palo Alto Networks Application Framework, announced today at our Ignite 2017 conference in Vancouver, reinvents how our customers rapidly adopt the most compelling new security technologies, consumed via cloud-based apps developed by any provider, large or small.

The framework is built on top of the Palo Alto Networks Next-Generation Security Platform, allowing our customers to access, evaluate and adopt the most compelling new security technology, as an extension of the infrastructure they already own and operate. These apps can be built by us, by third-party partners, by MSSPs and by customers directly to solve any use case imaginable.


It’s time to elevate this discussion beyond the level of individual products and vendors. Now, customers can embrace the technology they need to keep up with the ever-changing threat landscape, not make security decisions based on the typically large upfront ROI risk and cost of deploying and managing new hardware. It is not reasonable to ask security teams to differentiate workflows and derive actionable next steps from a mountain of threat intelligence, throwing manpower and new products at the challenges, only to find the next day that the threats and specific resource needs have once again shifted.

The answer is to drive a level of innovation that is at least as speedy, flexible and adaptive as attackers themselves. Our journey here is beginning, but we can’t do this alone. Delivering on this promise takes an entire community of developers and entrepreneurs to solve the most challenging security use cases facing our customers today.

Meet Our Community: 


As of today, more than 30 security industry vendors have committed to developing applications for the Palo Alto Networks Application Framework, including the following:

Aruba, a Hewlett Packard Enterprise company
Attivo Networks
Booz Allen Hamilton
Carbon Black
FourV Systems
Recorded Future
Sift Security

Become an Application Developer for Palo Alto Networks Application Framework

Today we also announced the formation of a $20 million security venture fund. The fund will provide early stage capital investments to fuel development of innovative security applications. The fund expects to collaborate with Greylock Partners and Sequoia Capital to identify and evaluate innovative security applications for potential co-investment. Prospective developers can sign up for review by our Corporate Development team and VC partners here.


  • 0

Moving to the cloud…Now what?

Category : Palo Alto

A cloud-first strategy begins an elaborate and sometimes difficult series of business and technology decisions – which can be more work than it should be.

Plus, cloud adoption creates potential security, legal, and financial risks, and changes the roles and responsibilities of the stakeholders who manage those risks.

Get on the right start to your cloud journey with this white paper from Cloud Security Alliance.

This white paper offers guidance to:

  • Build a framework to identify and engage the right stakeholders at the right time.
  • Establish a systematic and repeatable process for implementing a cloud-first strategy.
  • Ensure your cloud program is secure, compliant and effective.



  • 0

Traps Advanced Endpoint Protection Technology Overview

Category : Palo Alto

Most organizations deploy a number of security products to protect their endpoints, including one or more traditional antivirus solutions. Nevertheless, cyber breaches continue to increase in frequency, variety and sophistication.

Faced with the rapidly changing threat landscape, current endpoint security solutions and antivirus can no longer prevent security breaches on the endpoint.

Palo Alto Networks® Traps™ advanced endpoint protection replaces traditional antivirus with a unique combination of the most effective, purpose-built, malware and exploit prevention methods that pre-emptively block known and unknown threats from compromising a system.

TRAPS Product Summary Specsheet

  • 0

Practice Makes Perfect: Nemucod Evolves Delivery and Obfuscation Techniques to Harvest Credentials

Category : Palo Alto

Recently the Unit 42 research team have been investigating a wave of Nemucod downloader malware that uses weaponized documents to deploy encoded, and heavily obfuscated JavaScript, ultimately leading to further payloads being delivered to the victim. From a single instance of the encoded JavaScript discovered in one version of this malware, we pivoted on the Command and Control (C2) IPv4 address discovered during static analysis and deobfuscation, using our Threat Intelligence Service AutoFocus, unearthed many more versions of the malware and found that the versions seen to date were delivering a credential-stealing Trojan as the final payload.

In our recently published Unit 42 white paper Credential-Based Attacks we describe the importance of credentials to attackers, how they are stolen using techniques including malspam phishing as per this Nemucod campaign that delivers a credential stealing Trojan, as well as how the stolen credentials are used by the attackers to masquerade as legitimate users.

Over the past five months we have tracked this campaign of Nemucod malware in various industry sectors across multiple countries with Europe amassing the highest number of attacks, followed by the United States of America and then Japan (as can be seen in Figure 1).


Figure 1: Nemucod Destination Countries by session volume.


Figure 2: Target Industries by session volume.

Spain was the single most affected country, as shown in Figure 1, with the Professional and Legal Services sector, as shown in Figure 2, contributing the most towards that and also towards Belgium’s total volume as well. Utilities was next, almost exclusively in France; Healthcare was primarily made up again from volume seen in Spain; Energy, towards the end of the list of Top 10 industries shown in Figure 3, was mostly due to activity in the United Kingdom; the Securities and Investments sector was mostly made up from traffic in the United States of America, United Kingdom and Norway. Malicious traffic seen in Japan was due to attacks seen in High Tech industries.


Figure 3: European Countries by session volume.

Much of the malware arrived by email (using SMTP, POP3 and IMAP applications) as shown in Figure 4, the vast majority of which originated from Poland or at least using source email addresses with Polish domain names. Recipient email addresses varied but many seem valid based on names and linked-in account details. A small proportion of the sessions seen were over the web-browsing application being downloaded from websites resolving to IP addresses in Moldova, which will be discussed in more detail later.


Figure 4: Nemucod network application by session volume

The remainder of this blog describes the evolution of the malware since that time, as well as other topics:

  • Weaponized document evolution.
  • Insight into the possible workflow and setup of the attackers, including their infrastructure.
  • Obfuscation and social engineering techniques used.
  • The credential theft payload.

Technical Analysis

Dropper Evolution

Apart from a brief period of time in January 2017, when the actors delivered the encoded JScript content via Delphi-compiled dropper executable files, we have primarily observed only weaponized documents using Microsoft Office Macros using Visual Basic for Applications (VBA) code to install Nemucod. It’s hard to know why the attackers changed briefly from using weaponized documents to using executable files and then switched back again, especially considering the volume of documents carrying malware nowadays. Perhaps they were testing their own or their targets’ capabilities.

In total Unit 42 has seen over 50 versions of these weaponized documents spanning from late October through to March. We’ve used these to lay out a timeline, which will be referenced throughout the remainder of this blog, of the milestones of evolution that provides some insight into why the changes are made. Note: This figure does not cover all versions seen but simply milestone changes. It does however start with the first version created on October 23rd, last saved 25th October and first seen by our Wildfire cloud sandbox 26th October.


Figure 5: Timeline showing evolution of Nemucod weaponized documents.

Common throughout all versions of the weaponized document droppers is password-protected VBA code, as shown in Figure 6 below. The attackers use this to hinder researcher analysis and perhaps to give the document more legitimacy for those people, or security solutions, looking at such properties.


Figure 6: Password-protected VBA editor to protect code

Also common to all versions is the use of a heavily obfuscated JScript payload, an excerpt of which is shown in Figure 7. The obfuscation makes use of variable names that are seemingly randomly generated, extensive use of Unicode character encoding (e.g. \u00xx) where xx is the ASCII character code representation, and the use of generally unnecessary arithmetic to piece together sub-strings or select characters from strings. Such obfuscation is primarily to avoid signature-based detection technologies but has little to no effect on dynamic analysis sandbox systems, such as Wildfire. It does however cause some headaches and delays during manual analysis.

Figure 7: Obfuscated JScript code

In one of the earlier versions, towards the end of October and as shown by the fourth item in the Figure 5 timeline, an extra ASCII cipher obfuscation layer (excerpt in Figure 8) was added together with accompanying VBA code (Figure 9) to de-obfuscate said layer. This cipher obfuscation indicates the actors yearn to avoid detection.

Figure 8: Extra layer of obfuscated JScript code

Figure 9: VBA de-obfuscation code for extra layer of JScript obfuscation

It took a while for the actors to update any obfuscation techniques for the JScript code but around the middle of December, versions started to make use of Microsoft Script Encoding replacing their custom ASCII cipher perhaps for simplicity or bugs they themselves were finding difficult to debug.

Such encoded content often resides in files with a .JSE extension but it’s prudent to confirm by checking the magic bytes “#@~^” are present at the start of the file, an example of which is shown below:

Figure 10: Use of Microsoft’s Script Encoding to further obfuscate the JScript code

Don’t judge a document by its cover

It’s often interesting to extract document meta-data and other information from such weaponized documents in case it provides insight into the investigation. Of course, much of this data could be forged (as other researchers have shown) or simply nonsensical. In this case, there’s plenty of interesting variable data and information that make some conclusions quite plausible.

Looking at the charts below it’s clear to see patterns emerging in how the threat actors’ development of malware used in the campaign has evolved and how it’s analogous to a software development team working on a new project, tweaking code over time with some versions being major releases and others being minor.

Plotting the number of revisions made to each of the weaponized documents, as shown in Figure 11, and overlaying the number of words in each document’s body, highlights some patterns beginning to emerge.


Figure 11: Chart plotting number of revisions (right-axis) to each document and the number of words contained (left-axis).

The properties of the weaponized document of the initial version from late October indicates a large number of revisions – the highest with 192 – compared to all other versions since, which makes sense if it is indeed the actor’s first version indicating the authoring effort was significant with many modifications made. Again, this is analogous to a software developer’s first version of a piece of software.

Most of the versions avoided using anything but default VBA project property details, such as Project Names and Project Descriptions, however initially I didn’t think this would be the case having analysed the first version. Figure 12 below shows the custom Project Description used in this version.


Figure 12: VBA project description used in the first version.

If you don’t recognise this quote, Figure 13 below should provide some more context.


Figure 13: Breaking Bad season one, episode seven.

The quote used as the project description in the first version was a word for word copy from a scene in episode seven, season one of the American crime drama television series Breaking Bad. Warning – spoiler alert. I find it very fitting the threat actors should include this reference in their malware because, just as with the plot of the television series where a character was not always a criminal but turned to such a lifestyle to support his family, the person or persons behind this malware campaign must have switched at some point from law abiding to being cyber criminals.

Other document versions, much like the first with its 192 revisions as previously mentioned, also have an above-average number of revisions that tie to significant updates and feature releases in the malware’s evolution akin to a major software release. I will discuss these in more detail shortly but before moving on it’s worth highlighting the significance of the flat-line (zero) for the number of words included in these document versions that suddenly jumps up to over 6,000 words on the 30th November 2016 and that continues to trend upwards eventually ending with some of the most recent versions having over three times the number of words. Over this time period, as the number of words in each document increased, during this time the obfuscation techniques remained fairly stagnant indicating that the amount of code was increasing as more capabilities were added over time.

In addition to the number of words and edit revisions of these weaponized documents, comparing the time spent editing them compounds the aforementioned patterns in the evolution. Figure 14 shows a couple of interesting points to note. Firstly, that the initial version took the most amount of editing thus far – over 2 days – and secondly, that the next highest amount of time spent was on the November 30th coinciding with the aforementioned spike in number of words from zero to over 6,000.


Figure 14: Chart plotting amount of editing time for each version.

November 30th was certainly a significant shift in the techniques used by the actors and, investigating further, the change made by the actors between the two dates was to move the encoded JScript code from being statically held within the VBA code to being stored in the Word document itself.

How much VBA is too much?

Pre-November 30th all versions seen had the obfuscated (but not yet encoded at this point) JScript code stored in the malicious VBA code within Word’s AutoOpen macro, such that the code will execute automatically when the document is opened by the victim. The excerpt in Figure 15 provides a glimpse of said code but is truncated by many 100s of lines. Highlighted in bold is the code to add chunks of the obfuscated JScript code into an array object that will later be enumerated, processed and reassembled for writing to disk as a single .JSE file for execution by the Microsoft Windows Script Host executable (wscript.exe). The VBA code is overcomplicated with various function and object names being broken up unnecessarily and stitched together at run-time to be syntactically correct, another effort to hinder human analysis.

Figure 15: Obfuscated JScript code stored in VBA code

Since the von November 30th the VBA code has been replaced by less than 10 lines of code, as in Figure 16, that simply reads the text contents of the word document and writes it to the .JSE file. Over time the obfuscation of this smaller VBA code changed slightly to make string and signature-based detection difficult by over-complicated code syntax and by strings, such as filenames, being split and joined at run-time.


Figure 16: VBA code to retrieve obfuscated JScript code stored in document body

As can be seen in the code in Figure 16, the .JSE file will be written to disk in the same folder where the document resides and with the same filename as the document but having the .JSE extension. For a file named foobar.doc located on the desktop a file foobar.doc.jse will appear on the desktop.

The VBA code ActiveDocument.Content.Text is responsible for retrieving the obfuscated JScript content from the Word document, which in the case of one version highlighted in Figure 17, is 24 pages long but as you can see in the same figure, the document looks blank. Selecting-all in the 24 pages reveals more and changing the font colour to something other than white reveals the malicious code, as shown in Figure 18.


Figure 17: Post November 30th version showing 24 pages of blank content.


Figure 18: Revealing the hidden malicious code.

There could be numerous reasons for this change of moving the JSE code from within VBA to the document text, one of which could be simplicity for the actors, as per their shift from using their custom cipher code for obfuscation to Microsoft’s Script Encoder, which gave them less code to maintain. Another could be to throw off antivirus scanners and tools that use heuristics to evaluate the suspiciousness of files for which a 24-page document with content and a small amount of VBA code might look less suspicious than a 1-page, no-content document with 100s of lines of VBA code.

It could also be a social engineering technique as victims may be inclined to click on the “Enable Content” button if they believe the document has content but cannot see it. Of course, clicking this button would instead result in the VBA code being executed.

Practice makes perfect

Continuing along the Figure 5 timeline into December, around the middle of the month a version appeared that made use of the Security Permissions in Office applications to prevent unauthorised changes, such as marking areas of the document read-only, which also prohibits changing the font colour of the document text. However, such document permissions don’t stretch to Data Loss Prevention (DLP) capabilities so it’s possible to select the document text content and copy & paste into another application to retrieve the malicious code. Figure 19 shows the difference in document properties between versions pre (left) and post (right) permission changes that occurred on the December 18th version. Only a couple of the 20+ versions after December 18th were missing these permissions with no obvious evidence (e.g. new author, major code release, day of the week etc) to explain why but given the consistency with the others using permission it’s possible a human error occurred or the actor’s release process failed to check whether permissions were set.


Figure 19: Word document permissions missing (left) in earlier versions and present in most later versions (right)

In the week between Christmas and New Year – you know, that time where you’ve eaten too much, perhaps drunk too much and work, and the world in general, tends to be in go-slow mode – you would be an attacker’s perfect recipient of some unwanted phishing emails to take advantage of your stupor. On Wednesday December 28th a new version was created that boosted the social engineering capabilities of this malware.

Figure 20 shows the addition of a fake message claiming that the document was edited in a later version of Word and to view it, the recipient should click “Enable Content”. The festive period aside, it’s likely the actors were trying to stimulate the growth of their victim base with such tactics.


Figure 20: Social engineering used to entice victims to run their malicious macro code.

Since the beginning of 2017 we have seen a few versions including VBA GUI Form elements, as shown in the Figure 21. Currently the form, elements and skeleton code behind the scenes do nothing so one can only presume this is yet another measure to create a sense of legitimacy and perhaps throw some antivirus solutions off the scent by making the macro code seem quite benign. The use of GUIs is quite uncommon in malware as actors often don’t want to interact with victims and raise suspicion, unless to ask for ransom payments but there’s no indication of such payloads being used with these downloaders yet, nor any sense of these forms looking anything like typical ransomware ransom messages.


Figure 21: VBA Forms including GUI elements in some recent versions.

About one week after the first version to include VBA Form GUI elements another version emerged this time showing, albeit it in a faded grey colour, the encoded JScript code within the document text, as shown in Figure 22. Perhaps this is another lure technique to have victims click “Enable Content” believing the text may be ‘enabled’ and turn to the default black colour or look less like garbled text.


Figure 22: Grey, faded font properties used

Approaching the end of the current Figure 5 attack timeline now, some new versions seen around mid-January included a VBA code change to use Word’s AutoClose macro function instead of AutoOpen as used in all previous versions. The technical effect of this change should be quite obvious but the effect from a social engineering perspective and one of delaying or avoiding raising suspicion to the victim might be less obvious.

Quite often when weaponized documents like these are opened or enabled (“Enable Content” has been clicked) the effect is immediate – CPU spikes, ransom messages appear, network connections are made and so on. It may not be obvious that something untoward is happening but often hard drive noises, CPU fans or other indicators tell you otherwise. In this case however, the user could open the document safely, even click the “Enable Content” button and still remain safe and if no tell-tale signs of infection occur one might think all is well. Closing the document, or the Word application itself, however would trigger the infection routine by which point you may have felt a sense of relief nothing had happened. Short lived.

Some other points listed in the Figure 5 timeline worth discussing include the Operating System version, Code page and the Authors. Throughout the evolution of all the weaponized document versions all but two, according to their meta-data, were created using Word on a Windows 5.1 (XP) operating system; Windows 6.1 (Windows 7) was used for the two outliers. Incidentally, the two versions created on Windows 7 introduced two new Authors as well.

Author “Till3” appeared approximately one month after the first version and created their version on the 25th November, made 3 revisions to the content and last saved the document some 13 minutes after creating it. This version was one of the last of the “original” types where the JSE code was stored statically in the VBA code.

Author “Nish” appeared several versions later, around 14th December, making hardly any revisions and spending almost no time editing the document but doing so also on a Windows 7 host.

As for the rest of the authors, and their Windows XP systems, Figure 23 shows that most of the versions – over half – were created by authors with no names while Victor created almost a quarter and the rest were split in similar small numbers between John, Mike, Martin and two previously mentioned, Till3 and Nish.

Interestingly, it seems Victor played a much larger role in the final saves, and possibly edits, of over three quarters of all versions perhaps indicating him as a more senior member of the group or a team leader of sorts.


Figure 23: Author names (left), last saved names (right).

All versions of the weaponized documents gathered thus far share the same Code Page, 1251, which is designed to cover languages that use Cyrillic script, such as Russian, Bulgarian, Serbian Cyrillic and some other similar languages.

As shown in Figure 24 below, December was the busiest month for the actors who released close to 30 versions – almost one a day. It’s hard to know why the change in rates over the different months other than to say that clearly lots of churn was happening to various aspects of their malware and delivery mechanisms, which may have led to slightly higher numbers earlier on. As previously mentioned, and as described in our recent blog providing a glimpse into how the OilRig actors develop and test their malware in an attempt to remain undetected and to carry out multiple attacks without having to completely retool, these threat actors have shown during this Nemucod campaign their quite rapid development process that added features, ensured minimal detection rates by using obfuscation and other methods, and their enhancements in social engineering techniques to lure new victims.


Figure 24: Number of versions per month

The JSE Payload

Assuming the weaponized document’s macro code has executed the encoded, heavily obfuscated JScript code will be saved to disk and executed. One of the first behaviours observed is that of a fake error message box, such as the example in Figure 25. Message text varies but follows a theme of reporting something seemingly legitimate failed to run – another false sense of security for the victim.


Figure 25: Fake error message opened as part of the JSE execution

The vast majority of versions copy the JSE file to the Windows Startup Folder, as shown below, to ensure the code runs with every system reboot.

The JSE code uses various obfuscation routines and techniques to hinder analysis, including the use of Unicode characters in place of the ASCII character equivalent when declaring some variable names and for some strings. Converting these characters back to ASCII as part of the de-obfuscation process reveals some content that provides useful entry points for further analysis, an example of which includes the variable name “\u0075\u0072\u006c\u0031\u0032”, which translates in ASCII to “url12”.

In one version this variable is initialized with the following code, which decodes at run-time to the following URL string ‘https://185.159.82[.]11:3333/P/tipster.php?’.

Additional parameters, as shown in the example below, are later concatenated to this URL to form the HTTP GET request that would be used when connecting to the actor’s infrastructure to register new victims via unique user ids (uid below) as well as provide additional information about the client, including which version of the malware that infected the victim’s system allowing the actors to know how many victims are running particular versions of the malware. Using a version identifier in communication code is another behaviour of this malware analogous to a software developer wanting feedback or telemetry about their application being run in the wild.

  • add=3ef295d92702b904d009ba73e42a69c2
  • uid=1442894259
  • out=0
  • ver=20

The JSE code continues by enumerating all running processing and checks for matches against the following list of applications and quits if they are found. Clearly the malware does not want to be analysed. The “Johnson-PC” item below perhaps relates to well-known sandboxes that may use such names for their analysis machines, which the malware is keen to avoid running in.


The malware then runs a hidden command shell issuing commands, as shown below, to get a list of files and their full paths where said file extensions match the list described below. The list is redirected to a text file named, in at least one of the versions, as ‘pollos.txt’ – another reference to Breaking Bad.

During communication with the remote host IP mentioned above, the JSE may download another Portable Executable (PE), the payload of which could differ. In this version’s case, and on this occasion, a Base64-encoded, UPX-packed PE file (SHA256:76b703c9430abf4e0ba09e6d4e4d6cf94a251bb0e7f3fadbd169fcef954a8b39) was downloaded and responsible for injecting another PE component (SHA256:53edea186162d84803f8ff72fb83c85f427b3813c32bd9d9d899e74ae283368e) into memory to carry out the credential harvesting and exfiltration duties discussed next. It’s possible the actors could switch this malware out to another depending on their objectives and motivations. The Polish CERT team posted a blog earlier this year describing related malware that ultimately resulted in ransomware however during our research we have not seen such behaviour.

Credential Harvesting

Analysing one of the payload files installed by Nemucod in more detail shows the extent of credential stealing capabilities. The payload enumerates various Operating System and application credential stores in order to harvest as many credentials as possible.

Protected Storage (Pstore)

After determining the running Operation System is a legacy version, such as Windows XP, the malware starts by attempting to load the pstorec.dll library, to access the legacy Windows data store, Pstore. If successful a call to the PStoreCreateInstance function to get the pointer to protected storage will be made to allow calls to functions that enumerate and retrieve any stored credentials, as shown in Figure 26 below.


Figure 26: Payload code to gain access to legacy Windows Pstore.

Credential Cache

The malware then checks the credential cache, which is used in later versions of Windows, and allows all built-in applications in Windows Internet Explorer to store and use credentials automatically. Credentials using HTTP’s basic authentication passwords can be stored here as well as network login passwords. The malware searches specifically for the latter by filtering for passwords starting “Microsoft_WinInet_*” to attain only credentials stored by Internet Explorer, as shown in Figure 27 below:


Figure 27: Payload code accessing Internet Explorer stored credentials

The 128-bit value Globally Unique Identifier (GUID) ‘abe2869f-9b47-4cd9-a358-c22904dba7f7’ shown in Figure 27 is used in conjunction with the built-in Windows Cryptography functions to encrypt and, in the malware’s case, decrypt the stored credentials attained.

Windows Vault

Before moving on to harvesting data from browsers and other applications the actors check one final credential store – Microsoft’s ‘Windows Vault’, which is part of built-in Credential Manager. Providing the victim’s Operation System is 6.2 (Windows 8 or Windows Server 2012) the malware loads the Vault Client Access Library (vaultcli.dll) and uses it to access stored credentials.


The actors then shift their attention to web-browsers including Firefox, Chrome and Opera (Internet Explorer has been covered by the previous steps already). The malware enumerates various Windows Registry keys gathering installation folder paths for these browsers before attempting to harvests credentials stored by them.

Using Chrome as an example, the malware locates the sqlite database files created and used by the browser to store various pieces of information. One of the sqlite files the actors target is named “Web Data” and includes autofill information for auto-populating HTML forms for logins, postal addresses and so on. The sqlite command ‘.tables’ lists the table names as shown below:

Looking at the data held in my test system’s ‘autofill’ table, in the ‘Web Data’ database, you can see details related to a previous HTML form completion using a fictitious first and last name and cell phone number.

Another database accessed by the malware is named ‘Login Data’ that includes a table ‘logins’ containing information such as the example below showing a login to Google’s accounts service to access mail, calendars and more.

Email Clients

The next focus is on harvest credentials from email clients installed on the victim’s system, starting with Outlook and Outlook Express. The malware checks the registry key ‘HKEY_CURRENT_USER\Software\Microsoft\Internet Account Manager\Accounts’ for data relating to such installed clients or Windows address books, and enumerates all of the ‘Server’, ‘User’ and ‘Password’ values for SMTP, POP3 and IMAP protocol types, as shown in the Figure 28 below, and gathers the respective data.


Figure 28: Windows registry storing some email client account credentials

The malware continues to check for other installed mail clients, including Mozilla’s Thunderbird, RITLabs’ TheBat!, Windows Mail and Windows Live Mail, to harvest yet more credentials.

The mail client TheBat! written by software company RITLabs happens to be based in Chisinau in the Republic of Moldova. This is interesting as some of the infrastructure used by the threat actors, which I discuss in more detail later, is located in or registered to places in the same country.

Finally, the malware checks for various software applications that communicate over SSH (Secure Shell), FTP (File Transfer Protocol) and HTTP protocols often used to remotely connect and administer systems or to transfer files between systems. The goal here is to harvest any stored credentials as well as system hostnames and IP addresses. Credentials stored in these types of applications would be very useful for attackers who wish to move through the compromised network for further reconnaissance or performing other attack objectives.

The applications in question include WinSCP (Windows Secure Copy) used for copying files over SSH and Total Commander (Ghilser), FileZilla, FlashFXP, Cyberduck, CoffeeCup Software, CuteFTP and SmartFTP all of which include FTP capabilities.


Any credentials found by the malware will be stored in a text file in the victim’s temporary folder in preparation for exfiltration. In this version’s case the file was named as follows:


The format of this text file is as shown below and contains the unique identifier (uid) that was used earlier during the registration process, together with the date and time, allowing for the actors to sift their data accordingly, before the list of any credentials harvested during execution describing the protocols and ports required, usernames, passwords and hostnames.



The final phase for this malware is to offload all the information harvested to the actors by communicating using a HTTP POST request under the pretence of a Windows 7 Operating System and FireFox browser by setting the HTTP HEADER’s User-A­gent field to the following string:

Mozilla/5.0 (Windows NT 6.1; rv:45.0)

The malware makes calls to the InternetOpenA, InternetConnectA and HttpOpenRequest functions from the Wininet.dll library to prepare the HTTP POST request to the following URL where the contents of goga.txt will be sent.



WHOIS reports the following for the IP address used in this version of the malware to both register the victim system infection and to exfiltrate the stolen credentials:

  • The IP belongs to a Russian-owned hosting service, King Servers
  • The IP resolves to domain

Investigating IP and hostname information for all the samples gathered in this research shows a much wider infrastructure, described in more detail below, however, remaining focussed on the single IP discussed throughout this blog and, as shown in Figure 29 below, there are malware samples (the red circles) including weaponized documents (red circles) and PE file samples (red circles with blue bookmark) as well as domain names (blue circles) associated with the domain name resolved from said IP –

The vast majority of the samples in figure 29 were first seen in AutoFocus between January and March in 2017 except for two that were seen in late December 2016. The IP address resolved to the hostname customer.clientshostname[.]com depicted by the orange circle in the center of the figure; the blue circles attached represent sub-domains of clientshostname[.]com that mostly appear to use a ‘firstlast’ name convention, such as ‘joebloggs’. Some of these sub-domains have been linked, through reverse DNS, to IP address Indicators of Compromise (IOCs) listed in the Grizzly Steppe report. From the samples analysed it is not clear how these subdomains are being used.


Figure 29: Partial infrastructure

The following figure highlights another two IP addresses (185.130.104[.]156 and 185.130.104[.]178) that reside in the same class C network range together and within the same class B network range as the IP from the previous figure. All versions in this figure are weaponized documents except for one that is a PE executable credential stealer (depicted again by a red circle blue bookmark) and most reference IP 185.130.104[.]156 at the base and center of the semi-circle in the figure, and in the zoomed-in box. All but one of these samples were seen in AutoFocus in November 2016 with the outlier (arrow #1) seen in late December.

Interestingly, this IP address also had some associated domain names, as shown in the zoomed-in box as well, including letstrade-bit[.]com, lesbtc[.]com (and mail.lesbtc[.]com) and secure-trade24[.]com with the former two domains being registered December 20th and the latter on December 14th. All three domains mention trading or Bitcoins (BTC) but from the samples analysed, it is not clear how these subdomains are being used, however such terms are indicative of contemporary ransomware that requests ransom payments using BTC.

IP 185.130.104[.]178 (arrow #2) has three associated weaponized document versions all of which were seen in AutoFocus in the last week of February, which together with aforementioned IP addresses, indicates how different waves of this campaign occur over different months and how the actors switch to using different IP addresses within the infrastructure for their C2 communication.


Figure 30: Partial infrastructure

Following along that theme of the actors’ versions using different C2 communication hosts, the following figure shows yet more groups of versions using other IP addresses for their C2. The two IPs below once again share the same class C network range as each other with one IP (217.28.218[.]231) being used for only one version (arrow #1), which happens to be the first seen in AutoFocus on October 26th (the one with the Breaking Bad references) while the other IP (217.28.218[.]210) hosts twelve known versions’ C2 communications, three of which are PE executable credential stealers; the remainder are weaponized documents.


Figure 31: Partial infrastructure, including first version from October 26th.

Two weaponized document versions, shown in Figure 32 below were seen on the 19th and 30th of December in AutoFocus. These versions were a little different from the majority that were emailed to their victims as these were downloaded over the web-browsing application (HTTP) from the website[.]uk. The victim organisations belonged to the Telecommunications and Healthcare sectors in the United Kingdom.


Figure 32: Partial infrastructure showing argos-tracking domain name.

The Second Level Domain (SLD) is intended for UK-based businesses and, when combined with the words argos and tracking, would resonate with many UK citizens as possibly being related to the UK-based retailer business Argos, which has an online retail presence including a parcel tracking service. Given this information, and the UK targets seen using AutoFocus, it’s clear the threat actors were trying to deceive and socially engineer UK victims.

According to the WHOIS records the[.]uk domain registrant, a Mr Milosh Zotich from Belgrade, Serbia registered this now-suspended domain on the 15th December 2016 – just 4 days before AutoFocus saw use of the domain – and provided the domain names parking-1.domains4bitcoins[.]com and parking-2.domains4bitcoins[.]com as nameservers. Domains4bitcoins needs little introduction but just in case you weren’t aware, such services are used for domain registration and hosting services in an anonymous fashion through the use of a digital crypto currency. These nameservers were updated on December 20th to various nameservers at ClouDNS, a site offering free DNS hosting and domain names.

The most recent change to the[.]uk domain was on the 22nd February 2017 to suspend it. This example highlights the lengths the actors will go to in their reconnaissance of their victims in order to increase their changes of successful compromise.


Nemucod malware is mostly deployed using weaponized documents where the malicious VBA macro code is responsible for constructing and executing a malicious encoded JScript file that carries out further activities including registering victims with the actors before downloading payloads, which in this case included a credential stealing Trojan executable component.

Though the encoded JScript content was dropped by executable files attached to emails in malspam campaigns it was a much less common technique compared to weaponized documents dropping the content, most likely due to a reduced infection success rate because of the additional suspiciousness executable files on email pose.

This particular Nemucod campaign was seen by Unit 42 and AutoFocus running from late October through to late March 2017 impacting various countries, especially within Europe, and across various industries.

Given the details discussed in this blog, such as the[.]uk domain registration information; the location of the IP addresses and that many belong to a Russian-owned hosting service, King Servers; and the weaponized document code page and language settings it’s highly likely this malware, the attack campaigns and the threat actors originate from Eastern European countries.

Much like the evolutionary changes to the delivery documents, obfuscation techniques and social engineering methods used in this campaign, other malspam campaigns recently have highlighted the pace of development and changes within a single campaign to collect more victims or remain undetected for longer, as described in another Unit 42 blog.

Palo Alto Networks customers are protected by these threats in the following ways:

  • All samples discussed are classified as malicious by the WildFire sandbox platform.
  • All identified domains have been classified as malicious.
  • AutoFocus users can track the malware described in this report using the Nemucod tags.
  • Customers running Traps are protected by preventing Nemucod from executing.

When executing any of the weaponized documents on a Traps-protected end-point one of the default restrictions will be triggered protecting the system due to the suspicious execution of a child processes. In this case Winword.exe (Word’s process) tries to execute wscript.exe (Windows Scripting Host’s process). Given these weaponized documents often arrive through email a more real-world scenario would include a larger process tree of Outlook (or equivalent email application) executing Word in turn executing the Windows Scripting Host. Figure 33 below shows a typical Traps Prevention Alert for such activity.


Figure 33: Traps Advanced End-point preventing the malware infection via child process restrictions.

Figure 34 below shows in more detail, through the Enterprise Service Manager (ESM) the host affected, the restriction that triggered (1), the host system and the processes involved (2) as well as their hashes, versions, digital signatures, if any, and any related files or URLs. In this case the JSE file that was attempting to run in the context of the Windows Scripting Host process is listed (3).


Figure 34: Traps Enterprise Service Manager (ESM) detailing the restriction and blocked malware.

Appendix A: Indicators of Compromise

Email Attachment Names:

Microsoft Office Word Document.doc



















Email Subjects:

Your Eguipment

AW:Your order was completed











Re:Waiting for payment

AW:Waiting for payment


Re:Your order was completed






Get Carried Away at The Peninsula

Discover The Revolutionary Trick To Restore Your Memory!

RE: Rechnung



AWd: Rechnung

RE: billing terms

RE: We are waiting for your payment.

RE: payment








AW: Rechnung

PE Dropper Hashes






Document Dropper Hashes


























































PE Password Stealer Hashes




  • 0

GDPR/NIS Countdown: How Ready Are Organisations to Get Their Cybersecurity in Order for the Next Decade?

Category : Palo Alto

This month marks the start of the 12-month countdown for organisations to be ready to comply with either – or in some cases both – the General Data Protection Regulations or the NIS Directive becoming law in Europe on the 25th and 10th of May 2018, respectively.

Whether you have started working towards compliance in the last year or not, the deadline to be ready for these new laws is fast approaching, and the pressure to review, change and test new cybersecurity systems increasing.

So, what’s the current state of mind of cybersecurity and business leaders as we count down? In research recently commissioned for Palo Alto Networks, we found that IT security professionals across Europe are generally optimistic about how these laws will help avoid personal data and cybersecurity breaches. However, there is still some hesitation when it comes to how easy the change will be. What is immediately clear is there are vast geographical differences when it comes to openness to new ideas; senior management in countries like Sweden are least likely (28 per cent) to accept suggested ideas for change from internal stakeholders, whereas Dutch respondents were far more willing to adopt new ways to best protect their organisation (39 per cent).

A fear of the unknown continues to present a significant roadblock over the next year, and not all businesses can see the benefit in change. Only a third of respondents think they will get the support to implement the necessary changes, while the majority still feel there will be obstacles to overcome.

With only one in ten respondents admitting that pressure to comply with new laws would make them open to ideas for change, there is a major shift in perception needed to ensure European businesses are ready come May 2018. Our research found that:

  • 43 per cent of IT security practitioners were concerned changes to legislation will unleash a wave of previously unknown personal data and cybersecurity breaches that need to be reported.
  • Half of all IT professionals (49 per cent) said they avoid security system changes or updates because they think their current system is already broadly secure.
  • 56 per cent of IT security professionals think the GDPR/NIS implementation will be a pain both financially and operationally.

With all that in mind, there are several ways businesses can prepare themselves today ahead of May 2018:

  • Gain visibility of what information is being used and through which applications. If you don’t have ongoing insight into how your business is already processing information through technology, then you can’t validate if this is appropriate and what controls must be wrapped around it.
  • Too much of cybersecurity is legacy technology – leverage the new regulations as an opportunity to clean your house, validate that everything is fit for a purpose, today and in the future, especially considering that cybersecurity will continue to evolve, and the biggest shortfall is skilled cybersecurity people. Consider how you apply and maintain an adaptive cybersecurity ecosystem that is automated to work at the same speed as the attacker.
  • Ensure that you have clear leading and lagging metrics to validate the effectiveness of your cybersecurity. Can you prove to your own business and others that you are effectively aligning current best practices to the risks?
  • Test your capabilities – not just the technology, but also the people and processes around these, including the broader businesses teams.
  • Cybersecurity leaders will need to validate that their cybersecurity capabilities are relevant to the risk they face and that they leverage current best practices, referred to as “state of the art”, with clearly documented processes and measures.

To learn more about how you can prepare your business for the upcoming new laws, please see the following Palo Alto Networks assets:

  • 0

Palo Alto Networks Protections Against WanaCrypt0r Ransomware Attacks

Category : Palo Alto

What Happened

On Friday, May 12, 2017, a series of broad attacks began that spread the latest version of the WanaCrypt0r ransomware. These attacks, also referred to as WannaCrypt or WannaCry, reportedly impacted systems of public and private organizations worldwide. Our Next-Generation Security Platform automatically created, delivered and enforced protections from this attack.

How the Attack Works

While the initial infection vector for WanaCrypt0r is unclear, it is certain that once inside the network, it attempts to spread to other hosts using the SMB protocol by exploiting the EternalBlue vulnerability (CVE-2017-0144) on Microsoft Windows systems. This vulnerability was publicly disclosed by the Shadow Brokers group in April 2017, and was addressed by Microsoft in March 2017 with MS17-010.

Microsoft published a post on protections from the WanaCrypt0r attacks here, and has taken the step of providing patches for versions of Windows software that are no longer supported, including Windows XP. Organizations that have applied the MS17-010 update are not at risk for the spread of WanaCrypt0r across the network, but given it addresses a remotely exploitable vulnerability in a networking component that is now under active attack, we strongly urge making deployment of this security update a priority.


Palo Alto Networks customers are protected through our Next-Generation Security Platform, which employs a prevention-based approach that automatically stops threats across the attack lifecycle. Palo Alto Networks customers are protected from WanaCrypt0r ransomware through multiple complementary prevention controls across our Next-Generation Security Platform, including:

  • WildFire classifies all known samples as malware, automatically blocking malicious content from being delivered to users.
  • Threat Prevention enforces IPS signatures for the vulnerability exploit (CVE-2017-0144 – MS17-010) used in this attack: SMB vulnerability – ETERNALBLUE.
  • URL Filtering monitors malicious URLs used and will enforce protections if needed.
  • DNS Sinkholing can be used to identify infected hosts on the network. For more, please reference our product documentation for best practices.
  • Traps prevents the execution of the WanaCrypt0r malware on endpoints.
  • AutoFocus tracks the attack for threat analytics and hunting via the WanaCrypt0r tag.
  • GlobalProtect extends WildFire and Threat Prevention protections to remote users and ensures consistent coverage across all locations.

For best practices on preventing ransomware with the Palo Alto Networks Next-Generation Security Platform, please refer to our Knowledge Base article. We strongly recommend that all Windows users ensure they have the latest patches made available by Microsoft installed, including versions of software that have reached end-of-life support.

Change Log:

On May 13, 2017, this post was updated to include:

  • Link to Microsoft blog on protections against WanaCrypt0r attacks
  • Details on additional protections via DNS sinkholing
  • Updated URL Filtering section to reflect new analysis

On May 15, 2017, this post was updated to clarify the WanaCrypt0r attack delivery method based on additional information.

  • 0

Introducing the New Traps v4.0: Advancing Endpoint Security – Again!

Category : Palo Alto

Today, we’re pleased to announce the release of Traps advanced endpoint protection version 4.0. With this release, Traps expands its multi-method prevention capabilities to secure macOS endpoints and Android devices as well as to cover several additional attack techniques.

In this post, I’ll go over some of the enhancements we’ve made to Traps and discuss how they help you to secure your endpoints against cyberattacks. For a deeper dive, I encourage you to download our Traps Technology Overview white paper or join us for a webinar to see how Traps protects your organization against the imminent shifts in endpoint attacks.

Expanded Multi-Method Approach to Prevention

Traps replaces traditional antivirus and secures endpoints with a multi-method approach to prevention. Using a unique combination of highly effective malware and exploit prevention methods, Traps blocks both known and unknown threats – before they can compromise a system.

“Signature-based endpoint security simply cannot provide effective protection against the new wave of cyberattacks targeting endpoints. Given the acute problem presented by the “Patient Zero Effect,” new approaches are a must. Built from the ground up to address modern endpoint security needs, Palo Alto Networks Traps provides modern endpoint protection that can be implemented as either an independent, standalone solution or as a part of an integrated security ecosystem with the accompanying integration synergies that their Next-Generation Security Platform can provide. Palo Alto Networks Traps commands consideration for organizations seeking modern endpoint threat prevention capabilities.”
– Frank Dickson, Research Director, Worldwide Security Products, IDC

Traps v4.0 includes several expanded capabilities and enhancements, which follow.

True Prevention for Mac

Traps secures macOS systems and replaces legacy AV with a multi-method approach to prevention. Traps blocks both malware and exploits, known or unknown, before they can compromise Apple Mac endpoints.

This is in contrast to existing signature-based AV and security solutions for macOS that claim to be “next-gen” but can’t (and don’t) prevent cyber breaches by blocking both malware and exploits, leaving the endpoint exposed to attacks.

Office Macro Protection

Traps blocks known and unknown malicious macros that are embedded in Word and Excel files, before the files are allowed to open. This prevents ransomware and other advanced threats that rely on macro-based attacks to bypass existing endpoint protections.

  • Traps uses our WildFire threat intelligence to instantly identify an Office file (with a malicious macro) that has been seen before by any of our 15,500 WildFire customers, our threat intelligence technology partners, or our own threat researchers in Unit 42.
  • If an Office file with a macro that is unknown to WildFire, Traps uses local analysis (via machine learning) to immediately determine whether the macro is malicious. We have used the threat intelligence available through WildFire to train a machine learning model to autonomously recognize malicious macros – especially unknown variants – with unmatched effectiveness and accuracy.
  • In addition to using local analysis to render a verdict for an Office file that contains an unknown macro, Traps can submit the file to WildFire for complete inspection and analysis. WildFire goes beyond legacy approaches used to detect unknown threats, bringing together the benefits of four independent techniques for high-fidelity and evasion-resistant discovery, including dynamic analysis, static analysis, machine learning and bare-metal analysis.

Enhanced Child Process Protection

Traps delivers fine-grained control over the launching of legitimate applications, such as script engines and command shells, that can be used for malicious activities. This prevents advanced threats and ransomware from launching evasive attacks that are not detected by existing endpoint security solutions.

For example, Traps can prevent Internet Explorer from launching a specific script interpretation engine as a child process – a common technique used by ransomware. For any given process, Traps enables customers to either block all child processes except those that are whitelisted or allow all child processes except those that are blacklisted.

Exploit Kit Fingerprinting Protection

Exploit kits typically profile a user’s system to identify potential vulnerabilities and deliver the optimum attack that can predictably compromise a system or increase the success rate of the attack. This technique is commonly referred to as “fingerprinting” a system. Traps prevents attackers from identifying and targeting vulnerable endpoints by blocking the fingerprinting attempts used by exploit kits. This, in effect, prevents an attack even before it begins.

Kernel Privilege Escalation Protection

Kernel exploits are some of the most advanced attacks. Often emanating from nation-state attackers and advanced persistent threats (APTs), kernel exploits target vulnerabilities in the operating system itself. A common kernel exploitation approach is to create a malicious process that leverages a kernel exploit to “steal” the credentials (“token”) of a privileged process, allowing the malicious process to run with system-level permissions. Traps identifies and blocks this technique.

Single-Pane-of-Glass Visibility Into Security Events

Traps 4.0 can share its logs and security events with Panorama, our network security management product. This integration enables security operations teams to analyze and correlate threat patterns using both network and Traps security events, which, in turn, delivers a unified picture of security events across the entire environment.

In conjunction with automated policies, the integration of Traps with Panorama enables our customers to eliminate attack surfaces across their entire environment, from endpoints to firewalls to cloud and SaaS applications.

Traps Protection for Android Devices (Beta)

Traps for Android is now available through a community access beta program that extends the multi-method protection of Traps to users of Android devices.

On an Android device, Traps instantly identifies known malware by checking the hash of every application with WildFire. Using local analysis, Traps instantly determines if an unknown application is malware, in addition to submitting that application to WildFire for full inspection and analysis. WildFire, in turn, analyzes the unknown application using a multi-technique approach and renders a verdict.

Traps also identifies unknown, but benign, applications through its Trusted Publisher Identification method. Traps notifies users about the verdict associated with each application and enables them to terminate, uninstall or continue to run each application.

For more on Traps for Android, and to participate in the community access beta program, please contact your Palo Alto Networks sales team.


To learn more about Traps v4.0 and its expanded capabilities:

  • 0

Mole Ransomware: How One Malicious Spam Campaign Quickly Increased Complexity and Changed Tactics

Category : Palo Alto

On April 11th 2017, we saw a new malicious spam campaign using United States Postal Service (USPS)-themed emails with links that redirected to fake Microsoft Word online sites. These fake Word sites asked victims to install malware disguised as a Microsoft Office plugin.

This campaign introduced a new ransomware called Mole, because names for any encrypted files by this ransomware end with .MOLE. Mole appears to be part of the CryptoMix family of ransomware since it shares many characteristics with the Revenge and CryptoShield variants of CryptoMix.

The campaign quickly changed tactics and increased complexity.

After two days on April 13, 2017, the attackers behind these fake office plugins changed the format and began including additional malware. Along with Mole ransomware, victims would be infected with both Kovter and Miuref. Then, on the following day, April 14, 2017, the attackers stopped using a redirect link in the malicious spam and instead linked directly to a fake Word online site. Figure 1 shows the attackers’ changing tactics from Tuesday April 11, 2017 through Friday April 14, 2017.


Figure 1: Changing tactics April 11 – April 14, 2017

April 11th – Introducing Mole Ransomware

From Tuesday April 11th to the early hours of Wednesday April 12th, the fake Word Online used Google Docs links to provide Mole ransomware disguised as an Office plugin. Criminals behind this campaign abused Google Docs to provide a link for an executable file. File names were plug-in.exe or plugin.exe. Figure 2 shows how these fake Microsoft Word Online documents would attempt to lure users into downloading the Mole ransomware.


Figure 2: Fake Microsoft Word Online site with link to a Google Documents URL with the ransomware.

After downloading the executable, the infection chain is straight-forward. The victim executes the ransomware and infects his or her Windows computer. The mechanics behind a Mole ransomware infection have already been covered at the Internet Storm Center (ISC) and Bleeping Computer. Figure 3 shows the April 12 Mole ransomware in action.


Figure 3: Desktop of a Windows host infected with Mole ransomware on April 12th

April 13th – Introducing .js Files and Additional Malware

By Thursday April 13, 2017, this campaign changed tactics. The fake Microsoft Word Online sites no longer used a Google Docs URL to provide their malware. Instead, the malware was sent as a zip archive directly from the compromised site being used as a fake Microsoft Word Online page. The zip archives contained JavaScript (.js) files designed to infect Windows computers with Mole ransomware and additional malware.

The Figures 4 and 5 below illustrate the newer format used for malware infections by this campaign, where the new file is a zip archive named that contains a .js-based downloader named plugin.js.


Figure 4: Fake Microsoft Word Online site later on April 13th with link to a zip archive instead of an executable


Figure 5: The zip archive contains a .js file

The plugin.js is a type of file downloader commonly called a Nemucod. This .js file downloads and installs three Windows executable files named exe1.exe, exe2.exe, and exe3.exe as shown below in Figure 6.


Figure 6: Plugin.js installing 3 items of malware as shown in a analysis

Network traffic generated by this infection is similar to Nemucod downloaders we have seen from other campaigns. In Figure 7 below, you can see URLs for exe1.exe, exe2.exe, and exe3.exe from


Figure 7: Traffic from an infection filtered in Wireshark

The three items of follow-up malware are named exe1.exe, exe2.exe, and exe3.exe. In the early days of this campaign, they have been Mole ransomware, Kovter, and Miuref, respectively.

The Emails


Figure 8: An example of the malicious spam from Thursday April 13th

Emails from this campaign follow the same format as originally reported from Tuesday April 11, 2017. Figure 8 above shows an example email. They have a variety of subject lines, spoofed sending email addresses, and message text. Through Thursday April 13, 2017, the URLs were different for each message. By Friday April 14th, these emails were linking directly to the fake Microsoft Word Online pages, so the URLs for that day were the same.


Most large-scale malicious spam campaigns tend to stick with operating patterns that are much easier to identify and track. This particular campaign has evolved more quickly than we usually see. Such changing tactics are likely a way to avoid detection.

And this campaign continues to evolve. By Tuesday April 18, 2017, it stopped distributing Mole ransomware, and it began pushing the KINS banking Trojan with Kovter and Miuref. By Friday April 21, 2017, this campaign moved from USPS-themed emails to messages about speeding tickets, and it began utilizing a fake parking services website.

Why did we stop seeing Mole ransomware? Because families of ransomware are constantly changing. CryptoMix variants like Mole rarely stay around for more than a few weeks before being repackaged and distributed as a new variant. The samples of Mole ransomware we have identified so far are tagged in AutoFocus using the MoleRansomware tag.