Category Archives: Uncategorized

  • 0

Circumventing Application Whitelisting and Misplaced Trust

Category : Uncategorized

Application whitelisting has been an advantageous technique to harden an organization’s endpoints against malware, unlicensed software, and other unknown or unauthorized software. When properly configured, whitelisting certainly has its benefits as it controls which applications and scripts can run and execute. However, traditional whitelisting technologies will limit the user to a binary ‘allow/deny’ mode. This approach may work just fine for smaller organizations that have only a handful of applications, but in large enterprises, this can be extremely challenging to support. The organization would need to either ‘allow the unknown’ and open themselves up to unnecessary risk – or – ‘deny the unknown’ and deal with disgruntled users and operational issues.

Attackers increasingly have sophisticated techniques. If an organization has something of significant value to attackers, then you can certainly expect that they’ll find ways to circumvent application whitelisting policies. Heuristic-based detection and scanning methods can help supplement a risk mitigation strategy against attacks initiated by these bypassing techniques – but – is that really enough to keep up with the very skilled and sophisticated cyber attackers that we see today? A defense in depth strategy at the endpoint with multiple layers of security controls is needed.

Misplaced Trust

When an organization leverages only the free and rudimentary tools for IT administrators to define which applications can and cannot be executed, they inadvertently become more susceptible to attacks that originate on the endpoint. Furthermore, trusting all the binaries that are signed off by the operating system comes with a certain level of risk. Over the years, researchers have come across many executable files that have the ability to very easily bypass some of these basic tools with relatively simple commands and run arbitrary scripts. Some of which were even able to fetch files and communicate over the internetnot good! These free tools can be a great foundational resource but additional security controls are needed to better improve an organization’s security posture.

Reality Meets Application Control

Expecting your IT administrator to be aware of all the applications that exist within a larger organization is unrealistic and nearly impossible in practice. Moreover, analyzing these applications and identifying which should be allowed to execute and which should be denied is equally as challenging. When an organization enables an application control solution, it often takes a whitelisting approach and therefore must specify exactly what is to be trusted. The most common tactic is to trust every binary that is signed off by the operating system vendor – but – not all processes (e.g. child processes) that originated from the trusted process are considered to be fully trustworthy. This is particularly important when you consider the techniques of modern malware that leverage tools like PowerShell to pull code (e.g. Mimikatz) from online source code repositories and execute in memory – thereby bypassing many Anti-Virus, malware detection or whitelisting solutions. Being limited to only ‘allowing’ or ‘denying’ within PowerShell is certainly not the ideal situation.

A more proactive approach is to provide application “greylisting” which allows lesser known applications to run in a restricted mode based on policy whereby they are allowed to run but are for example, denied access to the internet, unable to spawn processes and forced to run at a lower privilege. Operating in a restricted mode allows flexibility to the end user but prevents the applications from accessing corporate resources and system resources as part of a targeted attack.

CyberArk Provides Defense in Depth for Application Control

CyberArk Endpoint Privilege Manager delivers several layers of security beyond what some of the basic, UAC software restricting tools can provide and in so doing is aligned with guidance from NIST Special Publication 800-167, Guide to Application Whitelisting. With CyberArk Endpoint Privilege Manager, users can define whitelists and greylists with flexible rules based upon any combination of various file parameters and not just those based on the file hash, path or publisher (which can easily be sidestepped by a few simple actions). With Endpoint Privilege Manager, an IT organization can provide the level of granularity that allows for specific users on specific machines to run PowerShell, with a pre-defined level of privilege (e.g. standard user, specific privileges [i.e. custom token], etc.).

Additionally, Endpoint Privilege Manager also supports a full range of trusted sources, providing the ability to manage a very large number of the executables within larger-sized organizations (e.g. any file distributed by a corporate software distribution system like System Center Configuration Manager could be defined as a trusted source just by one simple rule). Lastly, this solution provides deep integrations with third-party file reputation systems to help IT administrators determine legitimate applications versus what’s considered to be potentially harmful. The image below shows Endpoint Privilege Manager blocking an unknown .vbs script from running on the endpoint, by using Bginfo.exe (a known executable file signed by the OS vendor that can bypass whitelisting) as the executable host:

Minimizing the endpoint attack surface is top of mind for all IT Security teams and taking a layered approach in securing your endpoints by coupling both privilege management and application control is an essential step in stopping common endpoint attack vectors that organizations often fall victim to.  Our CyberArk Labs Team has demonstrated that a combination of privilege management and application control is 100% effective in protecting against both ransomware and unknown malware.



  • 0

Armory Sandbox – Building a USB analyzer with USB armory

Category : Uncategorized

The USB armory is a small computer on a USB stick, providing an ARM A8 800 MHz CPU and 512MB RAM, and it’s versatile enough to implement all kinds of interesting scenarios. One of its most interesting features for this project is secure boot, called High Assurance Boot, that allows better integrity of our USB armory platform. Amusing enough, last week there was a security advisory regarding this feature. Assuming for now that no vulnerabilities exist in its secure boot, the USB armory is a very interesting platform to have a reasonable hardware integrity level because we can fuse our PKI keys into the secure boot and just replace the microSD card per analysis target. There aren’t a lot of vectors for targeted malware to achieve hardware persistency and make the device unusable from a forensics point of view (meaning a permanent rootkit that could taint our analysis forever). The device can be ordered from Inverse Path. For this project you also need to order an host adapter – without it we can’t implement this project.


The armory can be used in two modes, host and non-host mode. The non-host mode is the default mode, which allows you to plug the device into a USB port and can access it via an IP address (it uses CDC Ethernet emulation to achieve this feature). It is essentially another computer plugged in into any computer. This configuration is interesting for hosting secure data, some kind of HSM, a secure messenger, TOR router, password manager, secure Bitcoin wallet, and so on. This wiki entry lists many other applications. Anything where hardware integrity is important because the device is so small that you can always carry it with you.

The host mode is the interesting mode for this project. In this configuration the USB armory is a standalone computer. We can attach other USB devices to it, for example, a keyboard, a USB monitor, a Ethernet and/or WiFi dongle, and so on. As long as there are Linux drivers you can attach them to the USB armory. With this mode it is very easy to build a small air gap computer – the goal for this project.

One of my first projects was to build a private travel WiFi hotspot/firewall. The idea is to have one WiFi interface connecting to the public network, and another WiFi or Ethernet dongle connecting to my private devices. This way you can isolate your machines from the public network and still use it. You power everything with a battery power pack and you have your own hotspot. These days there are many devices that do this. The key difference is that you fully control this one and avoid potential backdoors and bugs that plague this kind of device (none has secure boot for example). You can also easily add TOR routing and any other cool features (DNS tunneling to bypass annoying airport networks, etc).

Last week I gave a talk focused on physical and firmware security where I mentioned this setup and finally decided to write about my Armory Sandbox. The project has the following hardware and software requirements.

Hardware requirements:

Software requirements:

  • Debian 8.x host (VM or not)

The design is the following:


In this design a battery power pack is used to power everything but a self-powered USB hub is also ok if portability is not an issue. The USB armory host adapter can also work as a USB condom (only power lines are connected, data is blocked) meaning that we can safely power it from a normal USB port if necessary. The power pack can also power the USB or it might need extra power if connected devices are power hungry (big hard disks for example). The USB armory connects to one end of the host adapter, while the USB hub connects to the other end. Every other USB device is of course connected to the USB hub. The USB Ethernet adapter can be connected to the network where we want to copy data to, and to increase the air gap security a firewall can be set between the USB armory network and whatever network we want to access it from. Block everything but SSH and the air gap security just increases a notch (it now requires a malware that packs a zero day to bypass our firewall).

There are a few pre-compiled installation images by Inverse Path and other Linux distributions. Their default configuration is the non-host mode. To enable the host mode on these images please refer to this document.

I did not use a pre-compiled image because at the time the Linux kernel had no native support for the USB Ethernet adapter I bought (although the manufacturer made driver available) and building my own also allows me to customize it with extra software. Very recently Inverse Path made available a Makefile to build a Debian based image (instead of copy & paste a series of commands as before).

I made a fork called Armory Sandbox that adds some additional forensics packages, and a Linux kernel configuration that includes all the necessary drivers (both for the USB Ethernet adapter but also additional file systems, HFS+ for example). We need to support common filesystems we might find in target USB devices. If you have any specific requirements you need to generate a new kernel configuration file and update the included one. The default Armory Sandbox kernel configuration is located at kernel_conf/armorysandbox_linux-4.9.config. To update the kernel configuration you need to do it the following way:

KBUILD_BUILD_USER=usbarmory KBUILD_BUILD_HOST=usbarmory ARCH=arm CROSS_COMPILE=arm-none-eabi- make menuconfig

Save the configuration file and copy over the old config file (or just save it directly from kernel configuration). If you don’t do it this way the configuration file will be built for the host machine (x86 in this case) while our target is an ARM CPU. You can use other make configuration options if you are happier with a non-graphical kernel configuration mode.

But before we can build our own image we need to install some required software in our Debian host – ARM cross compiler and software required to build the root file system.

sudo apt-get install bc binfmt-support bzip2 gcc gcc-arm-none-eabi git gnupg make parted qemu-user-static wget xz-utils zip sudo debootstrap

The Makefile verifies the kernel and U-Boot signatures so we need to import their GPG keys:

gpg --keyserver hkp:// --recv-keys 38DBBDC86092693E
gpg --keyserver hkp:// --recv-keys 87F9F635D31D7652

We are now able to cross compile code for our ARM target.

To start building the Armory Sandbox image first clone the repo into the Debian host machine:

git clone

Edit the Makefile and add your own ssh key into SSH_KEY variable.

You can change the default Debian mirror to one that is faster for you. Just edit the DEBIAN_MIRROR variable. You might also want to change the default image size variable IMAGE_SIZE from the default 3500Mb. This assumes a minimum microSD card of 4GB. If it is bigger we can resize the partition later FAQ. If you don’t want to resize you can change this option – you just end with a bigger image that will take longer to write to the microSD card.

The default account is usbarmory and password is the same as username. You should definitely change the default password (edit the Makefile, look for CHANGEME string). We definitely don’t want malware to try to exploit a default password.

The next step is to finally build the raw image. This is done in four steps:

  1. Debian filesystem and packages.
  2. Linux kernel.
  3. U-Boot.
  4. Install kernel and U-Boot into the raw image.

If everything goes ok you end up with a armorysandbox-debian_jessie-base_image-YYYYMMDD.raw image file. Now we just need to write the image to the microSD card:

Linux (verify target from terminal using dmesg):

sudo dd if=armorysandbox-debian_jessie-base_image-YYYYMMDD.raw of=/dev/sdX bs=1M conv=fsync

Mac OS X (verify target from terminal with diskutil list):

sudo dd if=armorysandbox-debian_jessie-base_image-YYYYMMDD.raw of=/dev/rdiskN bs=1m

You don’t need to care about making partitions in the microSD card. This command will wipe out everything in the microSD card, and the raw image we generated already contains the necessary partition information. So please be careful and double-check the target device before pressing enter.

After dd finishes writing the image you can finally remove the microSD card from the host machine and plug it into the USB armory. Power on the USB armory and connect the serial console (the header layout is available here) and verify if it booted correctly.

The default IP address is without any configured gateway (at least by default we don’t want this device packets to go anywhere wild). You can just add an IP alias to the machine that will use the network to access the Armory Sandbox.

Mac OS X:

sudo ifconfig en0 alias

If this network is not ok for you just edit the Makefile before you build the image or log in via serial console and modify /etc/network/interfaces configuration file.

If you want to enable Secure Boot feature you should read Inverse Path secure boot document. Keep in mind that this feature is currently less valuable because of the mentioned security issue but it is still useful in some scenarios like this one, at least until the full vulnerability details are made public. The advisory is mostly concerned with unattended hardware and physical tampering but without full details we can’t evaluate if for example some kind of malware/exploit could be able to defeat secure boot and somehow compromise our setup and/or taint our analysis. But the biggest reason for not being included right now in this setup is that this feature involves permanent and irreversible actions.

To add packages you need to edit the Makefile and modify the line with qemu-debootstrap command. I had some problems related to packages with dependencies on Python 2.7. There were some issues with python 2.7 minimal package dependency. Not sure yet how to solve it – there are some bugs reports about this. If you really need the packages that have problems and fail to build the image you can always add them later on via apt-get or dpkg (either upload them manually, or connect the armory to the Internet).

When the Armory Sandbox finishes booting, you can log in via the serial console or SSH, plug in any supported USB device, mount it, and analyze its filesystem, or image it for analysis on another machine. After you finish analysis you can just discard the microSD (or sell them on EBay) if you want to be really safe, or just wipe it out and rewrite the Armory Sandbox image you built. This brings an additional problem, how to securely wipe the microSD card: self wipe, another isolated device just to wipe? We need to be careful to not break the air gap with a microSD card that might be potentially tainted by the USB devices we plugged in.

This project is far from the first to attempt to build an isolated USB analysis system. For example, has previously built CIRCLean USB Sanitizer using a Raspberry Pi device. The problem with this device is that it tries to automatically convert untrusted documents into another format, and more important to me, it mixes storage devices – the same “isolated” device accesses the bad USB and the good USB. It is breaking the air gap by design. I prefer a solution where the access is made over the network because we can add a firewall between the isolated device and the desktop machine. Also I don’t want to automate any data conversion, I just want an air gap. Of course CIRCLean project can be modified to accommodate these changes. Raspberry Pi doesn’t have a secure boot feature on its default package (although there are some available add-ons to achieve this), and that was a big plus on the USB armory, at least until vulnerabilities were found (my original setup was created way before these vulnerabilities were announced).

The USB armory is a super interesting platform and with some creativity really nice projects can be made out of it. You should definitely purchase one and explore it.



  • 0

Can I Trust My Vendor’s Security Claims? Peer-reviewed vs. self-certification methods

Category : HP Security , Uncategorized

Format-preserving encryption (FPE) is in the news recently, as two researchers demonstrated a cryptanalytic attack on one method that NIST had endorsed—FF3. NIST now expects to revise their endorsement of FF3 (Special Publication 800-38G) after details of the attack are published to either change the FF3 specification or withdraw approval. It’s important to be aware, this news is independent of NIST continued endorsement of FF1 format-preserving encryption (FPE).

However, this very review process—of a publication leading to expert analysis and subsequent revision for any newly discovered weakness—is precisely how we obtain trustable security systems. Without it, we must simply rely on obfuscation and hope from the words of sales reps, none of which is reliable for meeting the security requirements of today’s increasingly high-risk, technically-sophisticated world.

Nonetheless, since the FF3 attack was revealed a little over a month ago, fear, uncertainty, and doubt has started to emerge. Some of this is natural , as enterprises review options and understand impact. However opportunistic vendors might be attempting to re-direct the conversation to  often-confusing alternatives to FPE. Perhaps worse, some may be denigrating  the process of public review.

Proven in use by the largest organizations, FPE is an industry-defining breakthrough invention by HPE that has been securing the world’s most critical data, from financial information and health care data to sensitive identity records, and more. While HPE’s FIPS-validated FF1 implementation of FPE is not affected by the attack on FF3, it’s worth understanding a bit of the confusion about the NIST process impact.

For reference on HPE’s FPE position, refer to our last blog topic where we review HPE’s FIPS-validated format-preserving encryption, “At HPE, Strong AES FF1 Crypto and NIST Standards Matter

So what is the current status and what’s new since the attack was announced?

  • HPE customers using HPE SecureData based on FF1 encryption methods are not affected—it is still business as usual for the industry’s first FIPS-validated solution available for FPE that uses the robust FF1 method based on security proofs
  • No new compromises in the cryptanalytic attack status since April 12 for FF3, and
  • NIST has not yet determined next steps for FF3

With the above in mind, it’s worth looking at the reality of the current situation:

The NIST gold standard for security assurance helps determine vendor-independent trust
NIST standards and recommended best practices remain the benchmark of credible security assurance, both in federal markets as well as commercial. Notably, HPE continues to offer the only FIPS-validated FPE solution on the market with HPE SecureData with Hyper FPE based on FF1.

With heavy scrutiny and open challenges that are out in the public domain, security experts realize it’s more credible to be held subject to public peer review that helps remove the mystery of security compliance, than to simply take at face value vendors’ assurances . Trust should be earned and NIST remains the benchmark with public transparency in mind. Security vendors must welcome the critical public scrutiny of due process.

Alternatives to FPE may not be a relevant substitute
Traditional tokenization methods or AES encryption, for example, may not best offer the data masking flexibility, application usability with underpinned security, and similar values that make FPE best for data security applications where data in use protection is critical. And this assumes those alternative technologies are fully qualified as a starting point. Even so, relying on less flexible encryption approaches may not fit the needs of today’s modern application requirements, such as Big Data or IoT, where massive scale and usable data analytics are business concerns where FPE can help offer a perfect solution fit.

So with vendor credibility in mind, what should I consider to help ensure a trusted approach to FPE?
It’s important to understand how solutions are vetted to meet your needs vs. ambiguous claims that emerge:

Published methodology: Look for vendors willing to publish their methods for peer review and meet publicly-accepted standards. Peer review analysis helps ferret out methods and secrets, remove obfuscation, and avoid hiding behind claims, in hopes of achieving acceptable security methods.

Reliance on questionable expertise: Be leery if methods haven’t been analyzed by multiple, independent, expert third parties to help ensure credibility. Similarly, avoid methods that only examine security in terms of “brute force” risk. This is analogous to claiming, “the door can’t be broken,” when the lock itself is completely flawed. Whereas, NIST and similar industry standards bodies open up review to a wider audience who understand the credibility that these standards bodies have at stake.

The bottom line to remember is this—the cryptanalytic attack and review of FF3 is precisely welcoming of the wide scale and diverse scrutiny that ensures validation meets stringent security assurance criteria. Through process and procedure, potential technology adopters have an independent and trusted reference that supports maintaining a high bar for trustworthiness.

With HPE’s FF1 method, security was not compromised at the expense of performance shortcuts, as the design was prioritized to be secure against the variety of attacks, such as what compromised FF3. Nonetheless, public scrutiny is welcome, as it’s better to recognize exploits before they happen in the wild by more sinister actors.

While HPE customers using SecureData FPE solutions based on FF1 are not directly affected by the FF3 news, it’s easy to get caught up in the confusion of competing arguments and start to have doubts. We’re happy to continue the conversation by contacting us for more information to help guide you toward smarter, well-vetted, technology choices.

For more information, contact HPE Security – Data Security or your local HPE representative.

More info:

  • 0

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

Category : Uncategorized

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 (top) in earlier versions and present in most later versions (bottom)

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 (top), last saved names (bottom).

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 20thand 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 19thand 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 15thDecember 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

To Improve Health IT Security, Recognize the Importance of Privilege

Category : Uncategorized

The increased use of electronic medical records and rapid advances in healthcare technology have made hospitals target-rich environments for hackers. Unfortunately, the maturity of hospitals’ cyber security programs often are years behind that of other technology-dependent sectors, such as financial services. It’s no surprise that cyber security was a prominent topic at this year’s HIMSS conference.

In our conversations with industry professionals, we hear a widespread concern about the security posture at their hospitals. Outdated and unsupported software, inadequate resources, a lack of executive support, cultural resistance, and rapidly evolving technology have left hospitals vulnerable to attacks such as the ransomware exploit that forced Hollywood Presbyterian Medical Center to pay a $17,000 ransom to regain access to its network last year.

The problem is not limited to ransomware or network access. Poor cyber security hygiene makes networked medical devices on the hospital floor vulnerable to breaches, potentially putting patients’ health and lives in the hands of intruders. Properly managing access to privileged accounts and critical devices can mitigate risk and significantly boost hospitals’ cyber security posture.

The healthcare environment

Hospitals and medical centers are complex environments where advanced technology is supported by networks that were not wholly designed for it. Networked monitors, infusers, ventilators, etc. provide improved patient healthcare and reduce staff burden, and their deployment can increase the number of network endpoints by the thousands. The nature of these devices – they are critical to the health of patients — creates a conflict often seen with operational technologies and advanced security controls.

In a budget-conscious industry that struggles to control costs, decision makers without an understanding of IT often do not prioritize the critical task of cyber security. The mix of administrative, medical and technical users on the network also makes it difficult to get a stakeholder consensus on changes needed to improve security. This problem can be compounded in teaching hospitals, which like most universities, emphasize access and sharing.

The privilege pathway

The importance of controlling access to privileged accounts on connected devices was demonstrated last year when a massive distributed denial-of-service (DDOS) attack was launched against Dyn, a provider of Internet services to Internet sites. It was reported that the attack was conducted using millions Internet of Things devices compromised by the Mirai malware, which relied on factory-default user names and passwords to infect them.

These user names and passwords were easily available and intruders were able to access and install Mirai malware on thousands of online devices such as digital video recorders and IP cameras. Because device owners did not change the default settings they became part of a massive botnet used to launch DDOS attacks.

The impact of this risk goes beyond consumer devices and DDOS attacks. Privilege—the ability to use accounts that give users wide-ranging powers on a network and devices—is one of the first things an intruder looks for in an attack. Default administrative passwords are an easy way for intruders to get onto the privilege pathway and enabling them to complete their mission. This can put medical equipment on the hospital floor at risk of compromise; and the stakes with these devices are much greater and the threat more urgent.

Blocking the privilege pathway raises the bar for attackers by increasing the amount of effort and level of skills needed for a successful attack.

Mitigating the risk with good cyber security hygiene

Practicing good security hygiene in the form of proper password management is an effective way to reduce the risk from a breach. Managing access privileges does not mean denying them. Ensuring that default passwords are not being used, that administrative passwords are not being shared, and that all passwords are properly managed secures privileged accounts without disrupting access by those who need it.

This can be done without changing processes or disrupting established procedures. CyberArk has developed a powerful, modular technology platform that provides a comprehensive Privileged Account Security Solution to address this threat enabling healthcare organizations to take a painless first step in maturing IT security.

  • 0

Cybersecurity Leadership Forum

Category : Uncategorized

Register today to ensure your seat at the annual Forcepoint, powered by Raytheon, Cybersecurity Leadership Forum. The event will host discussions on the current state of cybersecurity and how to best prepare for future threats. This year’s forum is a unique opportunity to engage with thought leaders and hundreds of peers across Industry, Defense, Intelligence, Federal, Civilian and State & Local government.

This year’s keynote speakers include:
General Michael Hayden – Retired four-star general who served as director of the Central Intelligence Agency and the National Security Agency.
Theresa Payton – Former White House Chief Information Officer (CIO), cybersecurity authority and expert on identity theft and the Internet of Things (IoT).
Peter Singer – Technology and Cybersecurity Futurist who was featured on the Top 100 Global Thinkers List by Foreign Policy Magazine and in Defense News as one of the 100 most influential people on defense issues.

Tuesday, April 11, 7:30 AM – 4:00 PM

Register now

  • 0

How the future of application services will impact your business

Category : Uncategorized

Because your organization relies on apps to drive customer engagement, employee productivity, and revenue, they need to perform without fail. Today, there are a wide variety of application services designed to enhance security, improve performance, and ensure reliability, but what is the right strategy for your business?

Complete the form (we promise not to share your information) and you’ll be registered for this webinar. **This is an end-user only event.** If you are a partner and want to learn more about the content of this meeting, please contact your channel account manager.

What You’ll Learn

  • The most critical security services to reduce risk in multi-cloud deployments
  • If IoT will introduce new application service requirements
  • How organizations are using programmability to achieve OpEx reductions


  • 0

Target of Massive DDoS Attack and Ransom Demand, Lloyds Banking Group Manages to Fend off Cybercriminals

Category : Uncategorized

In the matter of 48 hours, over 20 million customers couldn’t check their  bank accounts online. And it’s all because of two people. Two cybercriminals, to be exact, who worked in tandem to conduct a DDoS (distributed denial of service) attack against Lloyds Banking Group. The end goal? Demand a ransom from the banking group, which they knew would be desperate to restore access back to its irritated customers.

 So how exactly did this DDoS attack work? To start, the cybercriminals bombarded the widely-used British bank’s online platform with millions of fake requests designed to grind the group’s systems to a halt. That halt managed to last almost three days, denying access to millions upon millions of customers across the U.K.

Then, the pair sent an email to a Lloyds Bank executive, pretending to be a consultant offering to restore the bank’s system and get it back online for a small fare of 100 Bitcoin (£75,000 / $94,000). Luckily, the disguised ransom extortion failed, as the cybercriminals’ bitcoin address still has zero balance with zero transactions made. As an added bonus, it seems no accounts were hacked or compromised during the attack, and service has returned back to normal.

Lloyds IT security experts are to thank for that, who “geo-blocked” the source of the attack, which is a security technique that effectively drops a portcullis over the server launching the attacks but also stopped legitimate customer requests from that area, too.

Though no customer data has been stolen and service is back online, this cyberattack is an unfriendly reminder about the nature of DDoS attacks, their ability, and their true impact.

Joe Bernik, Intel Security CTO for Financial Services, noted that the attack is nothing new, but attacks like it aren’t going anywhere. “As one of the oldest forms of internet-borne attacks, DDoS attacks are effective and popular because the internet architecture and protocols it uses easily lend themselves to this form of attack. Therefore, it makes sense that the attack on Lloyds’ banking platform is similar to the DDoS attacks that impacted large U.S. banks in 2013 and 2014 as well.”

Bernik continued, “Adding to this ease, DDoS attacks are highly visible by nature, and easy to perform, given the availability of ‘for hire’ botnets.  It’s also important to remember that—especially in cases like Lloyds Bank—a DDoS attempt can be part of a larger attack and could just be a detractor used to redirect security resources.”

Indeed, such attacks are something all banks need to be aware of in order to be on high alert. They need to look for threats and evasive attacks across their entire network and across all omni-banking touch points.

There is nothing unique here.  Yes DDOs attacks are here to stay.  As are cyber threats/attacks of all sorts. The bigger question is….banks need to shift their security posture to take a more offensive stance and not only be at the other end of the fire hose.  Granted that’s easier said than done.  They also need greater visibility “holistic view” into their security posture versus multiple myopic lenses that may hamper the ability to proactively detect and block attacks.  What did we learn about this attack on Lloyds bank….that customers started to report that they could not access their accounts which then triggered an alert.  Detecting and blocking attacks on the onset will continue to be both a challenge and a desired goal for banks. Whether it’s a DDos attack, zero-day attack or some other form of evolving and emerging threat.


  • 0

Top Seven WordPress Security Issues and How to Protect Against Them

Category : Uncategorized

WordPress is the most popular publishing platform in the world. It runs over 24 percent of all websites worldwide. Since it’s an open source platform, the WordPress code is visible to everyone and because it powers so many websites, it has become a target for hackers. The most recent vulnerability discovered prompted the update to WordPress 4.7.2 to secure the WordPress core against SQL injections and the posts list table against a cross-site scripting (XSS) vulnerability.

If a perpetrator can find a vulnerability in WordPress itself, or a popular theme or plugin used by WordPress, it lets them very quickly infect a large number of websites using automated attacks.

Eric Murphy, Director of Security WP Engine, says “Web applications will never be 100 percent secure. Because WordPress makes up such a huge chunk of the internet, there’s the misconception that it’s less secure than other platforms (because it’s commonly targeted by hackers).

“With WordPress,” says Murphy, “a site owner must not practice laxity, but take extra precautions to harden his/her site’s web application. Security goes beyond the WordPress core code base; security management responsibilities fall on the site owner, IT departments, primary users, and external platform providers. It’s important that all parties understand potential security risks, and how to alleviate them.”

Web operators are always juggling the tradeoffs between security and website performance. Murphy says various security plugins that are implemented in a poor fashion can significantly degrade a site’s performance. Additionally, when default server software environments are not properly configured, performance (and security) inconsistency can occur. 

“The biggest security vulnerability is an outdated WordPress component,” says Murphy when asked about what web operators can do to immediately to secure their WordPress sites. “The most important thing people should be doing is ensuring their WordPress core, themes and plugins are all kept up-to-date. Understanding the OWASP Top 10 further enables users, developers and engineers to protect their WordPress assets.”

Common Threats Against WordPress Site

Below is a list of common hacking attempts and vulnerabilities on WordPress and what you can do to prevent them.

  1. URL and SQL Injection

WordPress executes server-side scripts in PHP making it vulnerable to URL injection attacks. This happens when malicious commands are fed through the URL to WordPress making the platform act on them without authorization. SQL injection is a type of these attacks in which malicious commands target the database triggering behavior that could lead to exposing sensitive information that hackers use to deface and manipulate your site.

The best defense is setting up a thorough set of rules in your .htaccess file in Apache. This will act as a screen from all the URL requests and help strip off many of the malicious URL injections.

2. Access to Sensitive Files

This happens when you leave much of the sensitive files about your site easily accessed by anyone. Such files include the installation, PHP and wp-config files.

As with URL attacks, this is easily protected by writing a set of rules that blocks access to directory files, the site server and your CMS.

3. Default Admin Username

Retaining the administrator account after installing WordPress with the user name “admin” increases your site’s predictability, making it easy for a hacker to guess his way to your site. Create a new account with a new unpredictable name and strong password. Assign all the administrator privileges to the new user and delete the default administrator account. This makes it harder for any hacker to predict both username and password.

4. Change Default Settings

Many hacking attacks are done using automated programs. These rely on the default set up of your CMS. Changing the controls and permissions will protect you from many automated attacks

5. Update Your Site Regularly

Make sure everything from the platform to the plugins and extensions are all regularly updated. Making an update as soon as one is released will help prevent your site being compromised. Audit your plugins and remove unused plugins and themes and any vulnerability they may pose.

6. Enforce 2FA

Two-factor authentication adds a secondary form of identification in addition to an email address and a password to log into an account. This added layer of security makes it significantly harder to breach an account since the information is something only the user knows and can provide such as a security question, a thumbprint scan, a confirmation pin provided via a mobile device that is linked to the account or even an ID card.

7. Use Secure Hosting

Look for a hosting provider that offers managed patching when minor WordPress patches are released, and makes recommendations when major patches are available. Other features include reliable infrastructure security threat detection, firewalls and network monitoring.

Modern web security threats continue to persist. But Murphy is confident WordPress is prepared for the challenges ahead. “I think the community becomes very important here,” he says. “Reporting known vulnerabilities to or is the first step in communicating there’s a security issue so the open source community can work toward new security patches, and warn users of known issues with a certain plugin.

“One of the things WP Engine is working to change is the concept of threat intelligence sharing. Bad actors do this very well through a variety of mediums. Proper bug bounty programs, and intelligence sharing will be key to moving the community forward in WordPress security.

“It’s important for WordPress and its community to continue educating its users to know how to keep their site safe. No matter how secure WordPress is out of the box, it’s all for nothing if one fails to keep their site components updated, developers deploy exploitable code or practices general laxity in security best practices.”

Finally it’s important to implement security at all layers. A recent article from WP Engine discusses hardening WordPress at the application level. In addition securing a website’s infrastructure prevents unwanted hacks. Securing WordPress itself is not enough; it requires hosting providers, developers and users to work together to understand what’s required to prevent malicious activity.

Is there a question you have for our team or the team at WP Engine? Leave us a comment, we’d like to hear from you.

  • 0

Gigamon & Cisco Joint Solution Presentation

Cisco’s Doug Hurd covers the Gigamon & Cisco joint solution.