Archive for the 'Malware & Virus Analysing' Category

Page 3 of 45

New Spambot In Town Using Compromised Websites To Send Spam

Today, while digging in my sandnet, I came across a trojan that I’ve never seen before and that appeared to be new to me. The trojan gained my attention because its HTTP POSTing to www.google.com which is a bit weird (but more on this later). So, I decided to have a closer look at the trojan and found 20 binaries in my sandnet that showed up a similar behaviour:

2013-07-21 a1ae35eadf7599d2f661a9ca7f0f2150
2013-07-23 a00fd847d7152d2439251d5e5bf20dca
2013-07-29 a11daf09c9ef63466637a0c97a44ae0e
2013-07-30 289e7c3dd1771a1e0865417f81e2308c
2013-07-30 2f1da170625f1f5e5e9aebf0627abd62
2013-07-30 39e5cad818c033dd4b417593a2c16474
2013-07-30 3acf24d2285ce24f54ea60d33005ac2e
2013-07-30 4dce9885245756c8b159c08ebb660040
2013-07-30 4f5794df9bb22321975bc028038d6194
2013-07-30 6daf4f7a6f7131373ff16e7604555cc3
2013-07-30 75d4f090f80ef2628f659cad707d4b7d
2013-07-30 922260a5adbf1698cf1ab0eb0d40036a
2013-07-30 94bda5fa7c52c24259cdf2b3f7c14ebf
2013-07-30 a4b05e98cf2778fd5f44d5c3f5ff0599
2013-07-31 ab11d73f0de74b48deb7023483b49979
2013-07-31 b36c12525968dd29f23523d8898c4c82
2013-07-31 e9db3ab0f75f339995aecd61ebeb8cb6
2013-07-31 f5b627d158d61034064e71cfdd3eaa41
2013-08-01 47f910f5caf4a886675bdb88a317b9c2
2013-08-01 a29fd30396c564fc40a86b54ec36d602

As shown above, I’ve seen the first malware binary showing this behaviour on 2013-07-21. The trojan seems to be, at least from my perspective, somewhat new. What also made me curious of about this trojan is the fact that only 3 out of these 20 binaries are known to Virustotal. However, they seem to have quite a good AV coverage:

MD5 hash: a1ae35eadf7599d2f661a9ca7f0f2150
AV coverage: 35 / 46

MD5 hash: a00fd847d7152d2439251d5e5bf20dca
AV coverage: 34 / 46

MD5 hash: a1ae35eadf7599d2f661a9ca7f0f2150
AV coverage: 35 / 46

Having a look at the AV-results, this trojan is being detected as Rodecap by most AV-vendors. Symantec discovered this new threat on July 23 2013, two days after my sandnet came across the first malware binary showing with this behaviour:
https://www.symantec.com/security_response/writeup.jsp?docid=2013-072315-2550-99

*** The Trojan ****
Once a computer has been infected, Rodecap installs itself into the following directories:

C:\Document and Settings\USERNAME\Local Settings\Application Data\Microsoft\
C:\Document and Settings\USERNAME\Local Settings\Application Data\

The trojan copies itself to these directories using one of the following filenames:

cmstp.exe
ieudinit.exe
logman.exe
lsm.exe
mstsc.exe
sessmgr.exe
spoolsv.exe
wininit.exe
winlogon.exe

In addition, Rodecap might also write the following files:

C:\Documents and Settings\All Users\ieudinit.exe
C:\Documents and Settings\All Users\dllhost.exe

To ensure that Rodecap gets loaded on the system start, it creates a registry key in HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ using one of the following names:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MessageService
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Microsoft Connection Manager
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Spooler
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Sessmgr
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\WinLogon

The AV-vendor ESET has documented additional filenames and registry keys used by Rodecap.

*** Rodecap C&C Traffic ***
The botnet C&C communication used by Rodecap is quite fancy. As mentioned before in this blog post, Rodecap initially communicates with a C&C server using www.google.com. But it also does some other interesting C&C communication which is described below.

To obtain the address of the main C&C server, Rodecap gets the MX record of lyrics-db.org. This DNS response contains two MX records which are pointing to a different domain name:

DNS query: lyrics-db.org IN MX

DNS response:
13 mx1.games-olympic.org.
17 mx2.games-olympic.org.

Rodecap will now obtain the IP address of the main C&C server by getting the A record of one of the referenced MX records:

DNS Query: mx1.games-olympic.org IN A
DNS response: 95.163.104.68

Rodecap C&C Traffic

Rodecap C&C traffic (DNS)

This will tell Rodecap to use the IP address 95.163.104.68 as C&C server. Rodecap even goes one step further, and tries to evade sandboxes by using www.google.com in the HTTP Host header while talking to the C&C (of course this won’t work in a corporate environment where a web proxy server is in place):

POST /protocol.php?p=XXX&d=XXX HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
Host: www.google.com
User-Agent: Mozilla/5.0
Content-Length: 72
Connection: Keep-Alive
Cache-Control: no-cache

d=XXX

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 31 Jul 2013 X
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20

*encrypted data*

If you take a look at this HTTP Header this request should go to www.google.com, but in fact the bot sends the request to 95.163.104.68 which has been previously obtained by Rodecap using the MX DNS query. The IP address belongs to a Russian web hosting company called Digital Networks CJSC (DINET / msm.ru):

inetnum: 95.163.0.0 – 95.163.255.255
netname: RU-DINET-20081230
org: ORG-DNJ1-RIPE
descr: Digital Networks CJSC
admin-c: DNO-RIPE
tech-c: DNO-RIPE
country: RU
status: ALLOCATED PA
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: DN-MNT
mnt-routes: DN-MNT
mnt-domains: DN-MNT
source: RIPE # Filtered

Of course, Google is not hosted in Russia…

Once the bot contacted the main C&C server, it will tell the bot to drop additional malware components (PE32 executables):

hXXp://www.google.com/d/conh11.jpg
hXXp://www.google.com/d/fu13.jpg

Again, these files are not hosted on Google, but on 95.163.104.68. The dropped files are not .jpg files rather than windows executables:

Rodecap Binary Drop

Rodcap dropping additional binaris

*** Rodecap spam module ***
What Rodecap drops here seems to be at least one module that is used for spamming. This spam module has an interesting way of spamming internet users mailboxes. To do so, Rodecap will call a C&C server at newsleter.org to get a task from the botnet herder using HTTP GET:

GET /d/t14.php HTTP/1.1
User-Agent: -
Host: t.newsleter.org
Cache-Control: no-cache

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 31 Jul 2013 X
Content-Type: text/plain
Content-Length: 309
Connection: keep-alive
Keep-Alive: timeout=5
Last-Modified: Mon, 22 Jul 2013 X
ETag: “X”
Accept-Ranges: bytes

*encrypted data*

I’ve seen the spam module using different subdomains of newsleter.org, and they are hosted on different IP addresses:

t.newsleter.org (95.163.104.93 – AS12695 DINET RU)
bt.newsleter.org (208.115.109.53 – AS23033 Wowrack US)
seek.newsleter.org (208.115.109.53 – AS23033 Wowrack US)
fw.newsleter.org (85.143.166.221 – AS56534 Prix RU)

What Rodecap will try to get from these C&Cs is a spam template and a list of hijacked websites (more on that below).

*** CMS php backdoor component ***
Unlike other spam botnets that are either using stolen SMTP credentials for spamming, spamming the victims mailserver directly or abusing open SMTP relays, Rodecap seems to use a huge list of websites that have been compromised and running some kind of PHP script (backdoor). Within a few hours I was able to retrieve more than 3’500 unique websites that seems to run an outdated content management system (CMS, such as Joomla!) and which have already been compromised and hosting a malicious PHP file. A list of compromised websites I’ve came across so far and that are associated with Rodecap can be found here:

https://www.abuse.ch/downloads/rodecap_compromised_cms.txt

Unfortunately I wasn’t able to get a copy of such a PHP file yet, but based on the botnet traffic towards these compromised websites it seems that Rodecap is spamming through these PHP files:

Rodecap Spammodule C&C Traffic

Roadcap C&C Traffic

The HTTP POST request look like this:

POST /old/nieuw/plugins/editors/tinymce/jscripts/tiny_mce/plugins/devkit/stats.php HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0
Host: www.hrmet.nl
Content-Length: 883
Connection: Keep-Alive
Cache-Control: no-cache

encrypted data

HTTP/1.1 200 OK
Date: Wed, 31 Jul 2013 X
Server: Apache
X-Powered-By: PHP/5.2.14
Content-Length: 39
Keep-Alive: timeout=1, max=100
Connection: Keep-Alive
Content-Type: text/html

OK+taskid+0

If the PHP backdoor response with “OK” and the task ID, the spam email was obviously sent successfully. I’ve also seen various compromised websites returning the OS version and the task id instead of just “OK”. For example:

Linux20+taskid+1 (for webservers running Linux)
WINNT20+taskid+1 (for webservers running Windows, mostly IIS)

If the PHP backdoor isn’t able to send the spam mail (eg. because the spam mail has been rejected by the remote mail server), the PHP backdoor will send this information back to the bot along with the error message from the remove mail server.

Some examples:

Linux20+taskid+4+(dave332453@aol.com)+550 5.1.1 : Recipient address rejected: aol.com|
Linux20+taskid+3+(davehibbeler@hotmail.com)+421 RP-001 (BAY0-MC2-F47) Unfortunately, some messages from 92.53.113.126 weren’t sent. Please try again. We have limits for how many messages can be sent per hour and per day. You can also refer to http://mail.live.com/mail/troubleshooting.aspx#errors.|
Linux20+taskid+2+(davecarter159@yahoo.com)+421 4.7.0 [GL01] Message from (217.21.184.244) temporarily deferred – 4.16.50. Please refer to http://postmaster.yahoo.com/errors/postmaster-21.html|

According to the error messages, Rodecap currently targets big free email providers such as Windows Live, Yahoo and AOL.

I ran a Rodecap binary in a sandbox for a few minutes and checked the responses from the compromised websites. Based on the responses it appears that most of the spam sent by Rodecap were accepted by the remote mail servers.

*** Conclusion ***
This new threat seems to be just another spam bot in the wild. However, it is using some interesting methods for C&C communication and for sending out spam that I’ve never seen before. In fact the idea is quite good: There are ten thousands of websites out there running vulnerable (unpatched) CMSes that can easily be exploited to install malicious software on the victims webspace. The Rodecap gang seizes this opportunity to install a PHP backdoor that then allows them to send emails through the compromised webservers. By doing this, the criminals avoid common blacklists, especially blacklists that are listing dynamic IP space used by end users (DSL / cable subscribers) such as Spamhaus PBL or SORBS DUL.

To defend your network against this new threat, you should:

  • Block HTTP User-Agent “Mozilla/5.0″ and “-” on your Web Proxy
  • Ensure that your CMS is up to date running the latest version

In addition, you might also want to block the C&C communication associated with Rodecap going to the following destinations:

lyrics-db.org
games-olympic.org
mx1.games-olympic.org
mx2.games-olympic.org
newsleter.org
t.newsleter.org
bt.newsleter.org
seek.newsleter.org
fw.newsleter.org
95.163.104.68
95.163.104.93
208.115.109.53
85.143.166.221

UPDATE 2013-08-02 11:15 UTC
A reader of abuse.ch contacted me and suggested to block 95.163.64.0/18
entirely which belongs to Digital Network JSC (DI-NET Russia). According to him this blockage didn’t cause any false positive in the last 2 years.

Follow me on Twitter: https://twitter.com/abuse_ch

Collateral Damage: Microsoft Hits Security Researchers along with Citadel

Before I start this blog post, I would like to express that it is not my intention to offend any person or organisation. Please understand that I’m currently very disappointed and in some ways angry because of the story described below.

Operation b54

As most of you have already read in the press, the Microsoft Digital Crimes Unit (DCU) recently carried out an operation called Operation b54 to shut down Citadel botnet C&C servers. According to Microsoft, they were able to disturb over 1’400 Citadel botnets around the world by seizing more than 4’000 domain names and pointing them to a server operated by Microsoft. Technically, this is what we call “sinkholing”.

Sinkholing domain names isn’t something new, in fact this technique has been around for ages and was already used by the Conficker Working Group and their operation to hijack the Conflicker botnet. The purpose of a sinkhole is the same for the most part: collecting information about infected computers that are connecting to the sinkhole and report these back to the associated network owner so that the responsible end user can be notified about the infection and remove the malware from their computer.

These days there are many sinkholes around, most of them are operated by security researchers. But there are also many commercial sinkholes out there, that are being used by security service providers to gather information about infected computers and sell that information to their customers. As a security researcher I spend a lot of time in researching botnets in my spare time, and abuse.ch is running such a sinkhole as well (in fact for years). The goal is simple: sinkhole malicious botnet domains (not only limited to any specific Trojan / malware family) and report them to Shadowserver. Shadowserver, a non-profit organisation like abuse.ch, then informs the associated network owners about the infections reported by my sinkhole, in addition to infections reported by their own sinkholes and sinkholes run by other operators. In fact, every Computer Emergency Response Team (CERT), Internet Service Provider (ISP) and network owner can get a feed from Shadowserver for their country / network for free. For the time being, Shadowserver notifies more than 1’500 organisations and 60 national CERTs about infected computers within their responsibility.

Today, I’ve suddenly noticed that several domain names disappeared from my sinkhole. I started to investigate and noticed these are now all pointing to a server in Microsoft’s network range (199.2.137.0/24). It was quite obvious to me what had happened. Microsoft seized not only malicious domain names operated by cybercriminals to control computers infected with Citadel, but also Citadel botnet domain names that had already been sinkholed by abuse.ch awhile ago (I want to outline here that my sinkhole is appropriately tagged and clearly shows that it is actually a sinkhole of abuse.ch). I pulled down the list of Citadel domains that Microsoft seized and checked it against my sinkhole’s domain list. I was quite surprised about the result: Microsoft seized more than 300 domain names that where sinkholed by abuse.ch. I was not only surprised but also quite disappointed: Microsoft already showed similar behaviour in their operation against ZeuS last year were they seized thousands of ZeuS botnet domains, including several hundred domain names that were already sinkholed by abuse.ch. Due to this, I’ve set up a (non-public) Sinkhole Registry for LEA and security organisations to avoid similar situations in the future. I had hoped that Microsoft had learned their lesson, but apparently nothing has changed and my efforts didn’t change anything.

Since Citadel domain names previously sinkholed by abuse.ch have been grabbed by Microsoft, Shadowserver will not be able to report the IP addresses of infected clients calling home to these domains to the network owners any more.

Today, I’ve talked to several other sinkhole operators asking them about their experience with Microsoft. All of them confirmed to me that several dozens and for some operators even hundreds of Citadel domain names they had sinkholed have been seized by Microsoft as well. Calculating the numbers together, I can say that nearly 1’000 domain names out of the ~4’000 domain names seized by Microsoft had already been sinkholed by security researchers. In fact these ~1k domain names did no longer present a threat to internet users, but were actually used to help to make the internet a better place.

Unfortunately, this is just the tip of the iceberg. When checking out Microsoft’s sinkhole, I noticed that they are actively sending out valid Citadel configuration files to the connecting bots. A sample configuration file served by Microsoft’s sinkholes looks like this:

url_loader (binary download)

http://dcu-a-204.microsoftinternetsafety.net/updatefile-463454.exe

end

entry “AdvancedConfigs” (backup config files)

http://199.2.137.202/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

http://dcu-a-202.microsoftinternetsafety.net/file-463454.php

This configuration file causes that the blockage of websites of AV vendor gets removed (so the on the infected computer installed AV product can load the most recent definition), but also that the main C&C configuration including the fall-back (backup) C&C domains to get overwritten by servers operated by Microsoft (microsoftinternetsafety.net):

Registrant:
Domain Administrator
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
US
domains@microsoft.com +1.4258828080 Fax: +1.4259367329

Domain Name: microsoftinternetsafety.net

Registrar Name: Markmonitor.com
Registrar Whois: whois.markmonitor.com
Registrar Homepage: http://www.markmonitor.com

Due to this, Microsoft ensures that once a bot connects to their sinkhole it stays there and won’t try to reach out to a different C&C. In theory, this is a very good idea and I have to say that many sinkhole operators had the same thought years ago. But unlike Microsoft, most of the sinkhole operators came to a different conclusion: Sending out valid configuration files de facto changes settings of a computer without the consent or knowledge of the user (computer owner). In most countries, this is violating local law.

A very important point which Microsoft either didn’t take into account or chose to ignore, are potential countermeasures by the criminals. Let me try to make two examples:

From ZeuS-Licat (aka Murofet) to P2P ZeuS (aka ZeuSv3 aka Gameover ZeuS)

In 2011 ZeuS-Licat (also known as Murofet), a derivative of ZeuS, was using a Domain Generation Algorithm (DGA) which an infected computer (bot) used to “calculate” the current C&C domain. There were a lot of effort by security researchers and information security organisations to shutdown the daily C&C domains immediately after they became active. Every domain name was listed on ZeuS Tracker as soon it went active. Obviously, this effort popped up on the criminals radar quite fast. It didn’t take long for the criminals to roll out a new version of ZeuS-Licat – P2P ZeuS was born. P2P ZeuS is no longer using a central C&C infrastructure that could be sinkholed or take down, rather than using a sophisticated P2P technique to receive commands from the botnet herder and send stolen data to the criminals. Since the source and destination ports used by P2P ZeuS are randomized, its hard to detect such traffic in an ISPs network environment, and even harder to actually block it. A network owner needs an IPS/IDS or a deep packet inspection (DPI) system to detect or block such P2P ZeuS activities.

Torpig – RSA signed C&C communication

Torpig is a highly sophisticated e-banking Trojan that has been around for years. There are various organisations out there doing sinkhole operations on the Torpig botnet. A while ago, one of these operators started to send out valid configuration files to the connecting bots which caused that the bots stay on that specific sinkhole. This is in fact exactly what Microsoft is doing at the moment for Citadel. Of course, it was quite obvious that the criminals would implement countermeasures soon. It didn’t take long for the Torpig gang to roll out a new version of their Trojan that implemented an RSA signed C&C communication. While sinkholing is still possible, it is no longer possible to send a valid response back to the infected computer (bot) unless you know the private RSA key (which is only known to the Torpig gang).

Conclusion

It is common that such takedowns trigger countermeasures by the cybercriminals. Imagine: If someone breaks into houses with a baseball bat and you seizing his bat, what will that person likely do next? If he wants to continue, he will just buy a new baseball bat – or maybe he will even buy a gun next time, to make it harder to take him down. When you apply this to the Citadel case it’s obvious that the criminals using Citadel won’t stop doing cybercrime. It may even have the bad effect of criminals updating their software to prevent that such takedowns are possible in the future again (eg. by implementing P2P techniques like ZeuS-Licat or RSA signed C&C communication for Torpig). The problem with cybercrime is that it can’t be solved with doing takedowns. It’s only possible to solve this issue by implementing legislation related to cybercrime, enforce them by getting bad actors arrested and implementing security by design on different layers (operating system, network layer etc.).

As outlined before, Shadowserver will no longer be able to inform network owners about several thousand Citadel infected computers because the Citadel domain names sinkholed by abuse.ch has been seized by Microsoft.

According to Microsoft, their goal was to disturb Citadel botnet operations. In my opinion their operation didn’t have any big noteworthy impact on Citadel, rather than disturbing research projects of several security researchers and non-profit organisations, including abuse.ch. In my opinion, operation b54 was nothing more than a PR campaign by Microsoft.

Follow me on Twitter: https://twitter.com/abuse_ch




economics-recluse
Scene
Urgent!