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:
  • 20k (Score:5, Funny)

    by Anonymous Coward on Saturday July 12, 2014 @11:51PM (#47440921)

    this makes the trojan the least bloaty program on the average windows PC.

    • Re:20k (Score:5, Insightful)

      by CaptnZilog ( 33073 ) on Sunday July 13, 2014 @12:25AM (#47441019)

      If we could get the hired at MS maybe windows could run on a 256M machine. :P

    • With a size that small, I have to assume the security hole in windows is either really huge, or the virus is written in assembly.
      • by Anonymous Coward

        It's both.

        TFA [] confirms that it's written in assembly and saying that the security holes in Windows are really huge, well, that's just common knowledge.

  • For writing an article about IT-criminals in which he refers to them as IT-criminals.

    Even if it does appear on a page with a prominent link to another article which misuses the term 'hackers' in its very title. I am sure that was beyond his personal control.

    Also it sounds like some really good programming! 20kb compiled, and full functional. From <a href="">this report</a> it appears that it's written in assembler. Does anyone have a link to the actual code?
  • by Anonymous Coward

    Hold me closer Tiny Banker...

  • Trojan Man?
  • Tinba! (Score:4, Funny)

    by Anonymous Coward on Sunday July 13, 2014 @12:22AM (#47441011)

    His arms wide...

  • by Animats ( 122034 ) on Sunday July 13, 2014 @03:38AM (#47441351) Homepage

    Remind me again why Windows has the capability to "inject" a new DLL into a running process from outside the process.

    • by Anonymous Coward on Sunday July 13, 2014 @03:48AM (#47441369)

      I'm sure the NSA will let us know is due course.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      One reason could be to have the ability to extend the functionality of other programs. For example, back in the MSN Messenger/Windows Live Messenger days, there was a program called Messenger Plus!, which added lots of functionality to MSN/WLM. I don't think it would had been possible without DLL injection.

    • by Anonymous Coward

      Doesn't even need to be a DLL. You can allocate memory in a remote process via virtualalloc and the put you malicious code in the other processesemory. From there you just use createremotethread and bobs your uncle, your running your code from inside another application with full access to its memory space.

    • by Anonymous Coward

      Since it is useful for extending programs you do not have the source of. We use it a lot in our company to make measurement software write to an OML database without having to screenscrape its windows.

      You can do this with linux too, via /dev/(k)mem, but it is much less clean.

      • by Anonymous Coward

        no need for that. you just use LD_PRELOAD.

    • by Anonymous Coward

      One I've often wondered about myself. Makes NO sense coming from an EXTERNAL process (ala viruses), since yes, the DLL is sensible to have around in & of itself (to extend a program AND entire OS with an "object-oriented" if not "object request broker" style statndardized function set that's proven paradigm, via say, the LoadLibrary API function (not sure if THAT is the Win16/32/64 PE call specifically, especially out of kernelmode native API that is (even NTDLL has LoadLibrary though iirc... however, I

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

      • by Anonymous Coward

        Sounds like swe have a faggot M$ $hill here. Someone downmod this faggot. I disagree.

    • by Nkwe ( 604125 )

      Remind me again why Windows has the capability to "inject" a new DLL into a running process from outside the process.

      Because if you have root you can do anything (technically possible).

  • is plenty after all.

  • by ledow ( 319597 )

    It's not difficult to write a malicious program that can steal data as the user it runs. In fact, it's trivially easy, and your homebrew program will almost certainly avoid every antivirus signature with the minimum of tweaking and testing.

    Exploiting holes is harder, but there's always a PoC code somewhere if you dig enough, especially if you are subscribed to security lists. And there you might have to do a little tweaking/testing but with VM's and debugging toolkits, it's not hard for any proficient pro

  • For those who are interested, here is a link [] to the post on opensc that contains the source code download. You will need to register for an account before downloading.
  • What's wrong with those Trojan authors nowadays? There are whole programming language implementations that run in less than 20KB!

    Don't they code in assembler any more?

All Finagle Laws may be bypassed by learning the simple art of doing without thinking.