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

This post is also available in: 日本語 (Japanese)

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 23^rd, last saved 25^th October and first seen by our Wildfire cloud sandbox 26^th 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 30^th 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 30^th 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 30^th 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 30^th 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 30^th 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 30^th 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 18^th version. Only a couple of the 20+ versions after December 18^th were missing these permissions with no obvious evidence (e.g. new author, major code release, day of the week etc) to explain why but given the consistency with the others using permission it’s possible a human error occurred or the actor’s release process failed to check whether permissions were set.

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

In the week between Christmas and New Year – you know, that time where you’ve eaten too much, perhaps drunk too much and work, and the world in general, tends to be in go-slow mode – you would be an attacker’s perfect recipient of some unwanted phishing emails to take advantage of your stupor. On Wednesday December 28^th 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 25^th 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 14^th December, making hardly any revisions and spending almost no time editing the document but doing so also on a Windows 7 host.

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

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

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

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

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

Figure 24: Number of versions per month

The JSE Payload

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

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

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

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

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

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

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

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

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.

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.

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.

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.

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 20^th and the latter on December 14^th. 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 26^th (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 26^th.

Two weaponized document versions, shown in Figure 32 below were seen on the 19^th and 30^th 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.

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 15^th December 2016 – just 4 days before AutoFocus saw use of the domain – and provided the domain names parking-1.domains4bitcoins[.]com and parking-2.domains4bitcoins[.]com as nameservers. Domains4bitcoins needs little introduction but just in case you weren’t aware, such services are used for domain registration and hosting services in an anonymous fashion through the use of a digital crypto currency. These nameservers were updated on December 20^th 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 22^nd 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.

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

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

 

---

Register for Ignite ’17 Security Conference
Vancouver, BC June 12–15, 2017

Ignite ’17 Security Conference is a live, four-day conference designed for today’s security professionals. Hear from innovators and experts, gain real-world skills through hands-on sessions and interactive workshops, and find out how breach prevention is changing the security industry. Visit the Ignite website for more information on tracks, workshops and marquee sessions.