Original release date: September 9, 2019
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 Trojan malware variants used by the North Korean government – referred to by the U.S. Government as BADCALL. 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, report the activity to the DHS National Cybersecurity and Communications Integration Center (NCCIC) or the FBI Cyber Watch (CyWatch), and give the activity the highest priority for enhanced mitigation.
This report provides analysis of four (4) malicious executable files. The first three (3) files are 32-bit Windows executables that function as proxy servers and implement a “Fake TLS” method similar to the behavior described in a previously published NCCIC report, MAR-10135536-B. The fourth file is an Android Package Kit (APK) file designed to run on Android platforms as a fully functioning Remote Access Tool (RAT).
For a downloadable copy of IOCs, see:
Submitted Files (4)
Additional Files (2)
No matches found.
This file is a malicious 32-bit Windows executable. Analysis indicates this application is designed to force a compromised system to function as a proxy server. When executed, the malware binds and listens for incoming connections on port 8000 of the compromised system. The proxy session traffic is protected by way of a simple cipher based on rotating XOR and ADD. The cipher will XOR each byte sent with 47h and added by 28h. Each byte received by the malware will be XOR’ed by 47h and subtracted by 28h. See Figures 1, 2 and 3 for code examples. Notably, this malware attempts to disable the Windows firewall before binding to port 8000 by modifying the following registry key:
–Begin Firewall Reg Key Modified–
–End Firewall Reg Key Modified–
Analysis of this malware indicates it is designed to turn a victim host into a “hop point” by relaying traffic to a remote system. When the adversary initially connects to a victim’s machine via port 8000, the adversary must first authenticate (over a session secured with the XOR/ADD cipher described above) by providing the ASCII string “1qazXSDC23we”. If the malware does not receive this value, it will terminate the session, responding with the value “m*^&^ghfge4wer”.
If the operator authenticates successfully, they can then issue the command “ghfghjuyufgdgftr” which instructs the malware to begin functioning as a proxy server and respond to the operator with the value “q45tyu6hgvhi7^%$sdf”. Next, the malware attempts to create a proxy session between the operator and another server. During this process, the malware will attempt to authenticate with the destination server by sending the value “ghfghjuyufgdgftr” as a challenge. To complete the authentication sequence, the malware expects to receive a response value of “q45tyu6hgvhi7^%$sdf”. All challenge and response traffic is encoded using the ADD/XOR cipher described earlier.
The proxy session begins with a remote operator connecting to this implant via a “fake TLS” connection attempt, similar to the behavior described in a previously released NCCIC report, MAR-10135536-B. Essentially, the malware initiates the TLS session using one of several public SSL certificates obtained from well known, legitimate internet services and embedded in the malware. However, the traffic from the operator to this implant is not protected with SSL / TLS encryption. The traffic is only protected via the ADD/XOR cipher embedded within this implant (see Figure 2-3.). If the remote operator authenticates correctly as detailed above, the implant attempts to begin a proxy session with the remote target system. The traffic to the remote systems from this implant are sent and received via the SSL_read and SSL_write APIs available in OpenSSL. However, the malware does not appear to attempt to load an SSL private key or certificate.
The malware contains public SSL certificates for the following list of domains, which are used for initiating the “fake TLS” session:
–Begin SSL Certificate Strings–
–End SSL Certificate Strings–