This report is provided "as is" for informational purposes only. The Department of Homeland Security (DHS) does not provide any warranties of any kind regarding any information contained herein. The DHS does not endorse any commercial product or service referenced in this bulletin or otherwise.
This document is marked TLP:WHITE--Disclosure is not limited. Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol (TLP), see http://www.us-cert.gov/tlp.
This Malware Analysis Report (MAR) is the result of analytic efforts between the Department of Homeland Security (DHS), the Federal Bureau of Investigation (FBI), and the Department of Defense (DoD). Working with U.S. Government partners, DHS, FBI, and DoD identified Remote Access Tool (RAT) malware variants used by the North Korean government. This malware variant has been identified as FASTCASH for Windows. The U.S. Government refers to malicious cyber activity by the North Korean government as HIDDEN COBRA. For more information on HIDDEN COBRA activity, visit https[:]//www[.]us-cert.gov/hiddencobra.
FBI has high confidence that HIDDEN COBRA actors are using malware variants in conjunction with proxy servers to maintain a presence on victim networks and to further network exploitation. DHS, FBI, and DoD are distributing this MAR to enable network defense and reduce exposure to North Korean government malicious cyber activity.
This MAR includes malware descriptions related to HIDDEN COBRA, suggested response actions and recommended mitigation techniques. Users or administrators should flag activity associated with the malware and report the activity to the Cybersecurity and Infrastructure Security Agency (CISA) or the FBI Cyber Watch (CyWatch), and give the activity the highest priority for enhanced mitigation.
This submission included two unique files. The first file is a malicious application, which can be utilized to inject a dynamic link library (DLL) into a remote Windows process. The second file is a malicious Windows DLL. The DLL contains two functions that can hook callbacks to the Windows application programming interfaces (APIs) "Send" and "Recv" within a targeted process. These hook functions are utilized to intercept traffic received by the target process. In received Financial Messages, the malicious functions will look for targeted Primary Account Numbers (PAN) to deliver a custom response. It appears the malware will target a system on a bank infrastructure, which is designed to process automated teller machine (ATM) transactions.
This updated report included an additional sample that is used by advanced persistent threat (APT) cyber actors in the targeting of banking payment systems. The sample is a man-in-the-middle bank transaction modification malware. Once the malware is injected into an executable, it takes control of the send and receive functions in order to identify, log, and modify ISO 8583 messages. ISO 8583 is an international standard for financial transaction card originated interchanged messaging. This functionality enables the actor to withdraw more money than is actually available. The malware specifically targets ISO 8583 Point of Sale (POS) system messages, ATM transaction requests, and ATM balance inquiries. The sample uses code from open source repositories on the Internet and modifies the parsing code to support Extended Binary Coded Decimal Interchange Code (EBCDIC) encoding. EBCDIC is a character encoding format like the more commonly ASCII.
For a downloadable copy of IOCs, see MAR-10257062-1.v2.stix.
Submitted Files (3)
|Type||PE32 executable (DLL) (console) Intel 80386, for MS Windows|
|ESET||a variant of Win32/NukeSped.GA trojan|
|K7||Riskware ( 0040eff71 )|
|TrendMicro House Call||Backdoo.62DC2502|
- rule CISA_10257062_01 : ATM_Malware
Author = "CISA Code & Media Analysis"
Incident = "10257062"
Date = "2019-09-26"
Last_Modified = "20200117_1732"
Actor = "n/a"
Category = "Financial"
Family = "ATM_Malware"
Description = "n/a"
MD5_1 = "c4141ee8e9594511f528862519480d36"
SHA256_1 = "129b8825eaf61dcc2321aad7b84632233fa4bbc7e24bdf123b507157353930f0"
$x3 = "RECV SOCK= 0x%p, BUF= 0x%p, LEN= 0x%08X, RET= %08X, IP= %s, Port= %d" fullword ascii
$x4 = "init_hashmap succ" fullword ascii
$x5 = "89*(w8y92r3y9*yI2H28Y9(*y3@*" fullword ascii
($x3) and ($x4) and ($x5)
No matches found.
|Compile Date||2019-06-22 01:59:31-04:00|
|Microsoft Visual C++ DLL *sign by CodeRipper|
This file is a malicious Windows 32-bit DLL. Upon execution, it attempts to read the file "c:\\temp\info.dat". Analysis of this implant indicates the encrypted file "info.dat" will contain targeted PAN numbers, which are expected to be contained within transactions possibly originating from ATM systems. Analysis indicates the malware decrypts "info.dat" utilizing what appears to be the AES encryption algorithm. The key utilized for this decryption is displayed below:
--Begin Decryption Key--
--End Decryption Key--
The decrypted contents of "info.dat" are then parsed. Sub-components of the file are then further decoded using a hard-coded rotating XOR cipher (Figure 1). The data used as the rotating XOR cipher key is displayed below:
--Begin Rotating XOR Cipher Key--
--End Rotating XOR Cipher Key--
This application will not run without the file "info.dat", which was not available at the time of analysis.
Upon execution, the malware creates the directory "C:\tmp\_DMP". The malware will use this location as a working directory on the targeted system. The malware will store run time logs within this folder. When executed, the malware will create a log file with the following file name format "c:\\tmp\\_DMP\\TMPL_%d_%d.tmp" in this folder and stamps it with the data "HK-Start".
This binary contains two functions, which provides context to the malware's purpose and capability. Analysis indicates this DLL is injected into a targeted process. In order to capture and analyze incoming network traffic, the malware hooks the "Send" and "Recv" Windows API within a targeted process. One of these functions, located at offset "0x00004f60", appears to search for incoming network traffic for "x200" Financial Request Messages, such as the type that may be generated from an ATM banking system. When the malware captures data it uses the "getpeername" API to get the IP address of the connected host. It then converts this IP address to integer value using the "ntohs API". If the integer value of the IP address matches either "16843029" or "33620245" the malware will search it for a "Financial Request Message" (Figure 6). If not, it will process the incoming data as normal, however it still attempts to log it to a file named "c:\\tmp\\_DMP\\TMPL_%d_%d.tmp" in the format RECV SOCK= 0x%p, BUF= 0x%p, LEN= 0x%08X, RET= %08X, IP= %s, Port=.
Upon receipt of one of these Financial Request Messages, this structure will create a log file that is named with the following format: "c:\\tmp\\_DMP\\TMPL_%d_%d.tmp". The format of the data logged in this log file will be as follows:
--Begin Logged Message Data--
Message(msg=%d, ct=%d, pc=%d, sd=%d, pan=%s, date=%s)
--End Logged Message Data--
Upon receipt of a Financial Request Message the malware will decode a portion of the data, which was AES decrypted from the file “info.dat” to see if portions of it match the incoming Financial Request Message (Figure 3). Although the file “info.dat” was not available for analysis, it appears the malware is ensuring the PAN numbers of the incoming message match one of the PAN numbers contained within “info.dat”.
Static analysis indicates the malware utilizes an encrypted file named “blk.dat”. This file is expected to contain a denylist of ATM transactions, which will be denied by the hook function (Figure 2). This file was not available for analysis.
When the malware receives a request from an ATM, if it contains a PAN number configured in info.dat (Figure 3) and it is not on the denylist in “blk.dat”, the malware will craft a response and send it to the ATM system (Figure 4). It appears the response to the ATM will allow the transaction to proceed and potentially allow the hackers to illegally withdraw money. If the transaction is hijacked and approved, the malware records this success in the encrypted log file “suc.dat”.
If the transaction is rejected, because it is on the denylist in “blk.dat”, this error is logged to the file “err.dat”. If the transaction does not contain a configured PAN or a transaction on the denylist, the malware will pass it on as normal to the targeted application. When the malware receives an identified Financial Request Message, it will log it to a file with the name format "c:\\tmp\\_DMP\\TMPL_%d_%d.tmp". The message itself will be logged into this file with the format “Message(msg=%d, ct=%d, pc=%d, sd=%d, pan=%s, date=%s)”.
The actual response back to the ATM system will be logged into a file with the filename format "c:\\tmp\\_DMP\\TMPL_%d_%d.tmp". The format of the data written to this file will be send socket=0x%X, ret=%d, err=%d.
Analysis indicates the Send API is hooked with a function that uses the "getpeername" IP address of the connected host. The IP address of the host is converted using “ntohs” and if it matches one of the values “16843029” or “33620245” the sent traffic will be logged in a file named "c:\\tmp\\_DMP\\TMPL_%d_%d.tmp". The format of the sent data logged is SEND SOCK= 0x%p, BUF= 0x%p, LEN= 0x%08X, RET= %08X, IP= %s, Port= (Figure 7). Static analysis indicates successful hooks made to the “Send” and “Recv” APIs within the target process will be logged in a file named “c:\\tmp\\_DMP\\TMPL_%d_%d.tmp” with the format “g_hook_flag = %d”.
Figure 1 - Cipher used when decoding data in "info.dat".
Figure 2 - API "Recv" hook checking for incoming Financial Request Message for a targeted PAN.
Figure 3 - The malware searching for targeted PANs.
Figure 4 - Malware crafting and sending responses to the ATM.
Figure 5 - Hook function either searching network traffic for Financial Message or logging it and sending to the "RECV" API.