Follow Slashdot stories on Twitter


Forgot your password?
Crime Software IT

Source Code Leaked For Tinba Banking Trojan 75

msm1267 (2804139) writes "The source code for Tinba, known as the smallest banker Trojan in circulation, has been posted on an underground forum. Researchers say that the files turned out to be the source code for version one of Tinba, which was identified in 2012, and is the original, privately sold version of the crimeware kit. Tinba performs many of the same malicious functions as other banker Trojans, injecting itself into running processes on an infected machine, including the browser and explorer.exe. The malware is designed to steal financial information, including banking credentials and credit-card data and also makes each infected computer part of a botnet. Compromised machines communicate with command-and-control servers over encrypted channels. Tinba got its name from an abbreviation of "tiny banker," and researchers say that it's only about 20 KB in size."
This discussion has been archived. No new comments can be posted.

Source Code Leaked For Tinba Banking Trojan

Comments Filter:
  • by SeaFox ( 739806 ) on Sunday July 13, 2014 @04:38AM (#47441479)

    Remind me again why a free, "superior" operating system couldn't gain any appreciable market share in the consumer space

    Because consumers will generally buy what they're convinced they should by marketing before they get off their butts and actually do research and then make choices. Windows has a major corporation pushing out advertising backing it. Whereas for much of Linux's existence it's coding was a volunteer effort, let alone having paid marketing. Why did Betamax, the superior video cassette tape format, lose to beta? The consumer space was flooded by JVC pushing licensing to anyone, unlike the more restrictive Sony -- gee, kinda like IBM/PC vs Macintosh.

  • by ComputerGeek01 ( 1182793 ) on Sunday July 13, 2014 @10:04AM (#47442453)

    Damn it, you're going to make me burn the mod points I have already spent in this thread to educate the other *nix fan boys like you. First of all Windows offers a boat load more process memory protection then most other major Linux distros out there which is why DLL injection is necessary in the first place where as in Linux I can just dump the data I want from any memory page I damn well please once I'm running on the remote system. UAC may have been a bit late to the game but it's here now. However despite this solid protections scheme Windows must still remain functional for developers, so the WinAPI is forced to offer some method of run-time debugging for most processes (it does NOT allow this for all of them; things like csrss and lsass are off limits). DLL injection is accomplished by first locating the load point of the Kernel32 DLL in the target process and then going to the offset where the exported GetProcAddress() and LoadLibrary() functions are and invoking them through CreateRemoteThread(). Before even that occurs though the strings that all three of those functions rely on have to already be present in the remote process, this is done with first allocating the memory with VirtualAllocEx() and then writing to it with WriteProcessMemory(). In order for any part of this operation to be possible the end user would have had to of allowed the infection to enable the SeDebug privilege for the malicious process in the first place. Meaning that at some point the end user f***ed the pooch all on their own without Evil Old Microsoft having done anything stupid. Further more absolutely NONE of this would be in the slightest bit relevant if the information was encrypted in process to begin with and that is the fault of the banking systems software vendor. So get off of your wooden high horse, a well documented API being utilized by incompetent third parties is not an insecure one.

If a 6600 used paper tape instead of core memory, it would use up tape at about 30 miles/second. -- Grishman, Assembly Language Programming