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.
Subscribe to:
Posts (Atom)