There are two things one can count on every year at ToorCon: the amazing San Diego weather and excellent presentations about new and emerging security research. This year’s ToorCon 11 did not disappoint, and delivered a lot of great content and new security research throughout the weekend.

The conference started with a non-traditional keynote address from Vernor Vinge, an award-winning science fiction author, who presented his thoughts, insight and concerns about the future of ubiquitous computing. As a nice follow-up to this theoretical presentation, Dan Kaminsky spoke next about his research into the flaws behind X.509 public key infrastructure, which he previously spoke about at Black Hat USA 2009 / DEFCON 17 this past summer. These presentations set the tone for this year’s ToorCon, showing that anything and everything is open for discussion.

Saturday’s session featured in-depth one-hour presentations which ran the gamut of security-related topics. Brandon Enright presented an excellent summary of various botnets and how they work and stay operational, which can be a very confusing topic to people who aren’t in the trenches with botnets on a regular basis. Julia Wolf provided a mountain of data about various viruses and other malware that have been in the news, and the kinds of things security geeks dream about at night. A Hollywood-style presentation by Jason Ostrom and Arjun Sambamoorthy demonstrated their freshly released UCSniff tool for IP video eavesdropping and injection by performing a “theft” on stage reminiscent of something out of “Sneakers.” Later in the day, Josh Wright released a framework for the ZigBee wireless protocol, which is appearing in more and more places such as home automation and hospital care.

Last on Saturday, but not least, the CTU’s own Ben Feinstein presented an in-depth analysis of the Koobface malware which has plagued social networking sites throughout 2009, exposing its capabilities, problems and other data that has been gathered over the past several months. Two other CTU members presented on Sunday at this year’s ToorCon. Kevin Stevens spoke about the “pay-per-install” industry, how it has changed over the years and recent “reforms” players in this industry have made. Dennis Brown presented on the underground economy of trading video game currencies for real money which is driving the popularity of game password stealers.

Sunday focused on quick, 20-minute presentations, consisting mostly of new or in-progress research, but there was no decline in the quality of these presentations. One of the presentations that stood out was by Ron Bowes, who released some great information about scanning with nmap over SMB/RPC to obtain detailed system information. Another presentation of note was by Joel R. Voss who presented a new method for static code analysis, and demonstrated its effectiveness in finding flaws in common software. There were many other presentations that contained a wealth of information, as well as a couple impromptu Q&A sessions with Dan Kaminsky and others which were as humorous as they were informative.

Year after year, ToorCon continues to deliver, while still feeling like a smaller conference. One of the great things about ToorCon is that the presenters, and everyone else for that matter, is very accessible and usually happy to talk about what they’ve been working on and share their insight into what’s going on in security. This is often hard to do at the larger conventions, and makes ToorCon special in that regard. It’s definitely worth the trip!

The SecureWorks Counter Threat Unit^SM (CTU) has been carefully monitoring the activity of the Monkif/DlKhora botnet. This bot is an example of a Downloader trojan, in that its primary purpose is to receive instructions to download and execute other malware. The trojan also attempts to disable anti-virus and personal firewall software to maintain its foothold on the system.

One interesting technique the Monkif botnet utilizes to hide its intent on the network is to encode the instructions to appear as if the command and control server is returning a JPEG file. The server sets the HTTP Content-Type header to “image/jpeg” and prefaces the bot commands with a fake 32-byte JPEG header. The bot checks if the header matches and decodes the rest of the response to retrieve its commands. The commands are encoded using a single byte XOR with 0×4. The malware that CTU has observed being installed by Monkif is a BHO (Browser Helper Object) trojan commonly referred to as ExeDot, which performs Ad Hijacking and Ad Clicking.

The botnet makes no attempt to pad the commands to make the data size representative of a true JPEG. In addition, the data will not parse to a legitimate JPEG. These attributes may provide opportunities for generic countermeasures to detect the traffic by identifying malformed image data.

Recently, programmer Ruben Unteregger released the source code for a Trojan that allows an attacker to listen in on a victim’s Skype conversations [1]. For approximately seven years, Unteregger has worked as a software engineer for ERA IT Solutions AG where he developed the trojan. Skype traffic is encrypted using a 256-bit AES block cipher [2], the kind approved by the US Government to protect “TOP SECRET” information.

The Megapanzer trojan variant was released as free software by Unteregger under the GNU General Public License (GPL). The trojan works by injecting a thread into the Skype process and hooking several API calls. While Unteregger’s trojan does not break Skype’s encryption, this method allows an attacker to bypass it as PCM audio data is captured after being decrypted and converted to MP3 digital audio files. The MP3 recordings of the Skype call may then be uploaded to an attacker-controlled server [3].

Fig. 1: Skype Trojan Overview [1]

Governments around the world worry about the use of Skype for nefarious purposes, as the service may be used to place calls that cannot be traced or monitored using contemporary lawful interception techniques. The NSA has reportedly offered billions of dollars to anyone who can “offer reliable eavesdropping on Skype IM and voice traffic” [4]. Even though no backdoors or weaknesses in Skype’s encryption scheme have been disclosed, this trojan demonstrates that an attacker doesn’t need to exploit a flaw in Skype to eavesdrop on Skype communications. This is essentially a variation on the Man-in-the-Browser (MitB) techniques used by malware to steal information and commit financial fraud.

It seems novel that a programmer would release a trojan as free and open source software, however Unteregger stated in an interview that he wanted the code to be available to anyone who wanted to learn or add additional functionality [5]. In addition, since the code is published, it will be detected and blocked by most AV products. The trojan is currently detected by AV as Trojan.Peskyspy.

Fig. 2: Skype Trojan Source Snippet

After becoming infected, the trojan will attempt to disable the following firewalls (if they are present):

• Outpost firewall
• McAfee firewall
• ZoneAlarm firewall
• BitDefender firewall
• F-Secure firewall
• Kerio firewall
• AVG firewall
• Webroot firewall

A backdoor will be created, allowing an attacker to communicate with the victim’s machine. Once connected, an attacker may upload captured MP3 files, update the trojan, or remove the trojan from the machine. The released trojan does not contain a mechanism to spread itself, and has not been weaponized. The CTU believes that we may see variations of this trojan in the future and as always recommend keeping gateway and host AV signatures up to date and the use of a defense in depth approach to security.

References:

1. http://www.megapanzer.com/source-code/
2. https://support.skype.com/faq/FA145/What-type-of-encryption-is-used
3. http://blogs.zdnet.com/security/?p=4133
4. http://www.theregister.co.uk/2009/02/12/nsa_offers_billions_for_skype_pwnage/
5. http://www.megapanzer.com/2009/08/25/interview-on-gulli-com-about-the-skype-trojan-and-trojans-in-general-english/

Twitter is a social networking and microblogging service launched in late 2006. Once logged in, users post small updates to the site frequently throughout the day. These short update messages, known as “tweets,” may not exceed 140 UTF-8 encoded characters. User’s tweets are displayed on his or her “timeline” for their “followers” to see, accessible anonymously via the Twitter web site, RSS, or the Twitter API.

A web service like Twitter that allows users to publish short update messages to a publicly accessible page is a prime candidate for botnet command and control. This is especially true with regard to Twitter, since it is widely used. This large amount of content generated on a daily basis makes it easier for an attacker to blend in without being noticed. A proof-of-concept tool named KreiosC2 was released by Robin Wood that allows users to control machines via a central Twitter feed.

Jose Nazario of Arbor Networks recently uncovered a Brazilian infostealer trojan that uses Twitter for command and control and targets online banking credentials. Here we can see the malicious Twitter account (now cancelled by Twitter) and several encoded tweets:

Source: Arbor Networks

The messages shown are Base64 encoded URLs. Decoding the links and following them leads to an encoded .ZIP archive, which contains the infostealer trojan. In my opinion, using Twitter is an expected but novel addition to the list of previously used command & control protocols, including HTTP, IRC, P2P, et. al. Here we can see a graph of infected machines, the majority of which are located in Brazil.

Source: Arbor Networks

Twitter is not alone; it’s also important to note that other microblogging services such as Jaiku and Tumblr are being used in similar ways. In this case, the malicious tweets look suspicious and are easily decoded, revealing links to malicious sites hiding behind URL redirection services such as bit.ly. The complexity of these command & control mechanisms will continue to increase, with the end goal of operating in a completely undetectable manner.

Black Hat USA 2009 brought us the latest release of Moxie Marlinspike’s sslstrip tool. sslstrip is a tool for performing man-in-the-middle (MITM) attacks against TLS/SSL sessions. The previous version simply terminated the TLS connection at the MITM point and forwarded on an unencrypted connection to the client. While this attack was effective, observant users could tell what was happening. Marlinspike’s new version still terminates the TLS connection at the man in the middle point, but then uses a specially crafted X.509 certificate to create a TLS session to the client. The trick here is in the certificate itself; in order to pull this attack off the certificate must appear to be issued to the original website, not from the attacker. Marlinspike was able to circumvent this protection by exploiting a vulnerability present in many web browser. This vulnerability relies on the fact that character strings within X.509 certificates are ASN.1 encoded, but software written in the C programming language typically manipulates character strings as null terminated character arrays. ASN.1 strings are stored using a form of Type-Length-Value (TLV) encoding. C strings are simply terminated by a null byte (\x00). Here’s what this looks like in memory:


X.509 Certificate:
\x15www.bigbank.com


"C String" (char*):
www.bigbank.com\x00


Marlinspike determined that he could purchase a certificate from a major Certificate Authority (CA) with a Common Name (CN) of www.bigbank.com\x00thoughtcrime.org. Since commercial CAs only look at the root domain name and not the subdomains (i.e., thoughtcrime.org) when validating domain ownership and Marlinspike was the legitimate owner of the thoughtcrime.org domain, he was issued a signed certificate containing his specially crafted Common Name.

Things really start getting interesting when a vulnerable web browser attempts to validate a certificate that has been specially crafted in this fashion. For example, a user browses to www.bigbank.com and uses a DNS server whose cache has been poisoned such that www.bigbank.com resolved to an IP address controlled by an attacker. The attacker has a server at this IP address running sslstrip and using a specially crafted certificate with a Common Name of www.bigbank.com\x00evil.com. The user’s vulnerable web browser will perform a C string comparison (i.e., the strcmp() function from the standard <string.h> header file) between the domain being visited (www.bigbank.com) and the Common Name in the certificate presented by the attacker’s server (www.bigbank.com\x00evil.com). Since the browser is using a C string comparison it will assume it hit the end of the string when in encounters the null byte in the Common Name. Thus it will only compare the “www.bigbank.com” preface of the certificate’s Common Name against the domain being browsed to, www.bigbank.com. The end result is that the browser is tricked into thinking that it has made negotiated a valid TLS connection to www.bigbank.com.

Things gets worse. There is nothing a user can do besides inspect the X.509 certificate as it comes across the wire to detect an attack of this type. This is because vulnerable browsers use the same C string functions to display details of a certificate to the user. It’s quite an elegant attack.

Luckily, Marlinspike has been working with vendors to fix this vulnerability. Mozilla Firefox was updated within the week and a security update to Microsoft Internet Explorer should be available via Microsoft update channels soon. If you haven’t updated your browser in some time, we strongly recommend that you do so immediately to protect yourself from this attack and many others.

Mozilla Firefox has long been my browser of choice. Even though Firefox has not surpassed IE’s market share on the web, there are several features that make the browser indispensable to many of us. Firebug, NoScript, AdBlock Plus, Tamper Data, and the entire plugin architecture are must-haves!

Today, both the Google Chrome and Internet Explorer web browsers have a multi-process memory model, which allows each browser tab or component to run in its own memory space. A tab that crashes in this case will not affect other pages. This is great, except that it does not apply to Firefox. If one of my tabs crashes, the entire browser must be restarted.

Until now! Recently announced was a radical change to Firefox’s memory model. A new project called Electrolysis aims to outfit Firefox with multi-process capabilities. This is great news for Firefox fans. The Electrolysis page states that a future goal of the new memory model may be to provide security enhancements as well.

One of the provisions of the Communications Decency Act (Section 230 of the US Code) established a safe harbor for ISPs so that they couldn’t be held liable for the speech of their users. If you take umbrage at something someone said on the Internet, your remedy is to sue the speaker, not their ISP or telephone company.

That safe harbor is pretty well known, however there is another provision in title 230 that hasn’t received quite as much attention. Subsection (c) (2) provides protection for “Good Samaritan” blocking of offensive material. This states that service providers are not liable for voluntarily blocking access to offensive or otherwise objectionable material.

Kaspersky’s anti-malware product displays warnings and blocks the operation of Zango’s software, which is classified as adware. Zango wasn’t very fond of this practice and thus sued Kaspersky for tortuous interference in Zango’s business. Kasperksy was able to obtain a summary judgment in trial court because of the 230 safe harbor. Zango appealed to the US Court of Appeals for the Ninth Circuit. That court recently handed down a judgment for Kaspersky.

One of the arguments Zango raised in the appeal was that Kaspersky was selling a product, not offering an interactive online service. The court found that Kaspersky’s products count as an interactive computer service based on the fact that they disseminate updates via the Internet. This definition of interactive computer service should be broad enough to cover a good chunk of the security industry.

I am not a lawyer, this post does not constitute legal advice, nor would I be competent to offer such advice. The following is just the speculation of a security geek that thinks that our legal system should be accessible to anyone willing to do the requisite research. That said, for those organizations that would not be covered, I wonder if including a feature that allows users to update content via the Internet would be enough to extend the liability protection to that organization.

Another interesting side effect of including security services under the liability shield is that it could be used to try to shield an individual security researcher from liability. The exact wording of the statue states that no provider or user of an interactive service shall be held liable for:


"any action taken to enable or make available to information content providers
or others the technical means to restrict access to [objectionable content]"


If a researcher were to publish security research online that would allow others to develop countermeasures, that sure sounds a whole lot like it would be included in that definition to me. In theory, this could be used to shield researchers who publish vulnerability information. While this law may offer protection to those who disclose information in a number of different ways, SecureWorks supports and follows guidelines for responsible disclosure.

If this legal tactic were to be accepted in a court of law, there could be two unintended restrictions to when this defense could be employed, that some might consider leading to undesirable outcomes.

First, as the law only protects users or providers of interactive services, this liability shield may not work for someone presenting information in person or dead tree format. Second, if the requirement is to give information which would allow others to be able to restrict access, it might require enough information to write a signature to block the attack. So this could lead to a situation where revealing information online, full disclosure style, could have more legal protections then giving a talk at Blackhat for example. But then again, perhaps videotaping the talk and putting it online would be enough for conferences to be counted as an interactive service. It would be nice to have another tool to defend against legal threats that have unfortunately prevented some security talks.

Summary:

Eurocrypt 2009 was recently held from April 26-30 in Cologne, Germany. Sponsored by the International Association for Cryptologic Research (IACR), the website states that "It is devoted to all aspects of cryptology." This year’s Eurocrypt rump session was held on April 28, which featured a talk entitled "Automatic Differential Path Searching for SHA-1". Authored by researchers at Macquarie University in Sydney, Australia, their work reveals a collision attack on SHA-1 with a complexity of 2⁵² operations (the previous fastest known SHA-1 collision attack had required 2⁶³ operations). This is a significant improvement in finding SHA-1 collisions.

Hash Function Attacks:

A cryptographic hash function is an algorithm that takes a message as an input and computes a fixed-size digest. SHA-1 generates 160-bit digests. The generated digest is used for a variety of applications related to information security, information assurance, and digital trust relationships. When designing new algorithms, designers of cryptographic hash functions aim to fulfill three basic properties:

• Pre-image Resistance:
  Given a hash digest, it is difficult to find any message that will hash to the specified digest value.
• Second Pre-image Resistance:
  Given a message, it is difficult to find a different message that hashes to the same digest value as the original message.
• Collision Resistance:
  It is difficult to find any two unique messages that hash to the same digest value.

In this case, the SHA-1 attacks affect collision resistance, not pre-image or second pre-image resistance. This means that after 2⁵² operations, the researchers are able to generate two unique messages that hash to the same digest value. Obtaining a SHA-1 collision via brute force would require 2⁸⁰ operations. To date, it remains computationally infeasible to perform pre-image and second pre-image attacks on SHA-1. At the time of writing, I am unaware of a practical collision that has been found.

One iteration of the SHA-1 function:

Until recently, SHA-1 was widely regarded as the standard in cryptographic hash functions, and remains widely used in a variety crypto systems and as a normative reference in other RFCs and standards. The transition to the stronger SHA-2 functions presents the potential for interoperability issues, as SHA-2 signatures generated by updated systems may be unsupported by older systems. Adoption of the stronger hash functions must be carefully planned in order to reduce disruption to critical business functions.

The Digital Signature Algorithm (DSA) is an example of an important standard that relies in part on SHA-1. It specifies the use of a 160-bit hash function for the signatures used in 1024-bit DSA keys. The SHA-1 algorithm is nearly always the one used to sign these 1024-bit DSA keys. In order to eliminate reliance on SHA-1, users of 1024-bit DSA keys will need to transition to 2048-bit or larger DSA keys.

The OpenPGP Message Format (RFC 4880) also presents a challenge to the transition away from SHA-1. Section 13.3.2 states that SHA-1 is "the MUST-implement algorithm," and that even "if it is not explicitly in the list [of hash functions configured to be supported], it is tacitly at the end. However, it is good form to place it there explicitly." The GNU Privacy Guard (GnuPG) gnupg command-line tool will automatically reenable SHA-1 if you removed it from a key’s list of supported hash functions, visibly adding it to the end of the list just as suggested in RFC 4880. On the bright side, both GnuPG and the proprietary PGP have supported SHA-256 for well over 5 years now, making interoperability during the transition must less of an issue for users of those popular implementations.

The OpenPGP Web of Trust (WOT) is almost exclusively made up of SHA-1 signatures. Abandoning SHA-1 signatures today would immediately "evaporate" the Web of Trust. Because of the decentralized nature of the WOT, transitioning off SHA-1 will require a collective and distributed effort on the part of WOT users. There is much work to be done to eliminate reliance on the SHA-1 hash function.

The Debian Project uses OpenPGP and the WOT extensively, and has begun the process of transitioning Debian Developers and Debian Maintainers onto stronger crypto algorithms. That link contains some valuable guidance on making the switch as non-distruptive as practicable. Debian’s transition might well serve as an example for other organizations they rely heavily PGP-based cryptgraphic infrastructure.

A centralized, Certificate Authority (CA) based chain-of-trust Public Key Infrastucture (PKI) forms the basis for SSL/TLS authentication, and with that, the trust needed for secure use of the Web. Such a system offers a different set of challenges for a transition to the SHA-2 familiy of hash functions. CAs will need to recreate their intermediate chains-of-trust using SHA-2 signatures and make plans to revoke their SHA-1 signed certificate chain. (Will someone please explain to me how you revoke a root CA certificate?). Users and system administrators with certificates signed using SHA-1 will need to be issued SHA-2 replacements, or more likely will receive a new SHA-2 certificate when they go to renew their certificate with a CA. OS and web browser makers will need to build in support for SHA-2 hash functions if they have not already, and update their lists of trusted root CAs. And of course, users will need to update their OSes and web browsers to support SHA-2 and to receive the updated lists of trusted root CAs.

Every actor has a role to play: end users, organizations, software makers, Certificate Authorities, standards bodies, and of course let’s not forget the system administrators.

On April 1, 2009, while the rest of the cybersecurity world was largely focused on the Conficker worm, Senators John (Jay) Rockefeller and Olympia Snowe introduced the Cybersecurity Act of 2009. Since the hype over Conficker has died down now, I’ve had a chance to review the text of this somewhat controversial bill and add my two cents to the discussion. There are 23 sections to the bill, a few of which have raised some alarm in the infosec community.

The two most often-seen complaints in the blogosphere are:

1. The bill gives the President of the United States the power to "turn off the Internet" in an emergency.
2. The bill requires mandatory licenses for practicing infosec professionals.

Complaint number one seems like FUD to an extent; the bill as worded reads "The President– …may declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised Federal Government or United States critical infrastructure information system or network."

Some have taken "critical infrastructure" to mean communications networks, i.e. the Internet backbone providers. Unfortunately, the bill defines critical infrastructure as whatever the President says is critical infrastructure. So the criticism of the ambiguity here is valid.

But this idea that the White House could shut down the Internet shows a largely U.S.-centric bias when it comes to thinking about what the Internet actually is. Further, such a move during an emergency would likely have worse unforeseen consequences than whatever attack might have prompted it. And it’s unlikely that such an order would be given without consulting technical experts as to the alternatives for mitigating a large-scale attack. I happen to know several Internet infrastructure experts, and I can’t think of any that would say "Hey, let’s just shut off the Internet! That will solve everything!"

Complaint number two has more validity in my book – licensing of security professionals is just plain unnecessary and just creates more bureaucracy. The security industry already has numerous certification programs, all of which already fill the perceived need to have standards in knowledge and practice. If one argues whether a certification proves anything at all, those same arguments could be applied to government licenses as well.

And who gets licensed? According to the bill, this applies to a provider of cybersecurity services to any Federal agency or an information system or network designated by the President, or the President’s designee, as an infrastructure information system or network. I happen to work for a company that provides such services. Do I have to be licensed? Does everyone who works at the company have to be licensed? Where is the delineation?

Despite these and other shortcomings, there are several programs in this Cybercrime bill that I approve of, such as the creation of the Cybersecurity Advisory Panel and the Federal Cyber Scholarship-for-Service program. However, some other provisions seem to be potential boondoggles, such as the state and regional cybersecurity enhancement program.   Throwing money at the problem, at a regional level as opposed to a national level, is not the answer when the majority of skilled security professionals are located in a handful of metropolitan areas.

However, the primary problem with this bill (and any bill put forth by a single government) is that it does nothing to address the larger problem of cybercrime, malware, and the massive outflow of stolen cash from U.S. and European banks to organized crime networks. This is the biggest threat we face on the Internet today, and it won’t be solved by any single piece of legislation (although I wouldn’t mind seeing a Senate bill mandating BCP 38).

The bottom line – until networks everywhere are held responsible for the abuse coming from their systems, the problem won’t get any better.  Note to the Obama administration—if the US government really wants to accomplish something, begin work on a global treaty against Internet and computing abuse, and put an end to the safe havens that cybercriminals currently enjoy in some countries.

In this post I will go over the latest botnet making the headlines. The "Finjan botnet" appears to be large and strikes fear into many. As an average computer user, should you be afraid of the botnet, or should you be scared of being compromised by a Trojan? How bad can one piece of malware be?

I would like to give credit to FireEye for trying to track down the Finjan Botnet that Finjan first reported on. Reading through the Finjan and FireEye write-ups, one is able to reconstruct the trail and also discover the path taken. We can see two major types of Trojans that play a part in this. We have the VBInject Trojan and the AutoIt Trojan.

There are two servers on the same network to which VBInject phones home: x.x.62.2 and x.x.21.186. The server at x.x.21.186 is no longer responsive and appears down at this time. The server at x.x.62.2 is still up and DNS still responds with that IP address for the domain name used in these attacks. If you actually try to browse to that domain though, you will not arrive at this server. As you can see from reading the FireEye article, the Trojan phones home to /ldr/loadlist.php. It downloads more malware from /ldr/dl/. One of the Trojans it downloads is AutoIt.

At the time of this post, if you navigate to /ldr/dl/ you are presented with a directory structure where the Trojans had been kept but now they are gone. If you navigate to the /ldr/ directory you are presented with a login screen. It says "A username and password are being requested by http://.x.x.62.2. The site says: Fun House-10001" Is this a login page to control a botnet?

Now AutoIt looks to phone home to one server with different domain names. I have found at least five different .info domains associated with one particular IP address in the 124.217.x.x range. If you look at /proxy.cfg off of one of those domains it pops up proxy information that says to have everything open and to use the OpenDNS name servers for DNS resolution. When attempting to do a fake phone home I was presented with the below response which is the same response that FireEye got back, however the domains have changed from one ten-letter nonsensical .com domain name to another.

Here is the fake phone home that FireEye posted.

Notice that the user agent is listed as AutoIt. This is the AutoIt Trojan phoning home and the response is to download around 15 pieces of malware. FireEye posted the details of all of the malware in their blog post. Also I found an interesting script where AutoIt sends email through a Gmail account at http://pastie.org/pastes/385624/.

From my investigations into the various malware that use these domains I saw that anIP address in the 124.217.x.x range also pops up. This IP might serve the same function as the one in the 124.217.x.x range but I have not seen any domains for it. Both the ten-letter nonsensical .com domain names resolve to an IP address in the 94.75.x.x range. By using Google and one of the.com domain names in a search I found the whole directory listing for this malware server. When going to /_private/ it asks for a login page. “A username and password are being requested by http://xxxxxxxxxx.com. The site says: "xxxxxxxxxx.info"” The .info domain name also resolves to the same 94.75.x.x IP address.
 

Other notes in regards to the Finjan article. The Trojan that is partially redacted from their write-up is ZCHMIB.EXE and can be seen phoning home "66.90.x.x/bots /control.php?action=getMessage&version=test|16". An interesting thing about this Trojan is that it uses a site called Decaptcha to bypass captcha’s for sites. The site also has a /bot/captcha/ directory to bypass Gmail captcha so it can send spam.

The other file that was partially redacted on the Finjan site looks to be SENEKA[random].DLL. This might be associated with the TDSS/Seneka rootkit. It performs a phone home to a server in the Ukraine "GET /seneka/engine/ld.php?affid=303350&action=2". This might be the server that Finjan was talking about in regard to the botnet. The IP addresses related to this are both on the same 78.26.x.x network.

The 78.26.x.x IP addresses are no longer in use. The IP addresses resolved to a domain name that now resolves to an IP address in the 94.75.x.x range which is already associated with yet another domain name. The original domain comes to a login page but new domain name does not. At this time there is no “0-day” binary that has been identified by Finjan or anyone else to be the botnet.
 

As you can see by following the trail, gone are the days where you have just one Trojan infection. When you have an infection it usually comes from what is known as a Trojan dropper or downloader that will then download many more Trojans that each serves a purpose. From the Finjan article, the botnet masters used their dropper to open up a botnet. From this botnet they were able to specify what Trojans to download for whatever purpose they wanted. Trojans now come in many flavors.

You have spamming Trojans, ransomware, keyloggers, ones that steal your personal data, and many more. The end goal is monetary gain. When you become infected today, it is best to just do a complete reformat of your machine instead of trying to recover it, because you really don’t know how many infections you have. I have read plenty of articles where someone cleans their machine and they think everything is fine only to find more malware days to weeks later.

There is not any perfect AV tool; there is no perfect solution for any one problem. Your best defense is to practice what is called defense in depth and to only go to known websites. Don’t open mail from people you don’t know and be careful opening attachments from people that you do know. Update your OS and software regularly, including AV. Just having AV does not mean that you are protected; you also have to keep it updated.

• FireEye Blog – http://blog.fireeye.com/research/2009/04/botnetweb-part-ii.html
• Finjan article – http://www.finjan.com/MCRCblog.aspx?EntryId=2237
• Prevx shows ZCHMIB.EXE – http://www.prevx.com/filenames/1521641268775071064-X1/ZCHMIB.EXE.html
• ThreatExpert shows TDSS/Seneka activity – http://www.threatexpert.com/report.aspx?md5=5a1a6f4e83900e86c3e7dc62554318ac