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–
Figure 1 –
Figure 2 –
Figure 3 –
Figure 4 –
No matches found.
This file is a malicious 32-bit Windows DLL. Static analysis indicates this application is very similar in structure and function to C6F78AD187C365D117CACBEE140F6230. However, rather than being a PE32 executable this application is a Windows 32-bit DLL, which must be loaded by an external loader. This external loader was not included within this submission.
This DLL is designed to force a compromised system to act as a proxy server. This implant is designed to proxy network traffic from an operator to another software tool that is being operated by the adversary on a remote system. The traffic to and from this proxy server will be protected with the same simple XOR / ADD cipher used by the malware C6F78AD187C365D117CACBEE140F6230. Static analysis indicates sessions from the remote operator connecting directly to this implant will be protected via SSL / TLS, however the proxy sessions to the remote systems will not be protected via TLS but will instead use a “fake TLS” session. The traffic from the operator to this implant and traffic from the implant to the remote systems will be protected via the embedded XOR / ADD cipher (view screenshot). To implement SSL with the remote operator, the malware loads a private key from a file named ‘wbemhost.dll’ and a certificate from a file named ‘netconf.dll’. This malware does not drop either of these files (see Figure. 7).
Analysis of this malware indicates it is designed to bind to and listen for incoming connections to the victim’s system after disabling the firewall by modifying the following registry key. The firewall is disabled by allowing incoming access on port 443.
–Begin Firewall Reg Key Modified–
–End Firewall Reg Key Modified–
After connecting to this malware, the operator must issue the challenge value “qwertyuiop” to authenticate with the implant (see Figure 5). This malware also has the added capability of allowing an operator to collect information about the compromised system. This information is collected using the Windows APIs GetComputerNameW, gethostbyname, and GetAdaptersInfo. In order to use this feature, the operator must issue the instruction value “ghfghjuyufgdgftr” after authenticating. As with C6F78AD187C365D117CACBEE140F6230, this malware uses the OpenSLL functions ssl_read() and ssl_write() to exchange data with the operator, however the malware additionally uses a simple XOR cipher (as earlier described) to decrypt incoming traffic.
Analysis indicates this malware must also authenticate with the destination server to which the operator wishes to proxy traffic. To do so, this malware first sends that remote server the challenge value “1qazXSDC23we.” The malware must then receive the following response from the destination server before it will allow the operator to proxy traffic to it: “m*^&^ghfge4wer” (see Figure 6). The authentication values sent to and from this proxy server will be protected via the same XOR / ADD cipher utilized by the malware C6F78AD187C365D117CACBEE140F6230 (see Figures 8-9).
The following is a list of the domains for which the malware contains public SSL certificates, used for initiating the “FAKE TLS” sessions:
–Begin SSL cert list–
–End SSL cert list–