Category Archives: Uncategorized

  • 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://keys.gnupg.net --recv-keys 38DBBDC86092693E
gpg --keyserver hkp://keys.gnupg.net --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 https://github.com/gdbinit/armorysandbox

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 10.1.0.1/24 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 10.1.0.2 255.255.255.0

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, Circl.lu 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.

Source: https://sentinelone.com/blogs/armory-sandbox-building-usb-analyzer-usb-armory/

 


  • 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: https://www.voltage.com/encryption/can-trust-vendors-security-claims-peer-reviewed-vs-self-certification-methods/?utm_source=linkedin&utm_medium=&utm_term=&utm_campaign=socialmedia&utm_content=


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

nemucod_1

Figure 1: Nemucod Destination Countries by session volume.

nemucod_2

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.

nemucod_3

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.

nemucod_4

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.

nemucod_5

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.

nemucod_6

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.

nemucod_7

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.

nemucod_8

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.

nemucod_9

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.

nemucod_10

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.

nemucod_11

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.

nemucod_12

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

nemucod_13

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.

nemucod_14

nemucod_15

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.

nemucod_16

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.

nemucod_17

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.

nemucod_18

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.

nemucod_19

 

 

 

 

 

 

 

 

nemucod_20

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.

nemucod_21

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.

nemucod_22

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.

Procmon
Wireshark
Temp\iexplore.exe
ProcessHacker
vmtools
VBoxService
python
ImmunityDebugger
Johnson-PC
Proxifier.exe

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.

nemucod_23

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:

nemucod_24

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.

Browsers

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.

nemucod_25

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.

Exfiltration

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:

%TEMP%\goga.txt

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.

TEST-UID

YYYY-MM-DD HH:MM:SS

ftp://username:password@ftp.somedomain.com:21

https://username:password@accounts.somedomain.com/

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.

http://185.159.82[.]11/re/b.php

Infrastructure:

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 customer.clientshostname.com

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 – customer.clientshostname.co.uk.

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.

nemucod_26

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.

partial-infra

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.

nemucod_28

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 argos-tracking.co[.]uk. The victim organisations belonged to the Telecommunications and Healthcare sectors in the United Kingdom.

nemucod_29

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

The .co.uk 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 argos-tracking.co[.]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 argos-tracking.co[.]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.

Conclusions

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 argos-tracking.co[.]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.

nemucod_31

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

nemucod_32

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

Details.doc

List.doc

Doc1.doc

Agr.doc

YoursDoc.doc

Docs.doc

YourGoods.doc

R.doc

r_vk.doc

Vertragskopie

goods.doc

Agreement_copies.doc

documents.doc

Vertrag.doc

file

Bishop-GmbH-Vertrag.doc

Rechn.doc

Rec.doc

Email Subjects:

Your Eguipment

AW:Your order was completed

AW:Delivery

Re:Delivery

Documents

AW:Goods

Delivery

Goods

Package

Re:Documents

AW:Package

Re:Order

Re:Waiting for payment

AW:Waiting for payment

Re:agreement

Re:Your order was completed

AW:Order

AW:Documents

Re:Package

Re:Goods

AW:agreement

Get Carried Away at The Peninsula

Discover The Revolutionary Trick To Restore Your Memory!

RE: Rechnung

AW:Rechnungen

RE:Rechnungen

AWd: Rechnung

RE: billing terms

RE: We are waiting for your payment.

RE: payment

AWd:Rechnungen

AW:Auftrag

AW:Dokumentation

AW:Technikdokumentation

RE:Begleichung

AW:Schlussbestimmungen

re:bishop-gmbh-vertrag

AW: Rechnung

PE Dropper Hashes

1b64d1c93e53fa74d89c3362c30899644e9fef7f11292f40740b216bcbe03285

1db89009b678ba4517fc7490b9a7f597b838939499365374eba32347393fdd4e

85d56628f7ec277a5f49a801ef4793072edd56d9c26b0bdb9b3dc348366c734a

b75b3ff65632b65d1d641075bd2f5ed0ede93da3a35d7f50068b9371ee5c4552

ffc5e46200f16549f17d2d6e4d6e5e61239b711cd07fbf7932c31e2ea18a7865

Document Dropper Hashes

0a59bc35fe7bd84c955402aba2ad3883a5cdb08deb353c8f6310a163109f0c60

fee6b19ff8a39e83756345af421d3d85d20e67df62ac58bc05f514c368efc329

8e9af7d90193bddc89d1c3782477bde76f90707eb1900537c020fc02970bbd74

c173085b954ff1055fb859e6584a9e0bb3919740752351ad50706c0b7be37b51

1faa27f82bcbad0acc444727e7be35147e5a2ee92757781e5f26db614d3cee7f

6ebd2955fb137b5c983bbfb7601ea49ceb1f66119d13ce850c12d89e8c6a3742

777560483cb903ba803bfdbbd1f37353706da3a265e32da44fffb3ec7fcf07a2

7df6bd0af983f87dc34a71d009a3bd3bd272e094c6c55bf765148d836129e10c

d58cfd2d851b9c98f9de79d38944d72eddec1e2243f1065de7d8b1ed1bf1cddd

4916bc8dc91941a444d3aa41616eaebe8c3d4b095a0c566945b85c143ae532c1

de5ac4aedaca5649758bf34c87fd59967c2adeaaa0be65a58b9c8e9f6a8660f1

368304125ffd86a234aeb8c05a90b7ee40b37dae1dea7178deeda522eac9dcbc

1384934c09f6551d19150bfcf8ae954f4969d0b9ff841c93f81ebb57eecc9a71

f89edff923d1d2daf6b2ab36595e873ed7d1cd52c2f6b66b590fa636c17dced2

b1d5bfb124a15ab9068cf413de430a1c2cbd7b2bf67a766cf971269c67c3eace

256078f83cf9535c72debffa3d34818789849131e9138589728b4085e2ae2169

d3683a4fe910d5815541beb2c42b98827a1f6362073b9901a74c36e15072c1a2

cfe56d178ff873a5d984220c96570144a6674ce1b675036566a93ff6d680a981

069a4abb186efb6c3b6733cb2f35151d03eefe40cfb626d3c42aaa5f7ef342c6

97ea044a5820f9271c21bd8f1bb381099fb188a7d9f54ac72a88bf41411cf1b3

5b331693bc7ad009db3905fd37edfa94c528b6c4eee024f7a35dcc9b6b8a9c26

7e62823f8a775674b6333ff535e93a9fc0bdcfd943c903fe85e614b34d692549

a85b040e923e45a3e139576c2086a8f1671b1c60053274d850218ffa422f80e6

1c95a2a32b639008245a205f51aa7fbafc0b61ecc6879f9978be174feee516f4

9e9e7ade1def82a56898415c079bd3f861c143f9db6770a28592bbbe04d5f234

40fd876c5d7f859484a8d3a021ce3c5eeba23deb8574f4b598aeaa6a0ded7815

92c82d7ea7b89f02c5b8e7d93d2a4ad17fbc0688ff9ad881cc185c18ea466232

ae3bb85b87d40a12e82b2545fd4c9087b3e847a744a27c1ac215dd38821ced87

c600c7638474fb31664ab32fb9aad5c216096b2c68d93c9eb37cf0476868cf05

8451cf3f5e5e2576f2ad36a4f19998e5824c2ab185f40ddec460a81ab1a8525a

34e5104bea2728cf9107b4ede124daee8ac68ad0979c66c356ddf3a0e6d0f4c6

7b48b21b10990cd53bb8969930b9f0b39cc495e95a33c38f80024a21a72b0176

dcf3c00a20af527869771a7834565fb938739e3abf84038e2376b23a14926a38

d8e62ce3039921c11872319a09acc61038f2452a6a2fdb8c0d3a0848b56b26ff

50ab7834e98c2f40d7441006a0221c07bff5f9f694999b595daa29b37c9a5e12

b4d3c369449ead7ced48f84b9ea29cb4dbc6f485958e813b102c1d32ce62d3e8

a02ed37812ac37d44979d5131aa10927fb9b9bd09aae2b470e65532bc694b27c

61bcd9b0c11989d6049fd181786f1748116c128bd4768d1b6849805186190320

6edbbc7f02179211c5b8da74a770492e25b31be683468629a073f313f25ec8b6

985d44dfeaf83c2c39c331e4b07b19e8726fb0ec168223455476132fe8c32fc8

1a60afa5c3dcff0fc41179e6a3b71ea0a92e4b50192eaa4c8e2b16ea0c50a229

76edebe74e015e709abb662c4fa8a2db2f24c12d5b6c51822eef403bf3c3a304

3fdcaf24d5c45d7a8dcf1b2932c026915a982de19b52a8f346ca312c58d36f05

561343438f0c26fa7628a91584628a5bd62c3abe1c0cf890b9fdb0528adbde62

7f53abc951258d5663119f3ac383b8f84da5acbf0bb9063e5e113ca87b1843ae

7c552166089ebf45081a5d14bef331e3153a5de50c53b66211b044a08f46153c

432a220ca1e6c64546f21807e17521c243cce2a63d956d0c0cf21a1101835829

297665276699830549c83ae79cd2c48e23733e9569be8040ee38d08a4d99192e

5e54c865afbd42f5a7b4007840e3099d8e1882c58542d08263ffc23fe994ef9b

8aa5a12bb237f93fc0c3f150a41fcc60e86007b1000c2b133457b2be27dfad4e

8e7f77a61a1e710e368257a37fe6785f9b608bb068e5c40824623d299997dbf0

379615acf199bb0beaee736824067b83dcbb2ae60eb648576c81d4971330dd16

ad94f396f739d4df07f188b9babee829d07da01c986f4795a098d66137c7149c

ff7fa949a99d745143d41eeb6b450dca3d95a38031e304b1e829c5bda2ce5213

034421d601d43883528d68741c87e765d76ff4123161d364f6eddfae1f3c7493

e86c5f4fbcd626e1ec4c211ae1ed0d541fc453e6753e84a724f534c0b9700029

8b96d5316accd7d2ee0af01a4ae2766b7173d7705b3eef14d9dcb10cd34238ed

PE Password Stealer Hashes

53edea186162d84803f8ff72fb83c85f427b3813c32bd9d9d899e74ae283368e

76b703c9430abf4e0ba09e6d4e4d6cf94a251bb0e7f3fadbd169fcef954a8b39

99c50b658c632214f0b133f8742a5e6d2d34e47497d7a08ed2d80e4299be3502


  • 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

REGISTER


  • 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 security@wordpress.org or plugins@wordpress.org 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.


  • 0

Can the Phishing Menace be Reined in?

Category : Uncategorized

Phishing is the starting point for most data breaches. People are the weakest link to an organization’s security posture. Current approaches to controlling the proliferation of phishing have shown no signs of success. Imperva advocates the widespread use of Web Application Firewalls (WAFs) to prevent cybercriminals from gaining access to compromised servers and launching phishing campaigns. Researchers from the Imperva Defense Center working with Intsights*, an intelligence driven security provider, have discovered how cyber criminals are lowering the cost of phishing by enabling Phishing as-a-Service (PhaaS) using compromised web servers.

The Hacker Intelligence Initiative (HII) research report from Imperva shows that PhaaS is 2X more profitable and 1/4th the cost of an unmanaged phishing campaign. The traditional approaches focus on training people and deploying better malware detection, but training people has barely made a dent. The Verizon Data Breach Investigations Report (DBIR) from 2016 shows a disturbing trend of more users being susceptible to phishing in 2016 versus the previous year. Most endpoint protection software have increased the attack surface of an enterprise and possibly allow attackers access to the enterprise network.

Every enterprise has deployed a next generation firewall raising the barrier for network breaches and forcing hackers to exploit vulnerabilities of the users with the use of phishing. Our approach is to the choke the supply of compromised servers and contain phishing by making it expensive and cumbersome for hackers to launch phishing campaigns.

Find out more about how to prevent your web infrastructure from being exploited by PhaaS by downloading the full report. Download the full infographic here.

*Intsights worked with Imperva to expose the hackers identities as well as assist with understanding the costs of phishing attacks in both Phishing-as-a-Service and in traditional Phishing models.


Support