We are the champions, my friends

Results of a lengthy real-world malware protection study are published here.

Run, Chrome OS! Run!

It seems that the news on Chrome OS release have left no one neutral; some observers are beating the drums of its imminent failure and premature death, by relying on rather oversimplified concepts of cloud computing and insinuating about the reasons why careless moms and dads just can't grasp the concept of strong passwords ("how many times did we tell them to memorize Qp%n#82r$7D, but they keep writing it down on a piece of paper or even worse - keep choosing 12345?").

From the point of view of these observers, the new security model of Chrome OS is not much different from this:



Let's step back for a moment and try to give it a fresh and fair look. Let's also keep in mind that many good projects make their way into our lives by having 3 stages of its public perception: strong criticism (almost always, and that's where many fail), gradual, painful at start, then easier adoption, followed with a final stage that can be characterized as "Well, what's so special about it?". We don't want to fall the victims of the first stage, no matter how natural for humans it is, right?

Well, Google claims that under Chrome OS hood "all apps are web apps". Boo! But hold on a second, isn't it already true for Hotmail, Skype, online banking, and lots of other online web services that we are relying on so much every day?

Now come into a computer store (mentally) and look (again, mentally) at the average mom and dad who want to buy a new computer. Is it really a surprise to learn that most they're going to use it for will be "web apps" anyway, such as web, email, IM/chat/forums, Internet phone, documents editing/printing (bills/taxes/records), personal finance services (online banking, trading stocks), online gaming, etc. ?

Sure enough, with a web-only machine they won't be able to scan documents, but given the market exists, there will be dedicated scanners for the home users that will scan the documents and send the images over to their online accounts. They won't be able to listen or watch CD/DVD, but there are specialized devices that do it better anyway. They won't be able to play games with the powerful graphics, but there are plenty of gaming consoles for that purpose too.

Somehow it comes to a point – would you prefer to have a TV, a DVD/BD player, and a sound system as dedicated stand-alone devices, maybe from the different brands, or have all of them combined in one (cheaper) device? Would you prefer to have a printer, a scanner, and a telephone as separate devices, or a combined (cheaper) unit?

If you choose the second option, then you must really adore your phone's camera! If you choose first, even if it's a pricier option, doesn't it sound reasonable to have a dedicated device to handle web-only services?

For start, let's stick to just one such service – Internet Banking. Imagine having a dedicated 100% secure tiny netbook that allows you to bank online. It boots in 10 seconds and it can't run malware by design. Sure enough, hackers will try hacking a device like that to run Windows on it, but that won't be YOUR DEVICE. If your device gets stolen, it's useless – it stores nothing and you can't be impersonated with it. If you spill hot coffee on it and it shuts down instead of running faster, you'll buy another one (not coffee, netbook). Will it give you an extra hour of a good night sleep by knowing that no hacker can compromise your online banking account?

Now try to imagine how many threat families (keyloggers, banking Trojans, rootkits) instantly become irrelevant for you. Even if your other computer gets compromised with them, the only valuable thing the hackers might eventually steal from you will be a serial number of your antivirus product.

If you love your netbook, you might extend its application to online shopping or online trading. Then to anything that's online and is asking you for a password from that little soiled notes book from the middle section of your wallet. Extending its application further becomes a dangerous business as a flaw in one web service may affect your other services (e.g. a phishing email may affects your online banking account if you do both on one machine), just like it's not wise to put all your eggs in one basket.

The security overview of Chrome OS is an interesting read.

By openly discussing the security challenges and suggested approaches to circumvent them the Chrome guys talk to us this way:

"Look, in our bank there is a vault with so much gold in it. The system is secure, but we're not sure about that air con duct – we think it's a weak point and the intruders may potentially crawl through it".

Given the source code is open, the potential intruders will get access to the internals' scheme immediately. But the moment they start studying it, the highly qualified white-hat professionals will start doing that as well. The idea is that any bugs, flaws or weaknesses will be revealed and fixed instantly, without leaving the intruders any chance to plan an attack.

Compare it with an alternative approach: "Look, in our bank there is a vault with so much gold in it. The system is secure." After the robbery: "The system is secure." After another one: "Ok, we fixed it, the system is secure", and so on.

With the security being the main cornerstone of Chrome, it's a step away from the "traditional" development philosophy that we all are used to: "make it usable and release it first, think about security later, when the bugs/flaws are discovered". Usability being priority #1 creates a cash flow that allows investing into security and fine-tune usability at a later stage. The problem with this approach is that when under-invested security fails, usability falls with it. Not just declines, but crashes spectacularly.

The only company that can afford to have security in the first place, in the blueprints, even before the developed software becomes available for users, will likely have a "cash cow" in a different product or solution. Otherwise, it will be trapped in a vicious circle when the product is not released because its model is not secure enough, thus there are no sales and therefore, no funding to make it secure enough to be released. Google's "cash cow" is in its ads program, giving it all the required conditions to build a truly secure OS.

Not an OS that replaces all other OS (this will never happen), but at least an OS that can safely and narrowly be used for those critical web-only applications that create so much headache for the customers in terms of stolen identity and money.

Will Google blow this chance or not, time will tell.

Dissecting Limbo Dropper [old]

A routine laptop clean-up revealed a few month old video of unpacking the Limbo trojan dropper. Before it gets deleted, posting it here just in case some folks might find it useful [link to video].

PS The sample was received from Michael Hale Ligh. Thanks, Michael.

The New Moon Trojan

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

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

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

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

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

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

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

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

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

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

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

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

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).