Malware C2 addresses can be an important IOC to detect known threats. In order to obtain C2 information, we first need malware samples which are then analyzed dynamically or statically. However the analysis task is often times not straightforward.  Increasingly anti-analysis methods are implemented in malware or C2 information is extracted from secondary or tertiary websites.

VMware Carbon Black Threat Analysis Unit (TAU) analyzed HYDSEVEN NetWire samples then implemented a scanner to discover active C2 servers on the Internet by emulating the customized C2 protocol. In this blog post, the latest protocol and scanner implementation are detailed for researchers and practitioners.

HYDSEVEN NetWire C2 Protocol

For background context, NetWire is a cross-platform remote access tool or trojan (RAT) for Windows/Linux/Mac and sold by World Wired Labs. In the past different threat actor groups have utilized this tool for targeted attacks, Palo Alto published a C2 protocol decoder five years ago.

The NetWire C2 protocol is TCP-based. The RAT and C2 server initially exchange an “authentication packet” including information required for the packet payload encryption. By emulating the exchange, we are able to detect active NetWire C2 servers on the Internet.

HYDSEVEN, that was named by LAC, is a threat actor targeting virtual currency exchange companies for financial motive. This actor utilizes NetWire. However, as LAC pointed out in their report, HYDSEVEN customized the C2 protocol with different data format. Additionally TAU found a completely-different algorithm for the encryption key generation which was implemented in HYDSEVEN’s NetWire. Therefore, if we obtain any correct response after sending the customized “authentication packet”, the address of the respondent is a C2 server utilized by HYDSEVEN.

The following image is the flow of the key exchange by the customized “authentication packet”.

Figure 1: HYDSEVEN NetWire key exchange

The protocol format and encryption are detailed in the following sections.

Protocol Format

The customized “authentication packet” format is below. The packet is separated into the header and payload.

The header values are well-documented in the previously referenced  LAC report. The command ID (cmd_id) 0x3 and 0x5 specify the packets are used for an initial key exchange. The ID is encoded/decoded by one byte xor on each side. The platform ID (os_id) shows the client OS environment.

There are three values in the payload of the “authentication packet.” The random_seed is used for the AES key generation, combined with the hard-coded seed (“Password”). The random_IV is IV data for the AES encryption, generated and shared by the client side. The pcap data on VirusTotal (SHA256: a2e449364b1bc148a19824984010485e2770a2f2e3098a7b59b557a59f735691) showed the random_IV from a C2 server was NULL.

Figure 2: NULL random_IV value from a C2 server

The enc_TestPacket data is utilized in the validation of the exchanged keys and encrypted from the following hard-coded binary data called TestPacket.

Figure 3: TestPacket data to be encrypted

Payload Encryption

The HYDSEVEN NetWire’s payload encryption algorithm is AES in OFB mode, that is the same as normal NetWire. However, the key generation algorithm is totally different. The SHA1 algorithm is utilized in the customized key generation.

Figure 4: AES key generation algorithm used by normal NetWire (from Palo Alto protocol decoder code)

Figure 5: AES key generation algorithm used by HYDSEVEN-customized NetWire

Scanner Implementation

VMware Carbon Black Threat Analysis Unit (TAU) initially implemented the POC scanner then continued improving it for Internet scale.

POC Scanner

While it is possible to implement the scanner based on the static code analysis result, the implementation should be validated in another way. TAU utilized the pcap data described earlier for the validation.

The pcap data contains packets generated by both the client and server sides. The POC code took the client seed and IV from the client packet (auth_send.bin) and the server seed from the server packet (auth_recv.bin) as they are random data, then it generated the entire packets including the encrypted TestPacket (gen_send.bin and gen_recv.bin). As a result, the generated packets exactly matched the data in the pcap, so TAU concluded the POC scanner worked correctly.

Scanning the Internet

TAU initially focused on port 443 for the scanning as all analyzed samples utilized the port.

The initial version of the scanner sent the customized “authentication packet” after checking if port 443 was open on the host. However port scanning for all hosts on the Internet was too expensive for the scanner to finish in a realistic window of time. Thus the second version would only send the authentication packets to hosts discovered by the MASSCAN port scanner.

While the second version scanner had run for a few months, it was not effective as the port scanning practically didn’t work. Specifically, the number of open hosts discovered by MASSCAN was much smaller than actual ones.

Table 1: MASSCAN experiment result

As shown in the above table, the discovered open hosts changed according to the packet rates. Additionally, the search results by Censys and SHODAN were about 40 and 50 million. It was unknown why the majority of open host were missed with the previous tool.

The external security researcher Tadashi Kobayashi, who published the OllyDumpEx/OllyMigrate IDA plugins, advised the bottleneck was the broadband router performing NAT. Based off of his advice, TAU prepared a Linux VM directly-connecting to the Internet through PPPoE then run ZMap (MASSCAN didn’t support the scanning option against non-Ethernet interfaces). Using this method, TAU obtained 52,128,684 hosts, with port 443 open,  from the Internet.

Result

TAU scanned against the 52 million open hosts in mid-Nov this year by sending the customized authentication packet but at the time of the scan there was no responsive C2 servers. This initial scanning result indicates a series of possibilities:

• HYDSEVEN was not active at that time or stopped utilizing the customized NetWire
• The actor have changed the hard-coded data in the NetWire samples (e.g., fixed seed and TestPacket), as new variants are used in campaigns.
• The C2 is inaccessible to IP addresses not targeted by the actor

Wrap-up

TAU analyzed the HYDSEVEN NetWire C2 protocol then implemented the scanner to discover the active C2 servers on the Internet. No active servers were found by the scanning, indicating their inactivity or change of the TTPs.

TAU also learned several takeaways for a large-scaled scanning initiative as part of this research. This knowledge will be utilized during ongoing and future C2 research projects.

Acknowledgement

For this research, TAU appreciates Tadashi Kobayashi’s insight and advice. Kobayashi provided tactics for different port scanning strategies and the implementation details to identify the issues in MASSCAN and ZMap.

Indicators of Compromise (IOCs)