McAfee Avert Labs Blog

Over the past week, Mailbot.f (a.k.a “Kraken”) was thoroughly studied and reverse engineered by various security researchers. As mentioned in my previous blog, we focused mainly towards the network behavior of the bot and observed a few interesting things.

After the bot installs on a victim machine, it attempts to contact mx.google.com via TCP destination port 25 (SMTP) 3 times. This looks to be a network connectivity test by the bot. If this test fails, the bot does not send out any spam at a later stage. (Note that the bot does not use mx.google.com to spam). Next, the bot downloads the front page of 3 different popular web sites (mostly news sites), such as nytimes.com, cbsnews.com, news.com, cnn.com, reuters.com, msn.com, google.com, etc. We have not observed the use of these web pages in the spam sent out by this bot, however.

The bot then tries to find its peers and communicates with them. If it is an older version of the bot, it uses UDP destination port 447 to communicate with the peers, sending information such as the bot version, outgoing smtp connectivity status and other machine specific information such as hostname, operating system, uptime, language, CPU specs, memory information etc. It also communicates the current modules and their versions. The older version of the bot then downloads an update from its peers by connecting on TCP destination port 447. We have observed that this update is around 100 to 200 kbytes. The bot then updates itself.

The new version of the bot (or updated bot from the previous step) contacts its peers using UDP on random destination ports and sends similar information as in the previous step. It then connects to one of the peers to update its modules using TCP destination port 80. If the peer is available on port 80, the bot communicates using HTTP POST messages and receives the updates from its peers.

In the case when the peer is not available on TCP port 80, the bot communicates on TCP destination port 443 to download the module updates. Though it communicates using TCP port 443, the data is not SSL.

The bot then downloads other modules from its peers, such as spam template, spam payload, and mx server addresses, etc. With this information it starts sending out spam email. After sending out a batch of spam, it downloads further updates and sends out spam again.

We made the above observations after looking at a number of Mailbot.f samples. Most of these samples were either v315 or v316 (as derived from the bot client registration packet). All of the command & control (c&c) communication is encrypted and we were able to decode some of the c&c communication using the wireshark plugin referenced by mnin security blog. Since the bot can be updated, at will by the bot author, some of these observations may/can be changed at any time.

Given that the bot uses

• encrypted data
• random UDP destination ports with random size packet payloads
• legitimate HTTP protocol on TCP destination port 80
• communication on TCP destination port 443

its c&c communication is very stealthy and difficult to detect. Although the bot is currently being used to send spam email, the stealthy c&c communication and the update infrastructure already in-place can pose a greater threat if used for more devastating purposes.

There have been a couple of threads lately, one on LifeHacker, one on Ask Metafilter, about whether it’s necessary to use anti-virus software. The comments in both are a very clear indication on how far we have to go in educating users on the real danger of malware. It would appear the average user is operating under assumptions that might have been true 8 years ago. Now, it’s just a recipe for disaster.

The erroneous assumptions are that:

1) Viruses are noisy/easily visible and
2) Viruses are caused by actively bad behavior

To quote What the Geek from the LifeHacker thread,

I have a business client whose website was giving people a trojan for a while because it got hacked - and guess what? if you didn’t have an AV running, you’d never know that it happened. It would just sit on your computer sending your data off to who knows where silently. Just because it doesn’t give you a big skull and crossbones on the screen doesn’t mean it isn’t there.

This really sums up the situation for me - an innocent user was hacked, and might never have known it, as it was silent. It’s like the difference between the demos we give of an “average scary virus” now versus the ones we gave 10 years ago. Back then, the demos were all skulls and message-boxes and file corruption and deletion. Very spooky, very visual and very loud. Now the scary demos are effectively silent. The malware can come in without any user interaction, and you’d never know it was there without specific tools to show you what changes it’s making behind-the-scenes. Off goes your credit card number and your private documents, without you being the wiser.

And this is not something that just happens in the “bad parts” of the internet. Think of the most innocuous content on the internet. Pictures of cute and fluffy animals would certainly qualify, right? At the end of last year, CuteOverload fell victim to a hacking that delivered trojans to its unsuspecting readers. And major sites are supposed to be safe, right? How about the Superbowl website hack from the beginning of last year?

One point that I think needs bringing up specifically is the question of whether to use “on-access” scanning, or if “on-demand” is enough. As Dwroth succinctly put it in the LifeHacker thread:

All time (active protection) = good for the public, but overkill for the geek.

Turning off on-access scanning has never been a great idea, but now it could be a catastrophically bad idea. We’ve already discussed how one’s level of geekiness does not figure into one’s susceptibility to viruses which don’t require human interaction. Personally, if there’s a virus trying to get onto my computer, I’d really rather find out immediately before any changes could be made to my system rather than some time tomorrow or later this week.

A few minutes is plenty of time for malware to transmit my most sensitive data, why give it hours?

Clear protocols such as FTP or SMTP are unsafe. Anyone on the subnet can easily collect login usernames and passwords just by sniffing the network traffic. Even switched networks can be easily attacked to redirect traffic and gather credentials as simply as on a HUB based network. However, FTP is still widely used and often the only protocol provided by hosting providers and it’s for this reason we weren’t so surprised to come across PWS-FerTP – a piece of malware that takes advantage of this situation, collecting FTP credentials and infecting FTP repositories.

To slow down analysis, PWS-FerTP includes some (very simple) anti-debugging tricks and VMWare detection functionality shown below. Not very stealthy though, utilizing some well known VMWare internal mechanisms used mainly by VMware tools to communicate with the host system.

PWS-FerTP bypasses the Windows Firewall (by modifying the registry) and starts to look for three widely used client applications providing FTP support (FAR Manager, CuteFTP and Total Commander). Indeed, these applications unfortunately use weak encryption to save FTP passwords, while other details such as logins and IP addresses are stored in the clear.

In an attempt to gather more FTP credentials, PWS-FerTP switches the first network adapter found on the system to promiscuous mode via the ioctlsocket API call, allowing for a disabling of MAC filtering and thus sniffing all FTP account details passing by the current subnet.

PWS-FerTP sends all gathered credentials within specially crafted HTTP requests to a remote web server.

But PWS-FerTP is more than a password stealer – a quick string search reveals some interesting blocks of obfuscated Javascript as well:

Once decoded, the aim of this script becomes much clearer, redirecting user’s browser via an IFRAME HTML tag pointing to a malicious website.

In fact, PWS-FerTP connects to each previously gathered FTP account and looks for files whose names belong to this list:
- index.htm
- main.htm
- default.htm
- index.php
- main.php
- default.php

When such a file is found, PWS-FerTP retrieves it locally, injects the Javascript code shown above, and put the file back to the FTP repository.

Another good reason to follow well-known best practices: avoid using clear-text protocols and use applications providing strong encryption, like keepass, to store your credentials.

So, on a bright Friday morning here in Brazil, I was analyzing an interesting piece of malware. Well, this piece of malware was sending encoded data to gooqle-analytics.com…hmmmm maybe trying to get infection statistics?

We have seen this before…but something wasn’t quite clear… it seemed that this was all that the malware was doing… hmmmm ok… checking a little closer, I could see the traffic generated… it was encoded traffic… not common for Google Analytics…

A little more research revealed that there was a dll injected in the svchost process, and analyzing this packed dll revealed that its purpose was to steal information and send to gooqle-analytics… but what the heck? Is Google stealing my info? NOT!!! As some of you noticed reading this blog, I did not misspell the name… it was sending the info to gooqle-analytics.com, and not google-analytics.com…

This gooqle thing domain is hosted on a IP in Italy…yea…bad,bad gooQle…!

I was not at all surprised when I first saw the Trojan named anticnn.exe, because I’ve followed recent events between China and the Western media. I am not going to offer any political comments on the conflict between these parties; however, the appearance of this malware well illustrates how information warfare works and further proves that this kind of nonmilitary, nongovernmental battle has become an increasingly common phenomenon.

The Chinese “hacktivists” obviously have no intention of hiding their origins. The file has the flag of the People’s Republic of China as its icon. Upon execution, the red flag is displayed in the lower-right corner of the desktop. After a user clicks the flag, a window with a picture of Mao Zedong pops up with the message “It is a red flag action: using rational action to express your patriotism. That attack target is www.cnn.com.”

The file connects with www.cnn.com and keeps sending HTTP GET requests. The Chinese “hacktivists” seem to believe that as long as there are sufficient participants they will be able to succeed in their attack.

McAfee has detected this malware. I remain concerned, however, that anti-virus detection can prevent only those users who are unaware of the situation from getting involved in this event. Eventually this Trojan could be widely distributed via spam, malicious or hacked Web pages, Internet Relay Chat (IRC), peer-to-peer networks, etc. This attack looks like it will be hard to stop if many “infected” users intend to get this tool and run it intentionally.

Just one day later, we came across another tool designed for the same purpose. The difference with this tool is that it does not have a hard-coded target address. Instead, it allows users to manually input a target’s IP address or DNS name, and TCP port. Obviously, the organizers do not wish to name their target too early. In the setup program’s readme file, it says the attacker will inform the target a half-hour before the attack will be launched. Another interesting point: The tool developer states in the readme file that the tool has no backdoor inside. That makes me ask, Should the average user trust the developer’s claims?

Commonly in conversation with family or friends I am asked questions that begin with statements such as “Well, I had this computer virus…” Further into these conversations after asking some additional questions of my own, I become more convinced that the person believes they had a virus. From the descriptions provided I am often inclined to suspect classes of malware and potentially unwanted programs that are commonly referred to as FakeAlerts and rogue security software are responsible.

I have come across many of these types of programs disguised as anti-virus or anti-spyware products that generate false warnings of malware that is supposedly present on the system:

Fake alerts are typically trojans that generate false warnings of spyware on the computer. These alerts are most often displayed as a balloon pop-up from the systray. The fake alerts will typically encourage the user to download or install a rogue security software product by means of “detecting” bogus infections on the system and frighten the user into buying the rogue software in order to clean the fictitious malware that that was discovered.

I am continually surprised at the prevalence of these types of applications and how many computer users install and use these so I thought it might be useful to post some tips that may help with identifying traits that are commonly associated with these types of scams.

Use Responsible browsing practices:
Trojans typically spread manually, often under the premise that they are beneficial or wanted. To do this often times similar techniques such as those used in product marketing are involved. Responsible browsing practices can include identifying when propaganda is used to persuade one into believing something, doing something, or buying something. This is not solely indicative of something malicious in nature, however being able to tell when these methods are utilized can sometimes help one to know when to ask more questions about the motivation or intentions for the use of the tactic.

Do some quick research:
If something does flag ones attention it may be worth the effort to do some quick investigation. Use a well known search engine and enter search terms such as the name of the product you are being asked to purchase, the title of the dialog being displayed, the name of the malware that is being detected, etc. Try to avoid pages that are sponsored by the target of your investigation. Look for third party opinions or reviews. This may help provide some additional counterpoints that may help with an objective analysis of the software in question.

Are there any secondary indications of an infection?
Look for the presence of the files being identified by the software as malicious. Often these files will not exist on the system at all. Sometimes however these types of programs will write the fake files to the system so that it can later detect them as malicious.

Check the time and date stamps on the files. Are they similar to that of the time the program was installed or ran a scan?

Submit the file to an online scanning service such as VirusTotal and see if established anti-virus programs detect them.

These are just a few simple examples from the quick and easy do-it-yourself malware research guide!!

The Internal Revenue Service (IRS) is some phishers favourite target, especially during the tax season each year. We first saw IRS phishing emails in our spam traps in 2005 and have seen them every year since, particularly when the U.S. tax year comes to a close.

Does the early bird catch the worms?

Who would consider a tax issue as early as in September? The phishers must think someone would. We started to see IRS phishing e-mails as early as September last year. The volume has increased in the following months, with a sharp increase in January 2008, and is showing no signs of abating today.

Targeting both individuals and businesses

Most IRS phishing e-mails target individuals, but there were several campaigns which targeted business/corporate accountants and treasury managers this year. The phishing e-mails claimed that there were some recent changes to business and corporate tax laws and asked the recipient to download the relevant files by clicking the embedded links.

Using an IP address instead of a normal domain name is commonly seen in phishing e-mails, because the phishers want to hide the phish domain name from the recipients eyes. In the sample below the phisher also claims that the encoded IP is a document reference and the phishing uri is a personalized link.

Common characteristics of an IRS phishing e-mail

The IRS phishing e-mails normally have a faked “From:” header to try to let the recipients think it is from the IRS. The message body part usually begins with different variations of the IRS logo. They usually follow this with how much money you are supposedly to be refunded for the year. Then the recipients are asked to fill a tax refund form by clicking a link which is normally hidden behind text, such as “Please click here”. The link will lead the recipients to an online form which requests personal information such as Social Security Number, Name, Address, Date of Birth, mother’s maiden name, Bank account number, Credit card number, Expiration date, Card verification number, ATM PIN number and name of the issuing bank.

Recently some phishers have enclosed a html attachment to the e-mail rather than including a link to a phishing web site, and have asked the recipient to open the attachment and submit the details via the attached form.

We also spotted an IRS Vishing (short for “voice phishing”) campaign this year.

All in all it has been a busy tax season for the IRS phishers. The IRS give some helpful tips on how to avoid being caught out by these types of phishing emails on their web site.

The latest Microsoft ActiveX flaw disclosure looks like a silently patched issue.

The flaw, disclosed by US-CERT, was not part of Microsoft’s MS07-069 Security Bulletin released in December of 2007. The CVE ID (CVE-2007-6255) is not listed in Microsoft’s Bulletin at the time of this writing and is still in the reserved state on MITRE’s CVE Web site.

The vulnerability affects an ActiveX control used to play games on the MSN Games site. When exploited, it would allow for code execution at the rights level of the victim because of improperly processing a crafted “host” parameter.

The workaround for those who have not installed the patch is…

Bingo! Set the kill bit. You’ll want to disable the ActiveX object from loading using this class id: E5D419D6-A846-4514-9FAD-97E826C84822.

This is one of those cases where the moment you hear about the vulnerability, there is a patch available already. This, of course, is better than the alternative. Most of you should have the patch already installed.

I’m not going to get into the “Why weren’t we notified?” issue, I just wanted to call attention to this on the off-chance there is anyone who isn’t patched.

After the recent interest in Kraken bot by various communities, Gaurav Dalal, Denys Ma, and I have been observing the network behavior of the bot very closely.  About 2 weeks after the initial analysis from SANS, it seems like the bot author has seeded the bot with an update via TCP port 447. The updated bot now uses a stealthier command and control (c&c) mechanism that will evade previously proposed detections. The updated bot no longer uses UDP port 447 with 74 bytes of payload. After the bot updated itself, we observed that it uses UDP packets with random ports and also random packet payload lengths for its c&c communication. All of this c&c communication is encrypted. As a surprise, we also noticed that the updated bot now uses the well known HTTP protocol on TCP port 80 and 443 to send and receive encrypted c&c communication data. More interestingly, the communication on port 443 is encrypted but non-SSL. The process of the upgrade and also the c&c mechanism itself seems to be very interesting. We are continuing our research and will update this blog with more technical information soon.

Late on Thursday Microsoft released an advisory about a new privilege escalation vulnerability affecting IIS and SQL Server on Windows XP, 2003, Vista, and Server 2008.

It’s likely that this is the same flaw discussed by Cesar Cerrudo in his talk, “Token Kidnapping”, at the HITB Security Conference 2008 in Dubai. Cerrudo had discovered a privilege-escalation vulnerability earlier, and said in March, “Design weaknesses can be abused on Windows XP, Vista, Internet Information Services 7 and Windows Server 2003 and 2008”.

So what is known about this flaw? A malicious local user who has authentication could execute specially crafted code to raise his privilege level to LocalSystem. IIS and SQL Server are the main attack vectors. But other vectors are possible, such as Microsoft Distributed Transaction Coordinator (MSDTC) on Windows Server 2003.

While the vulnerability is limited to a local privilege escalation, IIS’s susceptibility is concerning. The Web server is widely used on the Internet, and is a top pick by Web-hosting providers. We might see Web-hosting providers targeted, and — this is scary -– their clients’ Web sites breached. As Microsoft stated in its advisory, “Hosting providers may be at increased risk from this elevation of privilege vulnerability.” However, no exploitation has been observed at this time.

The next Patch Tuesday is May 13. Sysadmins, please heed to Microsoft’s suggested workarounds for IIS until then -– or more to the point, until Microsoft patches this vulnerability.

Finally, a bit of speculation (hat tip to Kevin Beets). One attack vector for this vulnerability uses the SeImpersonateClient privilege. The MSDN page for privilege constants states:

Windows XP/2000: This privilege is not supported. Note that this value is supported starting with Windows Server 2003, Windows XP SP2, and Windows 2000 SP4.

Microsoft did not say that Windows 2000 or Windows 2000 SP4 are vulnerable. But curiously, they did say Windows XP SP2 is. If Service Pack 2 for Windows XP introduced this vulnerability in that operating system, might Service Pack 4 for Windows 2000 not have done the same for Windows 2000?