Threat Intel | Web Crew

15 June 2015

It's been a while since I've done a threat intel piece, so I wanted to put together a new one to show off some new methods and tips. This piece is called Web Crew due to the names of some malware they were hosting on some of their servers. So, let's get to it!

Discovery

I started my search for new work by firing up Threat Inc.'s Tango app to see if there was anything new and exciting going on, on our honeypots. There's always usually something happening, so I just grabbed one incident that seemed pretty active at the time.

I started looking at this incident, since there were three sessions, all originating from the same attacker, going to two different honeypots in a short amount of time. The attacker in this case was 61.174.49.51, an IP based out of China. So, let's start digging...

Initial Investigation

I noticed that in each of the three sessions, the attacker was doing different things in each. For example, in the first session, 06/11/2015 14:07:02, he ran about 10 commands, whereas the other two sessions, 06/11/2015 14:11:14 and 06/11/2015 14:29:01 he ran 3 and 8 respectively. Also peculiar is the fact that in the first session he was grabbing the malware from a completly different domain, hxxp://183.60.223.169:8889, as opposed to the other two sessions where they reached out to hxxp://61.174.49.51:6664. At the time of the my investgation, the 183.60.223.169 domain was down, however, the files seemed to be similar to the ones hosted on the 61.174.49.51 address, with names such as www2.6, www2.4, wwwarm, wwwwrt indicating malware designged for various architectures.

61.174.49.51

Checking out the webserver for this address on port 6664 turns up the typical HFS server, however, surprisingly it was in Chinese. There are a few files being hosted on this server, most of which were being requested in the sessions seen in Tango.

For the three original sessions I started looking at, I noticed requests for files from that server that looked something like kkk_.htm (kkk_3.htm, kkk_4.htm, etc.) and one for KKK.htm. Most of the files hosted were of varying filesize, so, they are probably malware built for various architectures like the ones on the 183 domain.

Here's the Whois information for the host:

inetnum: 61.174.48.0 - 61.174.49.255
netname: HANGZHOU-SRT-TECHNOLOGY-CO-LTD
country: CN
descr: HANGZHOU SRT TECHNOLOGY CO., LTD
descr:
admin-c: BB324-AP
tech-c: CH119-AP
mnt-irt: IRT-CHINANET-ZJ
status: ASSIGNED NON-PORTABLE
changed: zjnoc_ip_1@163.com 20120730
mnt-by: MAINT-CN-CHINANET-ZJ-HU
source: APNIC

![https://i.imgur.com/CW9voCH.png](https://i.imgur.com/CW9voCH.png)

All three sessions lasted under 3 seconds each, and the attacker was seen using two different SSH clients, SSH-2.0-PuTTY_Local:_May_14_2009_21:12:18 and SSH-2.0-libssh2_1.4.3. We also have sessions from this host going back to June 2nd, with the latest attack being the 6/11/15 14:29:01 session.

If we wanted to build a timeline of events for this host, we can run a Splunk query like this:

Trying to build a timeline of their attack history, we can run a search like this in our Splunk logs:

sourcetype=kippojson  [ search sourcetype=kippojson src_ip="61.174.49.51"
| stats count by session | fields session ]
| transaction session | search shasum=*
| stats count by url, _time

The above will give us all the URL's they attempted to download malware from, as well as the time they tried to download the malware.

Besides the two IP's we've found so far, if we go back to the 2nd of June, where the first attack happened from this host, we can see the attacker attempting to download malware from hxxp://222.186.21.103:10086, with the two files being:

hxxp://61.174.49.51:8088/mf222
hxxp://61.174.49.51:9999/sssssa

Again, at the time of my investigation, this domain was offline.

The attacker waited a few days, then started back up again on the 8th, using the 61.174.49.51 domain for hosting the malware they tried to grab. There were 2 sessions on the 8th, grabbing the following files:

hxxp://61.174.49.51:8088/mf222
hxxp://61.174.49.51:9999/sssssa

Throughout 9th, 10th, and 11th of June, they switched between both malware domains (61.174.49.51 and 222.186.21.103), both hosting files using the .htm extension.

File Analysis

Next, let's look at the files being downloaded on the honeypots. There's definitely overlap in the files, since it seems a lot of the files produce the same hash, even for ones which would look like they are for different architectures. In total, there are 13 different hashes being produced, for 41 different URLs.

Knowing all the different file hashes of this malware, I then looked at if anyone else was downloading these files. Turns out there were three total attackers:

61.174.49.51
222.186.21.103
183.60.223.169

![https://i.imgur.com/EfPh7E6.png](https://i.imgur.com/EfPh7E6.png)

One thing to note, they were all grabbing the malware from each of the IP's we know about (ex. 61.174.49.51 grabbing malware from each of the other two IP's, and the same for each other IP).

Let's take a look at the other hosts involved...

183.60.223.169

Again, this IP was located in China and had the following Whois data:

inetnum: 183.0.0.0 - 183.63.255.255
netname: CHINANET-GD
descr: CHINANET Guangdong province network
descr: Data Communication Division
descr: China Telecom
country: CN
admin-c: IC83-AP
tech-c: IC83-AP
status: ALLOCATED PORTABLE
remarks: service provider
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
remarks: This object can only be updated by APNIC hostmasters.
remarks: To update this object, please contact APNIC
remarks: hostmasters and include your organisation's account
remarks: name in the subject line.
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
changed: hm-changed@apnic.net 20091009
mnt-by: APNIC-HM
mnt-lower: MAINT-CHINANET-GD
source: APNIC

![https://i.imgur.com/zbyWCVY.png](https://i.imgur.com/zbyWCVY.png)

This host also used the same two SSH clients as our first IP:

SSH-2.0-PuTTY_Local:_May_14_2009_21:12:18
SSH-2.0-libssh2_1.4.3

Looking through the sessions that this host was seen in, we were able to acquire a new indicator, which was mjg.f3322.org. They were seen attempting to download the file User2.htm from mjg.f3322.org on port 8888.

Using the site detux.org, we were able to see that this domain resolved to 61.174.49.51, which was our first indicator and our initial IP we started investigating, what a coincidence! More information can be found here.

This host was seen attempting to grab malware from the f3322.org domain (which resolved to the 61.174.49.51 host at the time), as well as their own IP.

222.186.21.103

Next up on our list is the 222.186.21.103 host, which again, was located in China.

inetnum: 222.184.0.0 - 222.191.255.255
netname: CHINANET-JS
descr: CHINANET jiangsu province network
descr: China Telecom
descr: A12,Xin-Jie-Kou-Wai Street
descr: Beijing 100088
country: CN
admin-c: CH93-AP
tech-c: CJ186-AP
mnt-by: APNIC-HM
mnt-lower: MAINT-CHINANET-JS
mnt-routes: MAINT-CHINANET-JS
remarks: This object can only modify by APNIC hostmaster
remarks: If you wish to modify this object details please
remarks: send email to hostmaster@apnic.net with your
remarks: organisation account name in the subject line.
changed: hm-changed@apnic.net 20040223
status: ALLOCATED PORTABLE

This host was seen a lot earlier than the other two, with attacks dating back to 03/02/2015. We also noted some more SSH clients in use:

SSH-2.0-PuTTY_Local:_May_14_2009_21:12:18
SSH-2.0-libssh2_1.4.3
SSH-2.0-libssh2_1.4.2
SSH-2.0-paramiko_1.8.1

One thing to note about all our attackers so far, is, while some of the sessions vary by activity and time, they all seem to use SSH libraries to connect to our honeypots, which are a good indicator that these hosts are bots and not manually controlled. libssh is a common used SSH library, and Paramiko is a "Native Python SSHv2 protocol library", meaning these are definitely scripts doing the work for them.

mjg.f3322.org

Using passivetotal, we can see the mjg.f3322.org domain resolved to 183.60.233.169 on 06-11-2015. So, this tells us they've switched the DNS records for this domain at some point, since it resolved to the 183.60.233.169 host, and the 61.174.49.51 host. As of right now, this domain still resolves to the 183.60.233.169 host.

I checked out the registrar details for this domain and pulled back the following:

Email ppyy@astpbx.com (a,t,r)
Name peng yong (a,t,r)
Organization Bitcomm ltd. (a,t,r)
Street yinyuan building (a,t,r)
City changzhou (a,t,r)
State Jiangsu (a,t,r)
Postal 213002 (a,t,r)
Country CN (a,t,r)
Phone 8651968887168 (a,t,r)
Fax 8651968887169 (a,t,r)

Indicator Analysis

Utilizing virustotal, I searched for all four of our attackers/domains:

61.174.49.51 previously resolved to lengker.com on 12-13-2014
No Further Information (NFI) on 222.186.21.103
183.60.233.169 resolved to mjg.f3322.org on 6-12-15 and to tgmmh.com on 10-27-13

Nothing of value could be gleaned from the WHOIS of tgmmh.com except for the registrar: BEIJING INNOVATIVE LINKAGE TECHNOLOGY LTD. DBA DNS.COM.CN

With what we know right now, we can almost say with a fact, that all three of these IP's and one domain are all related to the same actor/group of actors operating out of China.

One quick note, the best thing about all the work done so far has all been passive research, we haven't even touched their actual infrastructure, which is great. I will make a note here though, that before we continue, we may not have all the malware samples from each of these sites. That's where TOR/proxychains can come into play.

Since we'd want to grab all their malware, we don't want to give up who we are by browsing their sites (although I'm sure they wouldn't notice...). Anyways, we can fire up the TOR browser bundle and hit up our command line with something like:

proxychains4 wget -r https://<badguyip>:<port>

The above will use TOR to mask our source IP and grab all the files hosted on the sites we've seen above. If we can't do passive, we might as well be sneaky as possible...

Now that we have a good baseline of our attackers, we can start digging more into the malware to see it's purpose and to possibly glean any more useful information from the malware.

Malware Analysis

Alright, let's start looking at our files, first let's see what type of files we're dealing with:

brian@nullsecure ~/Desktop/61.174.49.51:6664 > file *
123.rar:   RAR archive data, v1d, os: Win32
KKK_htm:   ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, stripped
KKSS.rh:   ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped
kkk_3.htm: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, stripped
kkk_4.htm: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped
kkk_6.htm: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped
rrrr.1:    ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped

Now let's get their hashes:

brian@nullsecure ~/Desktop/61.174.49.51:6664 > md5 *
MD5 (123.rar) = 040e679028b1dde876bb49b09e43509d
MD5 (KKK_htm) = e1d69b8c480cc2a50c94255e8bc5fba6
MD5 (KKSS.rh) = f59b74fbe80b0f48fcfb192d9f28c4d0
MD5 (kkk_3.htm) = 6c7734cad8e0fc1d1b52087b9d09610b
MD5 (kkk_4.htm) = 89ed34683d2b81d9e5cde1c1ad97710a
MD5 (kkk_6.htm) = 51e7501e9a04d3eb7f90d1b1dd1b3f37
MD5 (rrrr.1) = b1acbefac08d5ed3c2aa2f6d62e7c93d

brian@nullsecure ~/Desktop/61.174.49.51:6664 > shasum -a 256 *
863cbf4ff59624e0df8c3d71664917e0820597df306743d93cf79907997044f9  123.rar
2ba446d48141b19921e1c623c610eccb021c8b20f05fdcd2baeeb8be80645fe3  KKK_htm
b0f3adc6eceee2d198c94a21484bf94c848533f9efe9748e2a94a13ed805e92b  KKSS.rh
6d4f38761039a2f064b57b29e1f0a0575866adf8be157b5e9d9c386798fe66c1  kkk_3.htm
7d25523aa0b857a262953c281a92ae9c759f7f79dde244bf7c161c0b08cc678d  kkk_4.htm
8f915e4777daba125de5d2c6ec2aa70bf2af65985c8c1fb8b8a55817470faafc  kkk_6.htm
5962c55404cd55e5fca4e0daadd6c1d9e249e4b849d271bb83441d91b314e52d  rrrr.1

And lastly, file sizes:

brian@nullsecure ~/Desktop/61.174.49.51:6664 > ls -alh
drwxr-xr-x   4 Brian  staff   136B Jun 12 10:36 123
-rw-r-----@  1 Brian  staff   442K Jun 11 21:30 KKK_htm
-rw-r-----@  1 Brian  staff   385K Jun 11 21:30 KKSS.rh
-rw-r-----@  1 Brian  staff   444K Jun 11 21:30 kkk_3.htm
-rw-r-----@  1 Brian  staff   348K Jun 11 21:30 kkk_4.htm
-rw-r-----@  1 Brian  staff   734K Jun 11 21:30 kkk_6.htm
-rw-r-----@  1 Brian  staff   474K Jun 11 21:30 rrrr.1

Next, let's submit these to VirusTotal to see what's been seen before and what hasn't.

123.rar was not submitted previously, and had no hits. We open the .rar file and notice why...it's just two text files with Chinese filenames containing a list of IP's, ports, usernames and passwords, most likely a list of potential victims.

The first file contained a list of 254,293 hosts, the second one contained the same results, just formatted a little differently.

Next, KKK_htm was analyzed for the first time as well in VT, and produced some hits. Looks like a file from the MrBLack malware family.

KKSS.rh was analyzed about a week ago, and had 8/56 hits, which were:

Antivirus	Result	Update
Ikarus	Trojan.Linux.Setag	20150531
ESET-NOD32	Linux/Setag.B.Gen	20150531
AVG	Linux/BackDoor_c.CK	20150530
AhnLab-V3	Linux/Backdoor.393728	20150530
DrWeb	Linux.BackDoor.Gates.6	20150531
Kaspersky	HEUR:Backdoor.Linux.Ganiw.a	20150531
Avast	ELF:Elknot-AY [Cryp]	20150531
Jiangmin	Backdoor/Linux.ab	20150529

kkk_3.htm, kkk_4.htm and kkk_6.htm were all analyzed for the first time and had signatures for MrBlack and Dofloo.

rrrr.1 had a little less hits than the others, with only 7 out of 57. It's hits were for:

Antivirus	Result	Update
AVG	Linux/Backdoor.A	20150612
Avast	ELF:Elknot-BL [Cryp]	20150612
DrWeb	Linux.BackDoor.Gates.7	20150612
ESET-NOD32	Linux/Setag.B	20150612
Ikarus	Backdoor/Linux.ky	20150612
Jiangmin	HEUR:Backdoor.Linux.Ganiw.a	20150610
Kaspersky	HEUR:Backdoor.Linux.Ganiw.a	20150612

Next, let's see if these files are packed. There are a few ways to do this, but, let's start with something basic.

I started by running strings on rrrr.1 to see if it was unpacked, since if a file was packed, we wouldn't be able to make out many of the strings. Looking through the file, everything is complete gibberish, most likely meaning it was packed. I get about 3/4 of the way through the file and notice this string:

$Info: This file is packed with the UPX executable packer http://upx.sf.net $
$Id: UPX 3.91 Copyright (C) 1996-2013 the UPX Team. All Rights Reserved. $

So, if the gibberish ASCII strings were any indication that it was packed, this surely tells us it was packed. Next thing to do is unpack it:

brian@nullsecure ~/Desktop/61.174.49.51:6664 > upx -d rrrr.1

Now, when we run strings, we can see a lot more legiable strings in the file, things such as:

9CAttackIe
9CAttackCc
10CTcpAttack
15CAttackCompress
10CAttackPrx
10CAttackAmp
10CAttackDns
11CAttackIcmp
10CAttackSyn
10CAttackUdp
13CPacketAttack
11CAttackBase
7CSerial

The above strings go along with the fact that these are DDoS files, and the above are various types of DDos attacks.

Next, I found the following strings, which would indicate some sort of HTTP requests:

Keep-Alive
Connection
User-Agent
image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg,
application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, 
application/msword, */*
Accept
zh-CN
Accept-Language
gzip, deflate
Accept-Encoding
CONTENT-LENGTH

Along with some user-agents:

Mozilla/5.0 (|S|) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/|D&23&25|.
|D&0&9|.|D&1000&9000|.|D&10&99| Safari/537.17
Mozilla/5.0 (|S|; rv:18.0) Gecko/20100101 Firefox/18.0
Opera/|D&7&9|.
|D&70&90| (|S|) Presto/2.|D&8&18|.|D&90&890| Version/|D&11&12|.|D&10&19|

We can also see a large amount of hardcoded IP address in here. We can use a function that @Andrew__morris wrote called ipgrab, to just run a regex on the output of strings to look for anything that is an IP address.

strings rrrr.1 | ipgrab > ips.txt

The code for the function below, for anyone interested:

function ipgrab()
{
read line; echo $line | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}';
while read line; do echo $line | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'; done
echo $line | grep -E -o '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}';
}

Just plop that in your .bashrc file and you should be good to go.

After running the ipgrab function on the file and piping that to ips.txt file, we can check the file out. Turns out there are 356 IP Addresses in rrrr.1.

Running cat ips.txt | sort -u | wc -lleaves us with 348 IP's after sorting

We can use a quick little python script to spit out the network description and country code to get a better list of the IP's in this file.

from ipwhois import IPWhois
from pprint import pprint

with open('ips.txt') as f:
	for ip in f:
		try:
			obj = IPWhois(ip.strip())
			results = obj.lookup()
			print results['nets'][0]['description'], results['asn_country_code']
		except:
			pass

With this script we can run python resolve.py > filtered.txt

Then, with our finalized list of IP's, we can run something like cat filtered.txt | sort | uniq -c | sort -n and be left with a sorted list of unique networks, which gives us the top networks targeted:

10 CHINANET jiangsu province network
14 A12,Xin-Jie-Kou-Wai Street
14 Beijing 100088 CN
17 China Mobile Communications Corporation
17 Internet Service Provider in China CN
17 Mobile Communications Network Operator in China
24 China Telecom
37 China Telecom CN
37 Data Communication Division
51 China Unicom CN

Given the above list, we can clearly see this is targeting a good bit of IP's in China.

Dynamic Analysis

Next, let's go ahead and run this file inside a Vagrant VM to see what's going on...

First, we make the rrrr.1 file executable chmod +x rrrr.1, then run it ./rrrr.1

In another terminal, we'll run tcpdump to see what type of traffic we're seeing:

tcpdump -i eth0 -nnvvXS port not 22

We run the malware, and start noticing it's sending traffic to one of the three known hosts - 183.60.233.169 over port 36000

Just like my last post on MrBlack, we can see some identifying traffic being transmitted, like:

	0x0000:  4500 009c c6ab 4000 4006 c6bb 0a00 020f  E.....@.@.......
	0x0010:  b73c e9a9 b661 8ca0 c1cb 7078 1944 c002  .<...a....px.D..
	0x0020:  5018 7210 ad83 0000 0100 0000 6c00 0000  P.r.........l...
	0x0030:  00f4 0100 0032 0000 00e8 0300 0000 0000  .....2..........
	0x0040:  0000 0000 0000 0000 0000 0101 0200 0000  ................
	0x0050:  0100 0000 0a00 020f 0a00 020f 0a00 020f  ................
	0x0060:  0a00 020f 0a00 020f ffff 0100 0000 0000  ................
	0x0070:  3a00 0100 0000 0909 0000 e901 0000 4c69  :.............Li
	0x0080:  6e75 7820 332e 3133 2e30 2d34 352d 6765  nux.3.13.0-45-ge
	0x0090:  6e65 7269 6300 4733 2e31 3100            neric.G3.11.

We'll let this run for a while and then open it up in Wireshark to see what we found out...

After letting this run for a good bit, we fire up wireshark. Let's see what IP's this box was communicating with during this time. By going to Statistics -> Endpoints -> IPv4, we can see there were only three hosts involved: my Vagrant machine, my host machine and the attacking machine.

Looking at the traffic, we see the same type of traffic being sent around 30 to 40 seconds to the attacking host. It's 116 bytes of data being sent along with the 54 bytes for headers resulting in packets 170 bytes in size, with the data never changing and always looking like the following:

This is different from when I looked at the other Mr. Black samples in the past, since they would have pipe delimted fields with the string MrBlack in the actual sample. I'm sure they realized that wasn't the smartest idea to include the name of their malware in traffic since that could easily be picked up by any IDS.

So, besides trying to dig deeper into this malware, which I don't feel confident enough to do yet, we can try to generate some YARA rules to scan for this type of malware on other systems.

YARA Signatures

I just started messing around with an awesome tool called yarGen which can take a malicious file and compare the strings found to known good strings from goodware files, which leaves us with strings that are probably bad. To run this, we simply run:

python yarGen.py -m ~/vagrant/ubuntu_64_analysis/rr/

The above will recursively scan the rr directory for files, then read in the good-strings.db file and then produce a YARA rules file to be used to search for this malware.

Here it is in action:

Reading goodware strings from database 'good-strings.db'...
Processing malware files ...
Processing: /Users/Brian/vagrant/ubuntu_64_analysis/rr/rrrr.1
Generating statistical data ...
Generating Super Rules ... (a lot of foo magic)
Applying intelligent filters to string findings ...
Filtering string set for /Users/Brian/vagrant/ubuntu_64_analysis/rr/rrrr.1 ...
Generating simple rules ...
Generating super rules ...
Generated 1 SIMPLE rules.
Generated 0 SUPER rules.
All rules written to yargen_rules.yar

Bam! Rule created.

Let's check out yargen_rules.yar to see what it came up with:

brian@nullsecure ~/Desktop/yarGen-master > cat yargen_rules.yar
/*
	Yara Rule Set
	Author: YarGen Rule Generator
	Date: 2015-06-12
	Identifier:
*/

/* Global Rule -------------------------------------------------------------- */
/* Will be evaluated first, speeds up scanning process, remove at will */

global private rule gen_characteristics {
	condition:
		uint16(0) == 0x457f and filesize < 7429KB
}

/* Rule Set ----------------------------------------------------------------- */

rule _Users_Brian_vagrant_ubuntu_64_analysis_rr_rrrr {
	meta:
		description = "Auto-generated rule - file rrrr.1"
		author = "YarGen Rule Generator"
		reference = "not set"
		date = "2015-06-12"
		hash = "536b282fb9990451fc08a7a827c688c6c385bf63"
	strings:
		$s0 = "_ZN14CThreadHttpGet11ProcessMainEv" fullword ascii
		$s1 = "_ZN19CThreadFXConnection17GetFakeDetectPortEv" fullword ascii
		$s2 = "_ZN17CThreadConnection17GetFakeDetectPortEv" fullword ascii
		$s3 = "_ZN17CThreadFakeDetect11ProcessMainEv" fullword ascii
		$s4 = "ThreadHttpGet.cpp" fullword ascii
		$s5 = "_ZN14CThreadRecycle11ProcessMainEv" fullword ascii
		$s6 = "_ZN19CThreadShellRecycle11ProcessMainEv" fullword ascii
		$s7 = "_ZN8CManager19RecycleShellProcessEv" fullword ascii
		$s8 = "_ZN15CFakeDetectInfo17GetFakeDetectPortEv" fullword ascii
		$s9 = "_ZN14CThreadLoopCmd11ProcessMainEv" fullword ascii
		$s10 = "_ZNSt18_Vector_alloc_baseIP14CThreadHttpGetSaIS1_ELb1EEC2ERKS2_" fullword ascii
		$s11 = "_ZN8CManager19DoFakeDetectCommandEP7CCmdMsg" fullword ascii
		$s12 = "_ZN17CThreadFakeDetect16SetFakeDetectCmdER15CFakeDetectInfo" fullword ascii
		$s13 = "_ZSt11__copy_aux2IP14CThreadHttpGetEPT_S3_S3_S3_11__true_type" fullword ascii
		$s14 = "_ZSt19__copy_backward_auxIPP14CThreadHttpGetS2_ET0_T_S4_S3_" fullword ascii
		$s15 = "_ZSt13__destroy_auxIPP14CThreadHttpGetEvT_S3_11__true_type" fullword ascii
		$s16 = "relocation processing: %s%s" fullword ascii
		$s17 = "%s%s%s:%u: %s%sAssertion `%s' failed." fullword ascii
		$s18 = "ELF load command address/offset not properly aligned" fullword ascii
		$s19 = "_ZN8CManager14RecycleProcessEv" fullword ascii
		$s20 = "_ZNSt12_Vector_baseIP14CThreadHttpGetSaIS1_EED2Ev" fullword ascii
	condition:
		uint16(0) == 0x457f and filesize < 7429KB and all of them
}

For those who haven't messed with YARA rules before, I'll try to break out what it's searching for:

The top section between the /* and */ are just comments we can put in. Next is a global rule which looks for a certain condition. The condition is stating that there is an unsigned integer that is 16 bits long at offset 0 which is 0x457f in hexadecimal, and that the filesize is less than 7.5MB (7,429KB). The uint16(0) == 0x457f part I mentioned above, is looking for the Executable and Linkable Format (ELF) "magic number" which indicates that it is an ELF file.

To verify that the magic number is present, we can run something like hexdump and check it out for ourselves.

brian@nullsecure ~/Desktop/yarGen-master > hexdump ~/vagrant/ubuntu_64_analysis/rr/rrrr.1 | head
0000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
0000010 02 00 03 00 01 00 00 00 e0 80 04 08 34 00 00 00
0000020 38 03 12 00 00 00 00 00 34 00 20 00 03 00 28 00
0000030 1f 00 1c 00 01 00 00 00 00 00 00 00 00 80 04 08
0000040 00 80 04 08 e8 68 11 00 e8 68 11 00 05 00 00 00
0000050 00 10 00 00 01 00 00 00 00 70 11 00 00 f0 15 08sa

We can see right there at offset 0 is 7f 45, which as you'll notice is reversed from what we are searching for. That's because we look for them in YARA as little-endian format, which means the least signficant bits first, so, if you were to take 7f45, the "least signficant" bits would be 45 since they are not as valuable as 7F. For example, 0x7f45 in decimal is 32,581, which is 0111111101000101 in binary, meaning the farthest left bit that is a 1 equals 16,384, thus making it a lot larger than the farthest right bit, which is equal to 1.

I went ahead and tried making my own YARA rule before I messed with yarGen, and produced something like the following:

rule MrBlack
    meta:
        description = "MrBlack Malware Family"
        author = "Brian Warehime"
        date = "2015-06-12"
{
    strings:
        $attack_string1 = "9CAttackIe"
		$attack_string2 = "9CAttackCc"
		$attack_string3 = "10CTcpAttack"
		$attack_string4 = "15CAttackCompress"
		$attack_string5 = "10CAttackPrx"
		$attack_string6 = "10CAttackAmp"
		$attack_string7 = "10CAttackDns"
		$attack_string8 = "11CAttackIcmp"
		$attack_string9 = "10CAttackSyn"
		$attack_string10 = "10CAttackUdp"
		$attack_string11 = "13CPacketAttack"
		$attack_string12 = "11CAttackBase"
		$attack_string13 = "7CSerial"
		$user_agent1 = "Mozilla/5.0 (|S|) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/|D&23&25|.
|D&0&9|.|D&1000&9000|.|D&10&99| Safari/537.17"
		$user_agent2 = "Mozilla/5.0 (|S|; rv:18.0) Gecko/20100101 Firefox/18.0"
		$user_agent3 = "Opera/|D&7&9|.|D&70&90| (|S|) Presto/2.|D&8&18|.
|D&90&890| Version/|D&11&12|.|D&10&19|"
    condition:
		 all of them

Looking at what yarGen produced versus what I produced turned me on to some new things to implement in the future, things like the "magic number" and filesize. In my rule, I just searched for specific attack strings seen as well as the user agents noted in the malware. I'm sure both would work equally well, however, I enjoyed the practice of trying to make my own.

Once we have the rules created, we can go ahead and scan our system like so:

brian@nullsecure ~/Desktop > yara -r mrblack.yara ~/vagrant/ubuntu_64_analysis/
MrBlack /Users/Brian/vagrant/ubuntu_64_analysis/cywlooxx11
MrBlack /Users/Brian/vagrant/ubuntu_64_analysis/rr/rrrr.1

So, we can see our rrrr.1 file got picked up, as well as another file I had sitting around that was another MrBlack sample.

Next up, let's put together a Maltego graph illustrating their attacker/domain infrastructure. We can see a lot of overlap between the filenames and hashes associated with each domain. Here's a screenshot of what it looks like, but, feel free to play around with the maltego graph here as well.

Conclusion

Well, that about covers it. I'm sure there was a lot more I could have done, but, I think this touched on a few new things that I've been doing lately and hopefully was educational for some.

If you have any questions or thoughts about this post, feel free to message me on Twitter, @brian_warehime.