‘Citadel’ Trojan Touts Trouble-Ticket System

Underground hacker forums are full of complaints from users angry that a developer of some popular banking Trojan or bot program has stopped supporting his product, stranding buyers with buggy botnets. Now, the proprietors of a new ZeuS Trojan variant are marketing their malware as a social network that lets customers file bug reports, suggest and vote on new features in upcoming versions, and track trouble tickets that can be worked on by the developers and fellow users alike.

A screenshot of the Citadel botnet panel.

The ZeuS offshoot, dubbed Citadel and advertised on several members-only hacker forums, is another software-as-a-service malware development. Its target audience? Those frustrated with virus writers who decide that coding their next creation is more lucrative and interesting than supporting current clients.

“Its no secret that the products in our field — without support from the developers — result in a piece of junk on your hard drive. Therefore, the product should be improved according to the wishes of our customers,” Citadel’s developers claim in an online posting. “One problem is that you have probably experienced developers who ignore your instant messages, because there are many customers but there is only one developer.”

In the following excerpt, taken from a full description of Citadel’s innovations, the developers of this malware strain describe its defining feature as a social networking platform for malware users that is made available through a Web-based portal created by the malware itself.

“We have created for you a special system — call it the social network for our customers. Citadel CRM Store allows you to take part in product development in the following ways:

- Report bugs and other errors in software. All tickets are looked at by technical support you will receive a timely response to your questions. No more trying to reach the author via ICQ or Jabber.

-Each client has the right to create an unlimited number of applications within the system. Requests can contain suggestions on a new module or improvements of existing module. Such requests can be public or private.

-Each client has a right to vote on new ideas suggested by other members and offer his/her price for development of the enhancement/module. The decision is made by the developers on whether to go forward with certain enhancement or new module depending on the voting results.

-Each client has the right to comment on any application and talk to any member. Now it is going to be interesting for you to find partners and like-minded people and also to take active parts in discussions with the developers.

- You can see all stages of module development, if it is approved other members. We update the status and time to completion.

- You may pay a deposit, if module is approved (50%). After the deposit is paid by the members, the project starts moving forward, so that the money is paid directly to coders and there will be no laziness or inaction. Everything is clear: every stage of development is thoroughly shown.

-Easy jabber [instant message] notification of new member or developer comments, or the availability of new custom applications.

The Citadel store lets users file and track bug reports, and request and vote on new features.

Citadel may be the first notable progeny of ZeuS since the ZeuS source code was leaked online last year. The authors claim that it includes a number of bug fixes for the most recent ZeuS version, including full support for grabbing credentials from victims using Google Chrome. Also bundled with this update is a component that can record and transmit videos of the victim’s screen activity.

The basic Citadel package — a bot builder and botnet administration panel — retails for $2,399 + a $125 monthly “rent,” but some of its most innovative features are sold as a la carte add-ons. Among those is a $395 software module that allows botmasters to sign up for a service which automatically updates the bot malware to evade the last antivirus signatures. The updates are deployed via a separate Jabber instant message bot, and each update costs an extra $15.

Citadel also boasts a feature that hints at its creator’s location(s). According to the authors, if the malware detects that the victim’s machine is using a Russian or Ukrainian keyboard, it will shut itself down. This feature is almost certainly a hedge to keep the developers out of trouble: Authorities in those regions are far less likely to pursue the Trojan’s creators if there are no local victims.

The Citadel bot builder.

It will be interesting to see if these malware developers hold true to their word. The growth of a more real-time, user-driven and crowdsourced malicious software market would be a truly disturbing innovation. For now, the miscreants behind Citadel appear upbeat about their chances of ushering in such a reality.

“It’s very interesting for us to work with our clients,” they wrote in an online forum posting. “A lot of authors write in forums that they ‘support the product,’ but at the end the updates only come out once every three months or the author disappears forever. Problem is in author’s motivation. You support us, we support you. It is easy.”

Metasploit Updated: Trivial Access to TFTP

The Metasploit Update is out, and it's a little smaller than you might expect. We've recently rejiggered our development to QA to release workflow here at Rapid7, and that means that this week, we cut the release a couple days earlier than usual in order to ensure the work flow all makes sense and that the releases get the post-commit QA attention that they deserve. The end result is that we'll have a pretty light release this week (due to the shortened development cycle), but going forward, week-to-week changes should hit about the same volume as before.

TFTP Client Library

Metasploit Framework already ships a library for emulating a TFTP server, used mostly for setting up a rogue PXE server. PXE (pre-boot execution environment) is used to deliver operating system configuration details, so by running your own, you can pre-compromise unwary PXE clients. While that's pretty awesome in and of itself, I was kind of amazed to find no reasonable client-side implementation. What if a pen-tester lucks into finding a PXE server that has write access enabled? With the help of community contributor K. Reid Wightman, Metasploit features a new TFTP client library. With this, a penetration tester can now seize control of that legitimate PXE server and provide custom, pre-owned netboot images.

For usage details for the library, just take a peek at auxiliary/admin/tftp/tftp_transfer_util, which provides file upload and download functionality. Of course, you're not limited to merely squatting on PXE servers -- apparently, there are plenty of write-enabled TFTP servers floating around internal networks responsible for all sorts of interesting gear.

Firewall Fingerprinting

Another module of note is Patrick Webster's community submission, the auxiliary/gather/checkpoint_hostname module. This module takes advantage of an information leak present on current versions of CheckPoint's Firewall-1 product, disclosing not only the firewall's hostname, but the hostname of the associated SmartCenter management host. Not only is positively fingerprinting a client's firewall vendor pretty useful for the penetration tester, but getting the management console's hostname for free is an added bonus that can help the pen-tester concentrate efforts on a high-value target.

Perhaps the most noteworthy aspect of this module is that it's apparently 0-day. At first, it looked like a repackage of the 2001 vulnerability described by SecuriTeam, but Patrick insists that it's a) different and b) recent. So, you're not going to find a proper advisory or CVE number or anything for this.

New Modules

The other two modules of note in this release are auxiliary/admin/edirectory/edirectory_edirutil, which leverages the vulnerability described in CVE-2008-0926 to gain unauthorized access to logs and the ability to start and stop services on Novell's eDirectory server, andpost/windows/gather/credentials/razorsql, which is a post-exploitation module that makes quick work of saved database administrator credentials on a compromised workstation.

Availability

For those of you who rely on the msfupdate command to track Framework development, you already have these sitting in your local checkout. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new Framework hotness today when you check for updates through the Software Updates menu under Administration.

For more details on what's changed and what's current, please see Jonathan Cran's most excellent release notes.

Jumping to another network with VPN pivoting

Jumping to another network with VPN pivoting:

VPN Pivoting is one of the best but also most elusive features in Metasploit Pro, so the best way is to see it. That's why I've decided to post a snippet of a recent webinar, where HD Moore shows this feature in action.

VPN pivoting enables users to route any network traffic through an exploited host with two NICs to a different network. For example, you could run nmap, Metasploit network discovery, or Nexpose vulnerability scans through the VPN pivot. Using a TUN/TAP adaptor on the Metasploit Pro machine, the exploited host shows no trace of a new network adapter. This enables you to get full access to a local network after having exploited a single machine, e.g. after a social engineering attack. Here's the video

Note: This video is an excerpt from the webinar about Metasploit 4.1 entitled “What's new with Metasploit? HD Moore's personal tour of the next product version”. To view a recording of this webinar, please visit this page.

IOS forensics using open source tools

Satish Bommisetty has posted a nice article on his blog, on IOS forensics using open source tools. He has done this using iPhone 4G and IOS 5.0. His article can be found here.

Creating an IOC to Spot the Duqu Family

Creating an IOC to Spot the Duqu Family:

Duqu has been getting a lot of attention in the media. According to Symantec, there are 15 confirmed variants found thus far. One of the interesting challenges posed by Duqu is that every instance appears to be unique. Also, the main components are encrypted on disk, therefore restricting our search space to in-memory.

The OpenIOC language is a powerful and flexible tool for detecting both known and unknown evil. So why not leverage it to find all variants of Duqu? In this blog post we’ll take a closer look at Duqu and demonstrate how to create an IOC to spot the entire Duqu family.

It is important to note that when talking about Duqu, there are really two different components; the main module (consisting of the driver and 2 PNF files) and the keystroke logger that Duqu gets its name from. These two entities can run independently of one another, so for this discussion we will focus on the main module. Now let’s walk through Duqu in a logical fashion…

Analyzing Duqu

First we have the infamous Duqu driver. The elusive installer will register Duqu as a service. Each Duqu driver installation has a different file name, a different MD5, a different service name used within the registry, different version information, and different file sizes. Initially it appeared that the driver was always 24,960 bytes long, except for when it was signed, but since then different file sizes have been reported. This makes finding the driver on disk a little daunting, but when the Duqu driver starts executing, things start getting more interesting.

When the driver loads, we can see that it creates two devices (shown here courtesy of Mandiant Redline)

We currently have access to four of the different Duqu drivers. For this blog post we looked at jminet7.sys and cmi4432.sys, along with their corresponding encrypted PNF files, and adpu321.sys and iaStor451.sys (we did not have their PNF components. All four drivers create the Gpd1 device, while two of the drivers create the {3093AAZ3-1092-2929-9391} device and the other two create the {624409B3-4CEF-41C0-8B81-7634279A41E5} device. So Gpd1 seems to be consistent, while the GUID is less so. We will include these facts in our IOC, but we want to find something that is more focused on how Duqu does its magic and that is less likely to change.

With each Duqu driver installation, there will be two files with the extension “.pnf”. One of the PNF files is an encrypted DLL while the other PNF file is an encrypted configuration file. The main Duqu driver decrypts the DLL/PNF file using a key stored in an encrypted registry key (HKLM\SYSTEM\CurrentControlSet\Services\<Duqu_Service_Name>:FILTER). The driver then injects this decrypted DLL into services.exe.

This injected DLL will decrypt another DLL that is stored within its own resource section (named .rsrc in the binary) along with the PNF/config file. The config file will indicate which process to inject the final DLL into. Depending on what that process is, the injected DLL in services.exe will create a new instance of this process and map in the DLL that it decrypted from the resource section. In the examples that we’ve been able to look at so far, the process that is finally injected into has been lsass.exe, winlogon.exe and svchost.exe.

This means there will be a process which meets the following conditions:

1. Named lsass.exe, winlogon.exe or svchost.exe


2. Its parent process is services.exe


3. It does not have a named executable in memory since the main process is overwritten


4. It contains injected code (unnamed section of memory that contains an MZ/PE header).

This can easily be seen by running Mandiant Redline.

Since svchost’s parent should always be services.exe, this is not much of a giveaway, but for lsass and winlogon, it’s definitely abnormal. Lsass’s parent should always be winlogon and winlogon’s parent should always be smss.exe. With this information, we can start writing an IOC that focuses more on how Duqu behaves.

Making the IOC

First, let’s open the MANDIANT IOC Editor and create a new IOC. We start out with a parent OR, meaning that any component under it could be true for a match. Almost all IOCs start out with an OR, which is what the MANDIANT IOC Editor defaults to. We’ll put the pieces from our analysis under this OR to create the IOC that will match against the different parts of Duqu that we’ve observed.

We start our first AND block (items must be true together to make a match) by including the Driver DeviceName Gpd1, since it was the same in all instances that we saw in Redline. We then OR this with the other names we saw, using the OR because we did not see it in all the instances we looked at. This way, the first AND block will match on either Gpd1 by itself, or Gpd1 + either of the unique strings we saw.

Next, we want to describe the injected processes we’ve seen. We have lsass.exe, winlogon.exe, and svchost.exe. Because it could be any of these, we include each one under the parent OR in the IOC, so that the presence of any of them will match (as opposed to all of them having to match, which would require an AND). We describe the specific conditions for each process in an AND block, since we want all the conditions in each section to be true for a match.

We’ll take the case where the process name is lsass.exe, and we’ll combine it with our conditions from above. Currently, we can describe the process name, the fact that there is no section name in memory because it was overwritten, and the fact that it contains injected code. Under an AND, these all have to be true to give us a match for lsass.exe:

We’ll repeat the process for winlogon and svchost:

While reversing the injected DLL within services.exe I noticed that it should have created a mutex ({0de1ac9d-35da-433f-937a-8553016874f1}) and 2 events ({0df29544-7ded-4091-a8e6-b87402e6064c}2 and {92D9FA5C-D148-476E-BCC9-A4BEAC2E70D7}). I was able to confirm that services.exe contained references to these 3 handles, something else that we should add to our IOC. Unfortunately, even though we had access to 4 of the drivers, we only had access to 2 sets of PNF files that we were able to decrypt. Due to this, we are not able to tell if these change with the different variants, but these handles are seen in both of the variants that we do have.

Let’s add this additional information to the IOC. We create another AND block and include under it the fact that we are looking at services.exe, that is injected, and the handle names that were uncovered:

There are some publicly available bits of information from other analysts who have looked at Duqu. It is always a good practice to test your IOCs on real data before doing wide deployment of them – this is especially true when using data gathered from third parties. But in certain cases, samples of some malware may not be easily available and/or you may wish to make IOCs to search for malware that you don’t have specific samples of yet. Make sure to keep good testing practices in mind when you make all IOCs –especially for data you didn’t gather yourself. IOC Finder can be used as a tool to test against a standard build as a control, as well as looking at infected boxes to see if you are finding malware.

One publicly documented variant was signed by C-Media Electronics Incorporation. We will include that information in a separate AND block:

Symantec also released some items on what the installer might leave behind on a host:

1. The existence of the registry entry:
   
   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\4\”CFID” (though Kaspersky claims that it is really “CF1D”, so we’ll include both so we don’t miss anything)


2. The existence of an event log entry with an EventID of 3221235481, event type of 1 and event source of DCOM

Thanks to Symantec for this information. Registry keys and event log entries are easily describable in OpenIOC, so we will add those in as well:

After having tested this in the field, we’ve rearranged the IOC slightly differently than the order we’ve just gone through, however the components are the same. Putting this all together, here is our IOC for Duqu:

The IOC we created can be downloaded here:

http://openioc.org/iocs/72669174-dd77-4a4e-82ed-99a96784f36e.ioc

We hope this has been useful. If you have comments or questions, please drop a post in the MANDIANT Forums: https://forums.mandiant.com/tags/ioc or leave a comment here on the blog.