Linux “HoT” bank Trojan: Failed malware

Linux “HoT” bank Trojan: Failed malware

Summary: What? Another Linux vulnerability? Nope. Other operating systems may be easy malware marks, but Linux continues to resist malware.


Initially it looked like the "Hand of Thief" (HoT) Trojan would be the first successful Linux Trojan. However, further investigation by RSA, the Security Division of EMC, reveals that the Hand of Thief is just another in a long line of so-called Linux malware that's more bark than bite.

Hand of Thief: Another failed Linux malware program. (Credit: RSA)

Indeed, the only people who will be hurt by this so-called Trojan are the cyber-criminals who paid $2,000 for this half-baked hack.

Yotam Gottesman, an RSA Senior Security Researcher, reported that the company obtained the HoT code builder and created HoT binaries. Gottesman reports that HoT has no real functionality. "Our research and analysis shows that, in reality, HoT’s grabbing abilities are very limited if not absent, which would make the malware a prototype that needs a lot more work before it can be considered a commercially viable banking Trojan."

My own experiences with HoT demonstrated that while I smelled smoke, there was no fire. It is just a harmless exploit of a since-patched problem with the Chrome Web browser.

HoT's builder--the part that actually creates the virus--is a Windows program. In theory the builder would enable the botmaster to generate new variants of HoT. It created 32-bit compiled ELF (Executable and Linking Format) programs. ELF is the standard Linux binary format.

Once installed, HoT would seek to grab information from Web forms and send the results to a botnet server. As malware, however, HoT fails in the most fundamental way possible: It requires a deliberate effort by the user to install it.

On some operating systems, such as Windows, it's relatively easy to infect a system without the user being aware that anything is happening. On others, such as Android, the user must agree to install a program. With Linux, you must go out of your way to install any program. HoT has no mechanism to make that any easier for a criminal cracker.

In fact, even if you do take the time and effort to infect a Linux PC with HoT, the program still doesn't work worth a damn. RSA found that HoT often crashed with Firefox on Fedora, grabbed useless data with Chrome on Fedora, and was blocked from running at all on Ubuntu Linux.

Therefore, RSA concluded, "HoT has come to the cybercrime underground at a time when commercial Trojans are high in demand, stirring some excitement amongst criminals. Although it initially appeared to be a compelling new Trojan entrant, RSA’s in-depth analysis of the code proves it is a prototype more than true commercially viable malware, crashing the browsers on the infected machines and displaying overall inability to properly grab data."

As for that critical issue of infecting Linux systems, "HoT's developer claims that he is in the final stages of implementing a Web-injections mechanism, but since the Form grabber he designed is not functional on the browsers he claims to have tested, the injections are not very likely to work either."

I'll take that a step farther. The only people who have, or ever will have, trouble with HoT are the would-be crooks who bought this hopelessly maimed malware.

Related Stories:

Topics: Security, Linux, Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • LOL

    "... The only people who have, or ever will have, trouble with HoT are the would-be crooks who bought this hopelessly maimed malware."

    Good. It serves the bastards right.
    Hallowed are the Ori
  • Article: "[HoT] was blocked from running at all on Ubuntu"

    According to RSA, HoT was blocked because in Ubuntu 12.04 'ptrace scope' is enabled by default:

    It's noteworthy that the Linux kernel was patched in 2010, allowing for the restriction of ptrace scope:
    "As Linux grows in popularity, it will become a larger target for
    malware. One particularly troubling weakness of the Linux process
    interfaces is that a single user is able to examine the memory and
    running state of any of their processes. For example, if one application
    (e.g. Pidgin) was compromised, it would be possible for an attacker to
    attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
    etc) to extract additional credentials and continue to expand the scope
    of their attack without resorting to user-assisted phishing."

    And the link to Ubuntu's description of 'ptrace scope':

    Clearly, this is a very good security feature implemented by Canonical in Ubuntu. But, I wonder, how many distros besides Ubuntu enable 'ptrace scope' by default? Steven?
    Rabid Howler Monkey
    • You have also linked to the answer to your own question.

      "It's noteworthy that the Linux kernel was patched in 2010, allowing for the restriction of ptrace scope:"

      Hmm, you have linked to a discussion on the linux-kernel mailing list where Kees Cook posted his patch. And when I say "discussion", I mean that there are also a *lot* of replies and comments about the patch from core kernel developers, mostly along the lines of "This should have been implemented as a security module" and "Why not just enable SELINUX?"

      So I'm not sure that the 'ptrace scope' patch was actually applied to the mainstream kernel after all.
      • Zogg: "'ptrace scope' ... mainstream kernel"

        The Yama LSM, which includes ptrace scope limitations, was placed in the mainline Linux kernel in 2010:

        However, not all distros (e.g., Debian Wheezy or stable) have enabled the Yama LSM:

        "Bug#704750: src:linux: Please enable Yama LSM

        It also appears that enabling and disabling ptrace varies by distro (e.g., SELinux on Fedora, /proc/sys/kernel/yama/ptrace_scope sysctl on Ubuntu).
        Rabid Howler Monkey
    • Oh look, a Ubuntu FAQ on the subject...

      Ironically, you need to *disable* ptrace scope in Ubuntu in order to run Windows programs via Wine! So I'm thinking that the ptrace scope patch is specific to Ubuntu.
      • Zogg: "I'm thinking that the ptrace scope patch is specific to Ubuntu"

        Which leads to my original question, which I'll repeat for your benefit: "I wonder, how many distros besides Ubuntu enable 'ptrace scope' by default?"

        Some preliminary searching leads me to believe that Linux Mint, a popular Ubuntu derivative, also has 'ptrace scope' enabled by default. But, what about Mint Debian Edition that is derived from Debian unstable? And what about Debian stable/testing and other Debian derived distros?

        Here's a relevant link for Fedora:

        Note that ptrace appears to be disabled by default. Which means that it's also likely disabled by default in CentOS, a popular Red Hat Enterprise Linux derivative.

        Regarding a Linux Security Module for enabling 'ptrace scope' by default, it has a name, "Yama", at least in Ubuntu (and also, I believe, in Linux Mint).

        Finally, here's a link to a fairly recent Linux Mint thread which indicates that Banshee and Rhythmbox also have a problem running with 'ptrace scope' enabled:

        "Banshee and Rhythmbox work only with root user
        Rabid Howler Monkey
        • The point being that this patch was probably NOT included in 2010.

          The patch you are referring to appears to be "out-of-tree", making your claim that it was applied in 2010 incorrect.

          As an "out-of-tree" patch, it is therefore "not applied" by default. Which isn't to say that alternative security modules such as SELINUX aren't enabled instead.
          • Wrong

            The Yama LSM, which includes ptrace scope limitations, was placed in the mainline Linux kernel in 2010.

            See my post above.
            Rabid Howler Monkey
          • FYI: The patch you linked too was rejected.

            However, ptrace scoping is part of SELinux.

            Perhaps the correct (rhetorical) question you should be asking is "How many people run with SELinux enabled?".
          • The Yama LSM was added to the Linux 3.4 mainline kernel in May, 2012

            See '1.8. 'Yama' security module' in this link:


            And in December, 2012, the Yama LSM was made unconditionally stackable (with other LSMs such as SELinux and AppArmor) in Linux kernel 3.7:


            Rabid Howler Monkey
          • Except that your original link was NOT to the 'Yama' patch.

            Geez, get your links straight!
          • Can't see the forest for the trees?

            Your attempt at deflection here does not alter the fact that ptrace should be disabled by default on modern GNU/Linux distros (with an easy way for developers to enable the feature when needed for debugging). Just as Canonical has done starting with Ubuntu 10.10 in October, 2010.

            And, btw, why didn't Fedora's SELinux stop HoT in it's tracks as Ubuntu did? Could it be that on Fedora 19 ptrace runs unrestricted, meaning that the ptrace protection available through SELinux is disabled by default? Good thing for Fedora users that HoT is not prime time yet.
            Rabid Howler Monkey
          • Why keep asking rhetorical questions?

            "And, btw, why didn't Fedora's SELinux stop HoT in it's tracks as Ubuntu did?"

            No idea - why not ask *them* about the status of SELinux on the box *they* tested?
          • Glad that i moved to Linux...

            ... about six years ago. Since that computing have been secure, stable, nice, easy and cheap.

            Let these Windows-fanboys boil in the oil.
            Napoleon XIV
  • Only living creatures get sick and tired.

    Machines don't.
  • Our respected Windows protagonists and Linux antagonists

    will probably say, "your Linux is so user unfriendly, that even malware refuses to cooperate." And I would agree with that part. GNU/Linux and *BSD (even MAC OS X, when Apple is being idle and not stupid) are designed to be very unfriendly to malware.
    • Wrong

      Canonical had to 1) add a Linux Security Module (named "Yama") to Ubuntu and 2) set 'ptrace scope' to a value of '1'. You see, the malware was stopped it its tracks when it tried to run in Ubuntu. Not so for Fedora.

      Hopefully, other Linux distros will follow Canonical's lead with Ubuntu: adding the Yama Linux Security Module and enabling 'ptrace scope' by default.
      Rabid Howler Monkey
  • Pretty obvious really

    In the original Hand of Thief article I said this would likely become just another proof of concept Linux malware, not only does it have no good ways of infecting Linux users and no real functionality, but it doesn't even run properly.

    They should stick to writing malware for windows, where infection is easy.
  • Changes

    It's hard to infect an OS (Linux) when it's constantly changing due to bug fixes and Kernel updates. Whereas in Windows, that OS is always built on the previous version; so you have the same OS every time with a new GUI and bloated services added to counteract the sorry state of the code.

    Off-topic, but at the recent PAX, developers said their #1 wish was for GPU manufacturers to abandon DirectX. DirectX of course, is a lock-in for Windows and makes it hard to make games Multi-Platform. They recommended what everyone else, outside of who Microsoft pays, to use OpenGL -- the industry standard.

    Sorry folks but times are changing. Windows isn't center stage anymore for Games or Desktop usage. I hate to beat a dead horse, but we all know now about the hard-coded NSA Trojan in Windows. A user said to me this morning they were scared of getting a Virus in Windows from the Net; I just had to laugh knowing they were either ignorant or don't read the news.

    Why worry about about a Virus when one is hard-coded into the OS and stealing all your Skype logs and passwords?.
    Mike Frett
    • kinda sorta...

      "Whereas in Windows, that OS is always built on the previous version; so you have the same OS every time with a new GUI..."

      Actually, it's the windows API versus unix/Linux's ELF. Both don't change much, but they are fundamentally different approaches vis writing apps that'll run. The 'constant updates' to the kernel etc doesn't fundamentally alter the way apps need to be written and how they run. So Linux is equal to windows in the direct comparison you made, so far as any changes due to updates. It's the windows API that has the popularly exploited bits.