Ransom note displayed as the legal notice (Redacted)

PYSA Ransomware is not your Amigo

With amigos (friends) like this on the dark web, who needs enemigos (enemies)? PYSA ransomware, an acronym for Protect Your System Amigo, was one of the top four most common ransomware variants in Q2 2021. PYSA are another ransomware player of some significance, who have leaked sensitive data from almost 200 organizations. PYSA is being offered by its operators to “partners” using the Ransomware as a Service (RaaS) model. The RaaS model is popular with cyber criminals as it provides a division of labor between the ransomware authors and their partners. The operators create and update the ransomware itself, as well as any backend necessary, and the partners compromise victims’ networks, exfiltrate sensitive data and deploy the ransomware. They then split any ransom payments, with the majority going to the partners.

What Is PYSA?

PYSA has been listed in recent reports as one of the top four most common ransomware variants in Q2 2021 and has not previously been the subject of a Threat Report. PYSA ransomware is an evolution of Espinoza ransomware, which was first seen in October 2019, with the first PYSA variant surfacing in December 2019. It is offered via the common RaaS model, with the operators providing the ransomware for a cut of the profits, leaving the “partners” to compromise victim organization’s networks, exfiltrate sensitive data, deploy the ransomware and execute it.

PYSA dark web home page
PYSA dark web home page

As with most other ransomware operators, PYSA operators host a dark web site where they post sensitive data stolen from victims on the “Partners” page, the data is listed under the heading of “Something interesting from our partners”. For this Threat Report, a review of the site was performed. Please Note: No stolen data was accessed or downloaded during this review. The site, which uses the font and color scheme of an MS-DOS application, lists 189 victim organizations whose data was released, covering the period April 2020 to August 2021. For each victim, various zip files are provided for download, with the file listing for each zip file also able to be displayed. Based on the names of the files present in these zip files, there appears to be a wide variety of sensitive personal, financial, and business information. This data suggests that data exfiltration is one of the primary objectives of the PYSA operators and partners.

Partners page (Redacted)
Partners page (Redacted)
Zip contents example (Redacted)
Zip contents example (Redacted)

A review of the victim organizations listed on the dark web site shows most of them are located in the United States, with the United Kingdom, Brazil, Italy, and Canada the most common of the remaining 24 countries. A breakdown of victim organizations based on industry found Education the most common, followed by Medical, Manufacturing, Construction and Local Government. There is no evidence to determine if these target profiles apply equally to all PYSA victims, or only those who did not pay the ransom in time. The following tables list the country and industry breakdowns in full.

List of victim organizations by country
List of victim organizations by country
List of victim organizations by industry
List of victim organizations by industry

As for the ransomware itself, it does not contain any significant anti-analysis or evasion mechanisms, in fact the list of file extensions which are to be encrypted are hardcoded in plain text into the ransomware. This could be because PYSA tactics seem to place an emphasis on exfiltrating sensitive data from victim’s networks prior to deploying the ransomware. As such, the attackers will likely have visibility to which anti-virus solution is in use and can ensure that the ransomware will not be detected by that product. Therefore, the PYSA authors don’t see the need to invest large amounts of time and effort into sophisticated code. PYSA uses the Crypto++ library for cryptographic functions, rather than the common practice of using the cryptographic libraries which are part of Windows. Encrypted files are given the .pays file extension. Files which are 1KB or less in size are not encrypted, regardless of their file extension.

File extensions to encrypt hardcoded into the code
File extensions to encrypt hardcoded into the code

Rather than change the endpoint’s desktop background to an image of the ransom note, PYSA uses a novel technique. It changes the value of the LegalNoticeText and LegalNoticeCaption entries in the Windows registry so that the ransom notice is displayed at each reboot. These values are normally used to present users a notice of conditions of use for a system when logging on. The ransom note is also placed in a text document named Readme.README, dropped in every directory on the system.

Ransom note displayed as the legal notice (Redacted)
Ransom note displayed as the legal notice (Redacted)

PYSA are another ransomware player of some significance, who have leaked sensitive data from almost 200 organizations. Whether these organizations couldn’t afford to pay the ransom or recovered their data via other means, it appears the data contained in these files would constitute a data breach for each of these organizations. This is an example that the threat of releasing sensitive information is often potentially a greater motivating factor for victim organizations to pay ransoms than regaining access to encrypted files, as they may have alternative means to achieve that, such as backups.

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. The most common attack vector for PYSA ransomware is brute force attacks against poorly secured, internet facing, RDP (Remote Desktop Protocol) and AD (Active Directory) servers.

When/How Did BluVector Detect It?

Fifteen recent, publicly available PYSA samples were regression tested with BluVector’s patented Machine Learning Engine (MLE) and it detected them all, with an average detection time of 31.33 months prior to their release.


New eCHoraix Ransomware Variant Targeting QNAP and Synology NAS Devices

Small Office/Home Office (SOHO) users and tech savvy consumers using QNAP and Synology Network Attached Storage (NAS) devices, are being targeted by cybercriminals with a newly released variant of the eCHoraix ransomware. The current attacks against QNAP devices make use of the CVE-2021-28799 vulnerability, first disclosed by QNAP on April 22nd,2021, which has previously been used to deploy variants of other QNAP ransomware. Researchers believe the initial variant of eCHoraix to target both QNAP and Synology devices was first developed in September 2020, prior to this, separate campaigns were used for each device type.

What Is It?

A newly released variant of the eCHoraix ransomware (previously also known as QNAPCrypt) has been found to target both QNAP and Synology NAS (Network Attached Storage) devices. Though not commonly used by large organizations, these devices are used by tech savvy consumers and SOHO users. QNAP and Synology are some of the most popular vendors in this market segment. Though SOHO users don’t possess the financial resources to pay large ransoms, due to the potential lack of in-depth IT skills and support they may see paying a smaller ransom as their only option to regain access to their files. Researchers from Palo Alto Networks’ Unit42 team have found the potential attack surface of internet facing QNAP and Synology NAS devices numbers nearly 250,000.

Originally released in June 2019, eCHoraix is written in the Go programming language and has been utilized in multiple campaigns, including significant campaigns in June of both 2019 and 2020. eCHoraix attacks have exploited vulnerabilities in QNAP operating system software as the attack vector on QNAP devices. In the case of Synology NAS devices, administrative account credentials with weak or default passwords are subjected to brute force and dictionary attacks to gain access. The current attacks against QNAP devices make use of the CVE-2021-28799 vulnerability, first disclosed by QNAP on April 22nd, 2021, which has previously been used to deploy variants of other QNAP ransomware. Researchers believe the initial variant of eCHoraix to target both QNAP and Synology devices was first developed in September 2020, prior to this, separate campaigns were used for each device type.

It has been reported by users of BleepingComputer’s forums that each victim is given a different bitcoin address for the ransom payment. However, a forum user also noted that by following the transactions in the blockchain, it can be seen the ransom payments are always transferred to the same address. It’s unknown if all the transfers to that address relate solely to eCHoraix, however that address has received a total of more than 921 bitcoins, which at the time of writing was valued at approximately $US42 million.

eCHoraix Bitcoin AddressFigure 1: Bitcoin address (Redacted)

Samples of this eCHoraix variant are compiled for either Intel or ARM architectures, as both processor types are used by different models in the QNAP and Synology NAS device ranges. When executed, the ransomware checks to ensure another copy isn’t currently executing and hasn’t previously executed on the device. It then contacts it’s C2 (command and control) site to obtain the encryption key, ransom note text and the bitcoin address where the ransom is to be paid. Encrypted files are given the .encrypt file extension. The ransomware contains a large list of file extensions that it searches for and encrypts. The encryption process is handled in two stages, the first stage encrypts files matching a subset of approximately 40 file extensions which the authors clearly believe will be a priority to their intended victims. These priority file extensions relate to source code, image, and document files. The remainder of file extensions are then searched for and encrypted.

echoraix file extensions list
Figure 2: Partial List of Encrypted File Extensions

eCHoraix ransomware is an example that cyber criminals are not solely focused on large organizations as targets. They are aware that SOHO users and businesses represent a profitable target, albeit at a smaller per capita profit. They’re also cognizant of the fact that these targets can be considered soft, with strong motivation to pay the ransom, due to a lack of IT resources and support and a heavy reliance on the data that may be encrypted. It also illustrates that cyber security basics, such as prompt patching and good password hygiene, are critical to organizations of all sizes and every user.

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. In the case of QNAP devices, exploitation of the CVE-2021-28799 vulnerability is the attack vector, and for Synology devices it is brute-forcing of administrative account credentials.

When/How Did BluVector Detect It?

Ten publicly available samples, compiled for both Intel and ARM architectures, were regression tested against BluVector patented Machine Learning Engine (MLE). All samples were detected, for an average of 8.3 months prior to their release into the wild and up to 17 months.


LockBit 2.0 Ransomware uses Group Policies To Encrypt Windows Domains

 Cyber criminals unleashed a new propagation method that creates new group policies, increasing the threat to all Windows networks.  These group policies disable Microsoft Defender’s protections and create a scheduled task on the endpoints to execute the ransomware. In addition to utilizing the double extortion threat of releasing stolen data unless a ransom is paid, Lockbit’s operators also maintain a darkweb site with a list of their victims, a countdown to when the data will be leaked, and access to the data once the time has expired. Lockbit 2.0’s ransom note also contains a message attempting to recruit unscrupulous employees or contractors to provide access to corporate networks for the Lockbit operators. These increased threats make it even more critical to ensure highly sensitive endpoints are properly secured.

What Is It?

A new variant of LockBit 2.0 ransomware unearthed by the MalwareHunterTeam contains a previously unseen propagation method. If the ransomware is executing on a Microsoft Windows domain controller, it can create new group policies which are deployed to all endpoints in that domain, disabling various protections and executing the Lockbit 2.0 ransomware. This capability represents an increased threat to all Windows networks and highlights the need to ensure highly sensitive endpoints, such as domain controllers, are properly secured.

First seen in September 2019, LockBit ransomware uses the popular ransomware-as-a-service (RaaS) model for distribution, via “affiliates” who are responsible for compromising networks and endpoints and then deploying the ransomware. A revenue sharing approach is used to split ransom payments between the affiliate and the LockBit operators, with 10-30% of the payments going to the operators, dependent on the size of the ransom. It has been reported that in Q1 2021, LockBit held a 7.5% share of the ransomware market, third behind REvil and Conti. LockBit also follows suit with most other major ransomware operators by utilizing the so-called double extortion approach of threatening to release data stolen from victim’s networks if they do not pay the ransom in a timely fashion. The LockBit operators maintain a darkweb site to list recent victims and how much time remains before their data will be released, it also allows for the downloading of data stolen from victims if the countdown has expired.

 

Lockbit Darkweb Site (Redacted)
Figure 1: Lockbit Darkweb Site (Redacted)

 


Figure 2: LockBit Darkweb Site Stolen Data Download (Redacted)

A LockBit ransomware attack chain consists of an affiliate obtaining, or purchasing, access to a target organization’s network. Once an initial foothold is established, the attacker will move laterally through the network, performing reconnaissance to determine the highest value endpoints, such as file servers, and exfiltrating sensitive data to be used for double extortion purposes. Ordinarily, the attacker will also work to deploy the ransomware to as many endpoints as possible and synchronize execution of the ransomware to ensure the maximum number of files are encrypted. However, in this case, if the attacker can locate and compromise a Microsoft Windows domain controller, LockBit 2.0 can use it to distribute new group policies to all endpoints in the domain. These group policies disable Microsoft Defender’s protections and created a scheduled task on the endpoints to execute the ransomware. Encrypted files are given the .lockbitfile extension, which is given its own icon, using the LockBit logo.

.lockbitfile extension
Figure 3: Encrypted files with .lockbit file extension

One interesting component of the Lockbit 2.0 ransom note, which is displayed by changing the wallpaper of the desktop of the infected endpoint, is that it contains a message (highlighted in the red rectangle in the figure below) attempting to recruit employees to provide access to corporate networks for the Lockbit 2.0 operators. The message begins by asking the question “Would you like to earn millions of dollars?”. While this might seem odd, given it is displayed on an infected system which is obviously part of an already compromised network, it is potentially aimed at unscrupulous external contractors who may have been called in to assist with the ransomware incident.

 


Figure 4: Ransom wallpaper

From a technical perspective, the LockBit 2.0 sample uses various techniques to attempt to evade detection and to make analysis more difficult. The method used by the sample to detect if it is being debugged is described in detail further below. As with other ransomware variants, the sample contains a large, encrypted list of process name strings which are terminated if they are found to be executing. These processes either relate to various endpoint security and malware analysis tools or applications such as databases, mail servers and clients, and Office productivity suites. The latter group may have locked access to sensitive data files while they are executing, files which would be highly advantageous for an attacker to encrypt, including databases and mail and document files.

List of Process Name Strings
Figure 5: List of Process Name Strings

Another common malware tactic is to obfuscate the calls made to the Windows API (Application Programming Interface), by not utilizing an import table and using one of several techniques to locate and call Windows API routines directly. LockBit 2.0 uses this tactic and others which mean that the structure of the executable itself is unusual. Windows executables use the Portable Executable (PE) file format, which is made up of specifically formatted headers and components called sections. Most Windows executables will contain sections which include .text, .data, .rsrc and .reloc, whereas LockBit 2.0 only contains .text and .data. The authors may have had many reasons for this, and while the sample is still a valid Windows executable, this approach does make the sample appear suspicious, particularly to a detection technology such as BluVector’s patented Machine Learning Engine (MLE). The following figures show the sections found in the sample and those found in the executable for the Notepad utility which comes as part of Microsoft Windows.


Figure 6: Lockbit 2.0 Sections


Figure 7: Notepad.exe Sections

When analyzing a malware sample, malware analysts and reverse engineers use a debugger to follow and control the execution of a sample. Obviously, malware authors are aware of this and employ various techniques to detect if a sample is being executed in a debugger. In the case of this sample, debugger detection is accomplished by checking the value of the NtGlobalFlag, which is a well-known, but infrequently used method. The NtGlobalFlag is a specific byte which is part of the Process Environment Block (PEB), a data structure which deliberately poorly documented by Microsoft, as it intended for use only by the operating system itself. The NtGlobalFlag byte is located at offset 0x68 in the PEB. If the sample is being debugged, the NtGlobalFlag will be set to 0x70, which can also be represented as a lower-case letter p. The code from the sample checks the value of the NtGlobalFlag byte and if it shows the process is being debugged, the code will place itself in an infinite loop, which it achieves by having a JMP command jump to itself (highlighted in red in the figure below). This NtGlobalFlag check is the first code executed by the sample and is therefore obvious and is quite straightforward to circumvent.


Figure 8: Debugger checking code

How Does It Propagate?

The malware can propagate itself if it infects a Windows domain controller, it can create new group policies and deploy them, resulting in the infection of all endpoints in that domain. The most common initial attack vectors for LockBit ransomware are compromised RDP (Remote Desktop Protocol) servers and phishing emails.

When/How Did BluVector Detect It?

Two samples are publicly available and BluVector’s patented Machine Learning Engine (MLE) detected both. Regression testing has shown both samples would have been detected 91 months prior to their release in July 2021.

 

 


Destructive Wiper Malware Uses A Tokyo Olympics Lure

The Olympics have been a regular target for hacking, including the famous Olympic Destroyer worm from 2018. Cyber criminals are again using the 2021 Tokyo Summer Olympics as a social engineering lure for a malware attack likely aimed at Japanese users. Fortinet researchers described a sample of destructive wiper malware which has a filename made up of Japanese Kanji characters, translating to “[Urgent] About the damage report about the occurrence of cyber-attacks, attacks, etc. accompanying the Tokyo Olympics .exe”. This attack has rudimentary features and is likely not the work of an APT group or a nation state.

What Is It?

Despite the delay, the Tokyo Summer Olympics have captured the attention of a large portion of the world, inevitably, this includes cyber criminals. Any high-profile event or issue is guaranteed to be utilized in some form of social engineering as part of an attack. Fortinet researchers recently described a sample of destructive wiper malware which uses the Olympics as a lure and appears it may be targeted at Japanese users.

The Olympic games are no stranger to cyber-attacks, with the 2018 Winter Olympic games, hosted in South Korea, subjected to a cyber-attack during the opening ceremony. This attack, known as Olympic Destroyer, was a destructive wiper malware attack, which temporarily took down various parts of the Olympic games IT infrastructure. The malware described by Fortinet is also destructive wiper malware, however, when analyzed by the BluVector Threat Team, was found to be noticeably less sophisticated than that used against the 2018 Winter Olympic games.

The sample itself attempts to social engineer recipients with a filename made up of Japanese Kanji characters, which translate to “[Urgent] About the damage report about the occurrence of cyber-attacks etc. accompanying the Tokyo Olympics .exe”. The sample’s icon is also that of a PDF file, enticing casual users – those who haven’t noticed the file’s extension is actually .exe and not .pdf – to click on the file and execute it.

The sample itself is not overly sophisticated, suggesting the attack has not been initiated by an APT group or nation state. Firstly, the sample is UPX packed. UPX is an old school packer, initially released in 1998 and though sometimes used for legitimate software, its use is often an indication of a potentially malicious sample. The sample uses a fairly basic method – described in more technical detail below – to obfuscate a number of strings. Of these strings, 42 are the names of processes for various malware analysis and reverse engineering tools. The sample will exit if it detects any of these processes executing, in a somewhat crude – by current standards – anti-analysis attempt.

List of Process Names
Figure 1: List of Process Names

 

The main purpose of the sample is to delete files matching 20 different file extensions, located in the user’s directory and any child directories below it. These include file extensions used by Ichitaro Word Processor, created by Japanese software company, Justsystems. This fact added to the Japanese filename of the sample, indicate it is targeted at Japanese users. The files the sample will attempt to delete have the extensions: doc, docm, docx, dot, dotm, dotx, pdf, csv, xls, xlsx, xlsm, ppt, pptx, pptm, jtdc, jttc, jtd, jtt, txt, exe, log.

The sample is somewhat rudimentary, utilizing a very common packer, some basic anti-analysis techniques; and restricts its file deletion targets to only the user’s directory, limiting its overall damage potential. However, given the second sample described by Fortinet was uploaded to VirusTotal only three days earlier, and did not include a wiper component, it appears this malware is under active development. No matter how basic the sample, it could still cause temporary disruption to a user’s day, a reminder to always be vigilant, no matter the degree of the threat.

The sample’s author uses a basic method to obfuscate strings, in which the bits in each byte of the string are reversed. Though simple, this makes the strings undetectable to casual analysis. In assembler language, this is achieved using the NOT command. The loop from the sample is shown in Figure 2, and Figure 3 shows the strings as they are stored in the binary of the sample.

String deobfuscation loop
Figure 2: String deobfuscation loop

Obfuscated strings stored in the sample
Figure 3: Obfuscated strings stored in the sample

These obfuscated strings can be deobfuscated en masse by extracting the obfuscated strings from the sample and then using a simple Python script to perform the equivalent of the NOT command, as seen below.

Python routine to deobfuscate strings
Figure 4: Python routine to deobfuscate strings

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. The exact specifics of the attack vector are not publicly known; however, the samples were discovered after they were uploaded to VirusTotal.

When/How Did BluVector Detect It?

Two samples are publicly available and BluVector’s patented Machine Learning Engine (MLE) detected both. Regression testing has shown both samples would have been detected 92 months prior to their release.

 


Variations on a Theme: Another "benign" Word macro hides Zloader

Cyber criminals continue to rapidly adapt and change to evade detection. Criminals are evading signature-based detection tools, including end-point anti-virus. McAfee reports a campaign by nefarious actors designed to distribute the Zloader trojan using another example of a benign Word macro. The attack begins with a phishing email containing a Word doc and attachment.

What Is Zloader?

 A previous Threat Report  discussed a campaign to distribute the IcedID trojan using an attack chain that began with a Microsoft Word document containing a macro, which itself contained no malicious code to evade detection. A recent report from researchers at McAfee details a campaign to distribute the Zloader trojan using a conceptually similar “benign” macro. Though the samples related to this campaign are four months older than those from the IcedID campaign. 

The attack chain is a multi-step process:

  • The target receives a phishing email containing a Microsoft Word document as an attachment.
  • If the user opens the Word document, they are presented with the expected message, advising them to enable content to view the document. This is the pre-requisite for allowing the macro to execute.
  • If the Word macro is permitted to run, it uses content from Visual Basic forms in the Word document to access a remote password protected Microsoft Excel (XLS) document. This XLS document is stored memory and not written to disk.
  • The Word macro uses content from the cells in the XLS document, to create a macro in the XLS document.
  • The Word macro then alters the Windows Registry so that no warnings will be issued for executing Office macros.
  • The Word macro then calls the macro created in the XLS document.
  • The XLS macro downloads the Zloader DLL file and executes it.

The aim of this process is to evade detection by signature-based detection tools, including endpoint anti-virus. It attempts to achieve this by breaking up the content of macros, particularly any commands which would be classed as suspicious or malicious. This content, including the URL to download the XLS document from, is stored in different locations, such as in values for combo boxes on VBA user forms. By doing this, the macro, which is stored in the Word document appears, at first glance, to contain no problematic content. Not writing the XLS document to disk is another evasion tactic.

The McAfee report describes this as a new technique, though the samples related to this campaign were first seen in late January 2021. Additionally, during research for this Threat Report, a report released by the Threat Research team at Hornetsecurity was found. This report, released in late March 2021, describes a very similar attack chain to that described here, which resulted in the downloading and execution of a Zloader DLL; however, the initial attachment was a MHTML document. This MHTML document was given a “doc” file extension, ensuring it would be opened by Microsoft Word, with the remainder of the attack chain and techniques matching those described above.

The fact these techniques are being described by research reports now, after being deployed since late January, suggests criminals are being successful at their intended purpose of signature-based detection systems. As a result, it can be expected, further variations on this theme will continue to be utilized by attackers, until they are forced to pivot to another technique to maintain the efficacy of attacks on their targets.

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. This attack leverages social engineering, as the user must be convinced to allow the macro in the attached Microsoft Word document to run, in order for this attack to be successful.

When/How Did BluVector Detect It?

Two samples are publicly available and BluVector’s patented Machine Learning Engine (MLE) detected both. Regression testing has shown the samples would have been detected for an average of 52 months prior to their release. We detect threats that others don't.


IcedID campaign uses a “benign” macro in an attempt to evade detection

Cyber criminals continue to modify the IcedID trojan attack chain to avoid detection and increase the pool of potential victims. IcedID operators have innovated their tactics to successfully defeat endpoint detection solutions. When tested, BluVector’s Machine Learning Engine (MLE) would have detected an IcedID trojan sample 47 months prior to its release.

What Is It?

The IcedID trojan was the subject of a Threat Report soon after it first surfaced in 2017. Originally, Iced ID’s primary purpose was to steal financial information, classifying it as a banking trojan. As it has evolved over time, this focus has widened to include distributing other malware as a dropper. IcedID continues to become more prolific, particularly since the success of international law enforcement’s efforts to disrupt the notorious Emotet botnet’s operations in January 2021. Throughout its life, IcedID’s authors have regularly innovated and evolved the evasion tactics they employ, to ensure the maximum number of potential victims are successfully infected.

Previous examples of this include a campaign perpetrated in May 2020, which used a somewhat predictable COVID-19 pandemic related lure, married with an attack chain that used steganographic techniques to hide malicious executable payloads inside what initially appear to be harmless Portable Network Graphics (PNG) format image files. Another campaign from April 2021 utilized malicious Microsoft Excel files containing Excel 4.0 macros, as described in another recent Threat Report relating to a Baz Loader campaign.

In this case, described in a recent report from researchers at Sentinel One, IcedID operators employed a technique that uses a Microsoft Word document containing a macro which itself contained no malicious code to evade detection, particularly by endpoint-based security tools. Many macros used in malicious documents contain suspicious commands in the code of the macro itself, or incorporate various obfuscation techniques, which again make the macro appear malicious or at the very least suspicious. Here the macro itself is very basic and uses content from the document itself, as would a legitimate macro. Sentinel One’s report doesn’t include the actual Word document; however, the BluVector Threat Team identified and reviewed a sample using the identical technique and IOC’s related to this campaign.

Word Macro

The malicious content is hidden behind an image file on the document itself which requests the user enable content so that the macro can execute. This content is actually a Microsoft HTML Application file (HTA). The macro also uses the Title value from the document’s properties to extract the destination filename for the HTA file. Once written out, the HTA file is executed. The HTA file contains JavaScript, and VBScript, to deobfuscate and execute JavaScripts to download the malicious IcedID DLL, save it with a JPG file extension, and execute it. The obfuscated JavaScripts are stored within the HTA file as base64 strings which are also reversed.

Word Content
Word Properties

The IcedID DLL is used to collect and exfiltrate sensitive data from victim’s system to the IcedID command and control (C2) site. The various tactics described above are aimed at evading endpoint detection solutions, to maximize the number of potential victims. It demonstrates IcedID’s operators continue to evolve their tactics as part of their ongoing arms race with cyber defenders and detection solutions.

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. The usual attack vector for IcedID campaigns is the use of phishing emails with malicious Office document attachments, and this was also the case for the campaign described in this report.

When/How Did BluVector Detect It?

Sentinel One’s report included a list of nearly 500 hashes for the IcedID payloads associated with this campaign. Of these, 50 were regression tested with BluVector’s patented Machine Learning Engine (MLE), which detected all of them. These samples would have been detected for an average of 78.5 months prior to their release. Additionally, although their report didn’t include any samples of the actual malicious Word documents, the BluVector Threat Team identified a sample using an identical mechanism described in the report and very likely part of the same campaign. When tested, BluVector MLE would have detected this malicious Word sample for 47 months prior to its release.


When a false positive is a true positive: Microsoft inadvertently signs a malicious driver

A driver called Netfilter, which was digitally signed as legitimate by Microsoft, was found to be malicious. Microsoft is aware and investigating as of June 26th, 2021. Currently, only gamers in China are negatively impacted. Nevertheless, this is an example of how established processes and systems designed to detect bad actors cannot be solely relied on.

What Is It?

Approximately a week ago, systems at long standing security vendor G DATA advised them of a possible false positive detection of a driver called Netfilter. The system identified this file as a possible false positive as it was digitally signed legitimately by Microsoft. Review by G DATA analysts determined it was not a false positive, the sample was in fact malicious. Microsoft were immediately informed and are still investigating; however, they have stated that it appears the driver was submitted for signing via the legitimate process.

Microsoft Windows can run code in two different modes, user mode and kernel mode, in general applications run in user mode and critical operating system code runs in kernel mode. Many drivers require kernel mode to function. Given that all kernel mode code runs together, not isolated like user mode code, any issues with kernel mode drivers can result in a system crash. Therefore, beginning with Windows Vista, Microsoft mandated that any drivers needing to run in kernel mode are required to be submitted for testing and digital signing. In the normal course of events, unsigned kernel mode drivers will not be loaded by Windows Vista and later versions of Windows.

There have been examples of private keys for code signing certificates being stolen and used to sign malware. Most famously, the Stuxnet malware which destroyed centrifuges in Iranian nuclear facilities, were signed with certificates from Taiwanese companies Realtek, and JMicron, without their knowledge. Digitally signing of software, not just drivers, is commonplace and is intended to reassure the user the software is genuine and has not been tampered with. However, despite a digital signature from Microsoft,  essentially being the top of the trust hierarchy, this case is an excellent example that the presence of a valid digital signature, is in no way the only factor to consider when determining whether a given sample is legitimate or malicious. However, to most users, a digital signature from Microsoft is a guarantee of a file’s validity, and it usually is.

After discovering the Netfilter driver sample, G DATA identified an associated dropper sample, and an older driver sample. The dropper sample is basic, placing the Netfilter driver into the user’s AppData directory and registering it with the system. The driver connects to a hardcoded Command and Control (C2) server, located in China, and receives a configuration string consisting of additional URLs used to receive further settings. The primary function of this driver is IP address redirection, a list of approximately 350 IP addresses are redirected to a single IP address located in China. The Microsoft Security Response Center (MSRC) released a blog entry stating the malicious driver distribution is limited to gamers in China and is used to “spoof their geo-location to cheat the system and play from anywhere” and “to gain an advantage in games”. The PDB path of the driver, which is used when debugging, contains two Chinese characters, which translate to “source code”, indicating it was written by a native Chinese speaker. The MSRC blog further explains an attacker would also require administrative privileges on a system prior to being able to install this driver.

There have been various supply chain breaches already this year, this is an example that there can still be issues in the legitimate supply chain process, without the direct involvement of malicious actors. It is also a reminder that whether code is digitally signed, or not, is only one factor to be considered when determining the legitimacy of a given sample - malicious code can be validly signed and unsigned code can be legitimate.

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. The malicious driver is circulating in the gaming community, in China. Aside from a dropper being identified, the attack vector is not currently known.

When/How Did BluVector Detect It?

The two Netfilter driver samples and the dropper sample referred to in the G DATA report are publicly available and BluVector’s patented Machine Learning Engine (MLE) detected them all. Regression testing has shown the samples would have been detected an average of 62 months prior to their release.


You Can't Trust Anyone - Is LV Ransomware just a pirated version of REvil?

Cyber criminals find opportunities within their own den of thieves. Recent findings published by Secureworks, suggest that REvil is being binary edited and used by LV Ransomware, for their own profit. Yes, malware creators are being exploited by other criminals, who aren’t investing resources to create a capability from scratch. LV Ransomware has figured out how to partially reverse engineer REvil’s malware, using readily available tools.

What Is LV Ransomware?

The REvil/Sodinokibi ransomware was first discussed in a Threat Report from May 2019, soon after it was first discovered. It rapidly rose to prominence as a RaaS (Ransomware-as-a-Service) offering, filling the void created by the disappearance of the GandCrab ransomware group. By some accounts, REvil ransomware is responsible for approximately 4 percent of attacks and was one of the first to utilize the tactic of leaking and selling stolen data in an attempt to increase pressure on victims to pay the ransom, a tactic now generally referred to as double extortion. In late 2020, the REvil developers claimed to be profiting to tune of over $US100 million a year, and that’s just their share, with the bulk of the profits going to the “affiliates,” the customers who utilize REvil for attacks via the RaaS offering.

Based on findings released by researchers from Secureworks, it appears that one of REvil’s rivals, LV Ransomware, may just be a pirated copy of REvil. This is a somewhat an ironic situation, of cyber criminals having their malware appropriated by another group without authorization. Adding insult to injury, it appears the theft, may not  have been too difficult to achieve. Using some reverse engineering skills and a few simple tools, including a hex editor, the LV Ransomware “authors” have replaced the encrypted configuration file, stored inside the malicious payload, itself stored inside the REvil/LV Ransomware executable. This process did not require any access to, or knowledge of, the REvil source code.

During analysis, the BluVector Threat Team performed the steps, using a publicly available LV Ransomware sample. The first step was  to unpack the malicious payload from the LV Ransomware sample. The malicious payload was encrypted and  stored in the enc section of the sample. The 32 byte key used to decrypt the payload was stored as two separate 16 byte strings in the .rdata section of the sample. The payload can be decrypted using the key and the RC4 algorithm. The payload is the actual LV Ransomware executable.

Data key used to decrypt the payload.

Decrypting the configuration file found in the payload executable is a very similar process. The .7tdlvx section contains the encrypted configuration file; the key:, a hash of the encrypted data; and the length of the configuration data. This time the key is the first 32 bytes of the .7tdlvx section. Once again, using the key and the RC4 algorithm - the configuration file, a JSON formatted text file, can be decoded. The configuration used by LV Ransomware samples contains an empty dmn entry, in REvil samples this is used to specify Command & Control (C2)sites, potentially indicating LV’s authors do not yethave a backend infrastructure mirroring REvil’s. This point adds further credence to the theory LV Ransomware is based solely on reverse engineering a REvil sample, with no visibility to other components of the full REvil infrastructure.

7tdlvx key
Config file

Once the LV Ransomware author obtained an un-encrypted copy of the configuration file following these steps, they could modify it to meet their needs. The most obvious modification being the ransom note text. Once the configuration file is modified, it’s basically the reverse process to create a functioning LV Ransomware sample. First the configuration file is encrypted using a 32 byte key, then the key, encrypted configuration hash, configuration length and the encrypted configuration are put into the .7tdlvx section. This is  a process which can be achieved using a hex editor. Then the edited payload executable itself, needs to be re-encrypted, using the key from the .rdata section. It is then placed in the enc section, within a copy of the original sample. This step, once again, can be performed using a hex editor.

LV Ransom Note

The end result is that the LV Ransomware authors now have a functioning version of REvil ransomware utilizing the configuration file they altered to their needs. As previously stated, all it took was some reverse engineering knowledge and a few tools, mainly a hex editor. However, to paraphrase the words of  Dr. Ian Malcolm in the first Jurassic Park movie, perhaps the LV Ransomware authors were too focused on whether they could have done this, rather than spending time considering if they should have done it. As mentioned, REvil ransomware is a highly lucrative enterprise and it’s developers are unlikely to take kindly to individuals, or groups, profiting from their malware. Often large scale cyber criminal operations are backed by, or directly operated by organized crime, which makes “pirating” REvil ransomware a potentially unwise undertaking, to say the least. Secureworks researchers stated they found no evidence of LV Ransomware being advertised on the usual dark web forums. Knowing thi, and the apparent lack of any LV Ransomware backend infrastructure, strongly suggest, it is a lone wolf operation. A lone wolf looking to secure a small portion of  ransomware profits for themselves.

How Does It Propagate?

The malware does not contain the necessary code to self-propagate. LV ransomware is known to use spam emails containing malicious attachments as the initial attack vector.

When/How Did BluVector Detect It?

Six samples (including one which was unpacked) are publicly available and BluVector’s patented Machine Learning Engine (MLE) detected them all. Regression testing has shown the samples would have been detected for an average of 84.5 months prior to their release.


Just the Facts: What to Look for in Cybersecurity Incident Reporting

Ransomware attacks are alarming. With increasing media coverage, here’s a guide to analyzing news stories and why you should trust BluVector when we say that our Advanced Threat Detection (ATD) could have detected a threat vector. 

So far in 2021 there have been numerous high profile cybersecurity incidents, most notably related to ransomware and supply chain compromises. The obvious examples being the incidents impacting SolarWinds, Colonial Pipeline and recently, JBS. These incidents received significant, widespread coverage in both the mainstream and cybersecurity media. This is understandable, particularly in the case of Colonial Pipeline, given its impacts were felt by millions of members of the public through disruptions to the availability of gasoline to those living in parts of the U.S. East Coast. Mainstream media coverage of cyber attacks, especially ransomware, is increasing and will continue to grow, especially given the U.S. Government’s recent acknowledgement of the national security threat posed by ransomware. 

The level of media coverage and the non-stop nature of the current news cycle brings with it an expectation in many people that all the details of a publicized attack will be immediately available. This expectation is also often held by C-level executives and boards of organizations both large and small, driven by their own, shareholders and customers desire for answers and reassurance. This frequently results in pressure being brought to bear upon cyber security professionals and vendors to provide immediate answers to their questions and concerns. These questions and concerns often require specific information relating to the cyber attack to answer accurately and completely. It should also be noted that cyber security professionals and vendors will have the same, or very similar, questions.  

However, the simple truth is, during the incident response phase of a cyber attack, specific facts relating to the attack will not be released publicly. Whether an incident is handled internally, or external parties have been engaged to assist, the specific details will be considered confidential. Incident response teams will also be focused on containment and mitigation of the attack, and obtaining further insights through forensic analysis, all of which takes time.  

In the initial stages of a cyber attack, the victim organization is unlikely to have the answers to give its own executives and board, irrespective of the amount of pressure being exerted on incident response personnel and external consultants to provide answers. Questions such as what the initial attack vector was, the full attack chain, and timeline are extremely pertinent and valid questions. But they take time, effort and resources to answer. If the victim organization and incident responders actively engaged in resolving the incident don’t possess the specifics, there is obviously no way outsiders can answer those questions either during or at the conclusion of the incident.  

Additionally, many questions may never be publicly answered with specific details. A great example is the file hashes of the malicious samples related to a cyber attack. Samples from high-profile cyber attacks are rarely publicly detailed, and it’s rarer still for them to be disclosed while the attack is ongoing. An exception to this is rapidly spreading malware attacking vast numbers of organizations simultaneously. During the voracious global spread of NotPetya in June 2017, samples were readily available while the attacks were ongoing. The lack of access to facts can lead to speculation and sweeping but unfounded statements being made by some vendors and individual “experts” who do not possess the facts to make those claims. One particularly illustrative example relates to the SolarWinds breach, where the day following the initial public announcement of the incident, there were various reports of individuals who were cold called by sales representatives claiming their product could have prevented the breach. This is an impossible claim, since there were absolutely no details regarding the specifics of the breach available at this time. Without specific samples or a complete attack chain, claims like that cannot be legitimately made.  

Claims You Can Trust 

However, with some facts publicly released by credible sources and appropriate disclaimers, statements about probabilities of detecting attacks are valid. For example, BluVector’s patented Machine Learning Engine (MLE) detected 27 recent DarkSide ransomware samples (24 Windows executables and 3 Linux executables) after news of the Colonial Pipeline attack broke. BluVector regression tested the DarkSide samplesand all were detected an average of 75 months prior to their release. This indicates there’s a very high probability BluVector ATD would have detected the Darkside ransomware used against Colonial Pipeline, although the actual DarkSide samples from the attack are not publicly available so could not be tested. 

When considering coverage of the next high-profile attack, keep in mind facts – i.e. specific details – are likely to be in short supply, especially initially. However, theories and speculation are bound to be rife. There is nothing wrong with theories, they just need to be clearly stated as such. Facts will be provided by statements from credible sources, including the victim organization, law enforcement and other government agencies. As an example, the FBI confirmed Darkside ransomware was responsible for the Colonial Pipeline incident and REvil/Sodinokibi ransomware was used against JBS. These are facts, but as an example of speculation, after the FBI’s announcement regarding Darkside, many reports referred to the “Darkside gang” being responsible. Darkside ransomware uses the RaaS (Ransomware as a Service) model, so it was most likely one of the “affiliates”, a Darkside ransomware customer, who was in fact responsible. 

Also, keep realistic expectations regarding the timeframes of facts becoming available. In the case of Colonial Pipeline, the public announcement was made by the company the day after the attack took place, two days after that the FBI confirmed Darkside ransomware was responsible. It wasn’t until 27 days after the incident actually began that it was publicly stated a compromised VPN account was used as the initial attack vector. Keep in mind, in this case it is also likely that the immediate public impact of the attack led to these timeframes being compressed compared to incidents with less visibility to the general public. 

To sum up, concerns and questions regarding high profile cyber attacks are understandable. Just be aware, publicly released facts relating to attacks are in short supply, especially early on, but theories and speculation will be widespread. 


BazaLoader campaign uses fake streaming services to evade detection 

What is it?

Cyber-criminals continue to evolve their social engineering tactics to evade corporate network detection measures and deliver malicious payloads. Proofpoint recently discovered attackers are operating a call center-like capability, where a live agent answers a call and directs victims to a fake movie streaming website. The BazaLoader campaign relies on the victim initially being contacted via phishing emails. The attackers create a sense of concern and urgency by sending messages that the victim will be charged for a subscription, resulting in the installation of the BazaLoader trojan.  

Social engineering is a concept regularly discussed in Threat Reports as a common component of successful attack chains. Attackers continue to utilize social engineering because it is effective. As with any other attack technique, social engineering tactics continually evolve, in an arms race of sorts, as defenders raise awareness of successful campaigns. Recently, Proofpoint described a novel approach used to distribute the BazaLoader trojan involving an actual person answering phone calls, redirecting victims to a fake movie streaming service website. BazaLoader was first discovered by Proofpoint in April 2020 and is used by attackers to download other malicious payloads, including some Conti and Ryuk ransomware campaigns. 

The campaign described by Proofpoint begins with potential victims receiving phishing emails claiming to relate to trial periods for streaming services expiring soon. The streaming services are all fake, using names such as BravoMovies, UrbanCinema and BOMovie, among others. The body of the phishing emails states the target’s credit cards will be charged, soon, if the subscriptions are not canceled. To this point, it sounds like a  common phishing lure, which would usually include a malicious attachment, claiming to be an invoice, bill, or account statement, etc. which the victim would be enticed to open causing a download of a malicious payload. However, in this case, the phishing emails list a phone number and advise the victim to call a customer service number, where a customer service representative will assist them  

When a victim calls  the phone number, it is answered by a human, who talks them through opening the fake streaming service’s website. The agent helps them navigate to a FAQ page where they will find a link to the subscription page, which contains an option to cancel. At first glance, the websites created for these campaigns are a reasonable facsimile of legitimate streaming sites. However, on closer inspection, they appear to be created with a generic website creator, contain grammatical and spelling errors, and list fake movies. It can be assumed that victims don’t notice the fake information, grammatical errors, etc. because they are focused on avoiding the charges.  

If the user clicks the cancel button, an Excel binary file format document (XLSB) containing a malicious Excel 4.0 macro is downloaded. Common to many Bazar Loader campaigns, this malicious document is known as CampoLoader, named for the download URL. The use of Excel 4.0 macros for malicious purposes has been growing in popularity since around February 2020. These macros are a valid Excel feature, added to the product in 1992, and are used by attackers as an evasion method.  It is important to point out that they are more cumbersome to reverse engineer than more commonly used VBA macros. From a user’s perspective, it looks like any other malicious Excel file, showing an image, requesting the enable content option to be selected, which allows the malicious macro to run. If the macro can execute, it downloads and runs the actual Bazar Loader payload. 

This is not the first time the BazaLoader attackers have used this attack chain, since January 2021, there have been several campaigns using lures other than streaming services, such as fake floral, lingerie, pharmaceutical and anti-virus organizations. What’s interesting about this attack chain is the malicious CampoLoader XLSB file is directly downloaded from a website, as is the final Bazar Loader payload. This indicates the elaborate social engineering efforts – the call center and fake streaming service websites – are being used to obviate the need to attach a malicious document to the phishing email; and therefore, evade potential detection of malicious documents in email. It could be an example of attackers adapting to many additional employees still working from home due to the pandemic. Corporate email protections still apply to remote users, however, web browsing usually goes directly from the user’s laptop to the internet, through their home network.                                                                                  

How Does BazaLoader Propagate? 

The malware does not contain the necessary code to self-propagate. This campaign relies on significant social engineering techniques to convince the user to open a malicious XLSB file, resulting in the downloading and execution of the BazaLoader malware. 

When/How Did BluVector Detect It? 

The BazaLoader sample related to this campaign was tested and BluVector patented Machine Learning Engine (MLE) detected it. Regression testing has shown the sample would have been detected 79 months prior to its release. The malicious XLSB file was also detected by BluVector MLE.