Tuesday, August 11, 2015

MMD-0038-2015 - ChinaZ and ddos123.xyz

Background

Sorry to keep on saying this, previous posts about ChinaZ are in [-1-] [-2-]. A loy of effort was done to this threat, we grabbed its builder in some CNC we spotted, and we also PoC "a suspected" coder of the ChinaZ malware turned out to be high-schooler 3rd grade in his effort of improving source code of ChinaZ in GitHub DDoSClient repository early in this year, but it seems the real actors is still out there continuing his malicious scheme. And this post is having information that may lead to him.

As team, we must say this post is not so technical, but more to the investigation of one of ChinaZ suspected bad actor, so our apology for some of you may not be interested to read this topic. We also know that many of security folks don't agree on pointing out a suspect in cyber crime for the OPSEC purpose.

However. the information posted here was passed to the authorities and enforcement for more than 10days by now. And the information contains many useful threat indicators that can be used by security entity to mitigate or blocking the infrastructure used, or for the good people in PRC can trace the threat deeper, which are reasons to share it too as per it is.

Infection and malware CNC analysis result

It is (always) started from the HFS panel with the infection distribution of the shellshock. Below is the panel, and the shellshock method is as per previously posted cases detail, nothing new. Thank's @benkow for the information sharing.

The two samples of the ChinaZ are the focus of this post, a pair of the same codes of 32 and 64bit version. Our team mate uploaded and tagged those in virus total in [-1-] and [-2-].

From this part, since the post may be sensitive and may raise conflict in interest, I hereby inform that I am to be personally responsible for what had been investigated and had posted here, not my team.

The binaries are obviously ChinaZ, and it was a bit surprising to know that the sample is still actively communicate to its CNC as per recent tests:

// DNS connection
connect(1, {sa_family=AF_INET, 
            sin_port=htons(53), 
            sin_addr=inet_addr("$DNS")}, 16)
// DNS query formed & replied:
send(1, "\235\210\1\0\0\1\0\0\0\0\0\0\3www\7ddos123\3xyz\0\0\1\0"..., )
recvfrom(1, "\235\210\201\200\0\1\0\1\0\2\0\2\3www\7ddos123\3xyz\0\0\1\0"..., 
// send cnc a mesg used resolved addr..
connect(0, { sa_family=AF_INET, 
             sin_port=htons("29135"), 
             sin_addr=inet_addr("42.51.156.201")}
// Noted this typical ChinaZ msg..
write(2, "Connect:: Operation now in progress"...,)

A curiosity for this CNC authentication made me check it further into socket level to its IP:socket..

// connection trace
TCP MMD.SMACKS.CHINAZ.:43708->42.51.156.201:29135 (ESTABLISHED)
// socket test as CNC PoC...
[42.51.156.201] 29135 (?) open
Connection to 42.51.156.201 29135 port [tcp/*] succeeded!
d
we have a what seems to be alive and actively responding CNC here. But let's not jump into any conclusion before seeing the next sections..

The origin analysis and validity

The DNS request shows a query to a hostname of www.ddos123.xyz and is registered in current DNS record as:

;; ANSWER SECTION:
www.ddos123.xyz.        2518    IN      A       42.51.156.201
;; AUTHORITY SECTION:
ddos123.xyz.            2517    IN      NS      ns1.72dns.com.
ddos123.xyz.            2517    IN      NS      ns2.idc1.cn.
;; ADDITIONAL SECTION:
ns1.72dns.com.          1808    IN      A       101.226.167.174
Just to be sure, I search by RRset mode to find range of activity of the suspected domain, and the result shows it wasn't sinkhole and under origin of the registrant as per initially registered.
bailiwick xyz.
count 60
first seen 2015-03-12 07:26:22 -0000
last seen 2015-08-03 07:42:07 -0000
ddos123.xyz. NS ns2.idc1.cn.
ddos123.xyz. NS ns1.72dns.com.
We must admit it is a kind of weird for ddoser actor's used hostname showing "ddos" keyword, it's too blatant, isn't it? I mean what would you think to see a CNC of backdoor/ddoser ELF malware with hostname as www.ddos123.xyz? But since the checks are solidly explained and DNSDB records + DNS records implies the initial sate unchanged, showing a full control of the domain from whoever actor who set it up as CNC calls, it makes some senses. But let's also check this a bit further..

The CNC hostname, is in 42.51.156.201. The local internet service stated the origin of the IP is in below written area:

河南省郑州市 
河南电联通信技术有限公司
And matched to my custom GeoIP API that is pointing to:
  "ip": "42.51.156.201",
  "hostname": " htuidc.bgp.ip",
  "city": "Zhengzhou",
  "region": "Henan",
  "country": "CN",
  "loc": "34.6836,113.5325",
  "routes": "42.51.128.0/17",
  "org": "AS56005 Henan Telcom Union Technology Co., LTD"
It's a node in network in Zhengzhou city of Henan, prefecture in the People Republic of China (PRC) country, and, again, comparing the network to several sinkhole database and it doesn't match to any sinkhole nodes too, so we are positive to see an alive CNC in that area, with noted, it is in a hardline IP address.

The interesting part is, the hostname (the www pointer) www.ddos123.xyz and domain (the "@" pointer) ddos123.xyz are not pointing to the same IP. I.e. the ddos123.xyz is with A record in 43.249.11.171:

;; ANSWER SECTION:
ddos123.xyz.            3600    IN      A       "43.249.11.171"
;; AUTHORITY SECTION:
ddos123.xyz.            3600    IN      NS      ns1.72dns.com.
ddos123.xyz.            3600    IN      NS      ns2.idc1.cn.
;; ADDITIONAL SECTION:
ns1.72dns.com.          600     IN      A       101.226.167.174
Which is served in a VPS in the very different location and service under this BGP [link] info..
  "ip": "43.249.11.171",
  "hostname": "No Hostname",
  "city": "Qingdao",
  "region": "Shandong",
  "country": "CN",
  "loc": "36.0986,120.3719",
  "org": "AS62468 VpsQuan L.L.C."
This also implies that the actor doesn't want to link the domain to the its usage as CNC hostname, but it is not eliminating the previous result that it has the full control to make domain's record arrangement so far, unless we can proof the domain was hacked or hijacked (checked that too so far and the result is likely not).

The registration and some information

Now we can assume to have a valid data: the ddos123.xyz internet domain name belongs to the actor. let's find out who is responsible for this domain's arrangement.

The registration investigation came up with a contact email address of 130128628@qq.com, and additionally linked to below registered domains the in the internet:

zhmr.org 
ddos123.xyz  
ddoscc.xyz
It is interesting to know the keyword "ddos" was used to more than one domain. And the usage of the .XYZ domain is reminding me to the previous takedown 103 domains that was being used by ChinaZ in different case..a relation?
OK, checking further..each domain was registered in the "same way" too, please see how registration was written as per below snipped WHOIS record:
Domain Name:ZHMR.ORG
Domain ID: D173189409-LROR
Creation Date: 2014-07-04T07:27:48Z
Updated Date: 2015-07-05T01:32:50Z
Registry Expiry Date: 2016-07-04T07:27:48Z
Sponsoring Registrar:PDR Ltd. d/b/a PublicDomainRegistry.com (R27-LROR)
Sponsoring Registrar IANA ID: 303
WHOIS Server:
Referral URL:
Domain Status: clientTransferProhibited -- http://www.icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod -- http://www.icann.org/epp#autoRenewPeriod
Registrant ID:DI_37377779
Registrant Name:"hu lu"
Registrant Organization:"hu lu"
Registrant Street: beijingxinchengshishi
Registrant City:xincheng
Registrant State/Province:Beijing
Registrant Postal Code:071800
Registrant Country:CN
Registrant Phone:+86.5555555
Registrant Phone Ext:
Registrant Fax: +86.5555555
Registrant Fax Ext:
Registrant Email:"130128628@qq.com"

Domain Name: DDOS123.XYZ
Domain ID: D7151240-CNIC
WHOIS Server: whois.72dns.com
Referral URL: http://www.72e.net
Updated Date: 2015-06-25T09:27:23.0Z
Creation Date: 2015-03-12T10:27:23.0Z
Registry Expiry Date: 2016-03-12T23:59:59.0Z
Sponsoring Registrar: Foshan YiDong Network Co.LTD
Sponsoring Registrar IANA ID: 1563
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Registrant ID: pi68yf15rg63o3zq
Registrant Name: "wo wo"
Registrant Organization: "wo wo"
Registrant Street: beijingbeijingbeijing
Registrant City: beijing
Registrant State/Province: beijing
Registrant Postal Code: 000101
Registrant Country: CN
Registrant Phone: +86.105801000
Registrant Phone Ext:
Registrant Fax: +86.15121231
Registrant Fax Ext:
Registrant Email: "130128628@qq.com"

Domain Name: DDOSCC.XYZ
Domain ID: D7465669-CNIC
WHOIS Server: whois.72dns.com
Referral URL: http://www.72e.net
Updated Date: 2015-06-25T09:27:24.0Z
Creation Date: 2015-04-06T10:27:24.0Z
Registry Expiry Date: 2016-04-06T23:59:59.0Z
Sponsoring Registrar: Foshan YiDong Network Co.LTD
Sponsoring Registrar IANA ID: 1563
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Registrant ID: 2lkqa4quhzht2pcg
Registrant Name: "wo wo"
Registrant Organization: "wo wo"
Registrant Street: beijingbeijingbeijing
Registrant City: beijing
Registrant State/Province: beijing
Registrant Postal Code: 000101
Registrant Country: CN
Registrant Phone: +86.105801000
Registrant Phone Ext:
Registrant Fax: +86.15121231
Registrant Fax Ext:
Registrant Email: "130128628@qq.com"
We can see some attempts to "fake" whois information up there. Made those look suspicious. Seeking more malicious record linked to these domains might lead us to something else, but I will focus to the case we ChinaZ CNC verdict in hand..

After some searching in the internet, it was recorded the QQ account was used in a bulletin board with this profile [link] as a contact information. Below is the screenshots and please noted that I am not accusing anyone with anything (yet) here.

This was a posted in December 2014, a request on searching for a source [link]..

He was seeking solution for Linux related problem [link]

interesting tweet discussion regarding to the message posted by the suspected actor:

was suggesting the actor's effort in seeking for Linux malware..

We have internal discussion about posting or not posting this information, but considering only very few people can seek this far, it would be better to post it for other can take a lead for the further step/approach to stop the actor. All of the information was reported, and we will leave to the law enforcement for the next steps..

Epilogue

Good people were collaborated to takedown the used CNC domains:

The moral of the story is, even if you don't see the other users in real life via internet, it doesn't mean you can abuse them or any machines online and make illegal money by badly utilizing it. It is bad, and every badness in life will come back to you, eventually.

Sample is shared in kernelmode [link]

#MalwareMustDie

No comments:

Post a Comment