The Wayback Machine - https://web.archive.org/web/20150723043658/http://blog.trendmicro.com:80/trendlabs-security-intelligence/hacking-team-uses-uefi-bios-rootkit-to-keep-rcs-9-agent-in-target-systems/
Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro


  • Zero-Day Alerts

  • Hacking Team Leak

  • Recent Posts

  • Calendar

    July 2015
    S M T W T F S
    « Jun    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • Email Subscription

  • About Us

    The dissection of the data from the Hacking Team leak has yielded another critical discovery: Hacking Team uses a UEFI BIOS rootkit to keep their Remote Control System (RCS) agent installed in their targets’ systems. This means that even if the user formats the hard disk, reinstalls the OS, and even buys a new hard disk, the agents are implanted after Microsoft Windows is up and running.

    They have written a procedure specifically for Insyde BIOS (a very popular BIOS vendor for laptops).  However, the code can very likely work on AMI BIOS as well.

    A Hacking Team slideshow presentation claims that successful infection requires physical access to the target system; however, we can’t rule out the possibility of remote installation. An example attack scenario would be: The intruder gets access to the target computer, reboots into UEFI shell, dumps the BIOS, installs the BIOS rootkit, reflashes the BIOS, and then reboots the target system.

    We’ve found that Hacking Team developed a help tool for the users of their BIOS rootkit, and even provided support for when the BIOS image is incompatible:


    Figure 1. Technical support provided by Hacking Team

    In installation, three modules are first copied from an external source (this might be from a USB key with UEFI shell) to a file volume (FV) in the modified UEFI BIOS. Ntfs.mod allows UEFI BIOS to read/write NTFS file. Rkloader.mod then hooks the UEFI event and calls the dropper function when the system boots. The file dropper.mod contains the actual agents, which have the file name scout.exe and soldier.exe.


    Figure 2. Files copied when the UEFI BIOS rootkit is installed

    This means that when the BIOS rootkit is installed, the existence of the agents are checked each time the system is rebooted. If they do not exist, the agent scout.exe is installed in the following path: \Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\6To_60S7K_FU06yjEhjh5dpFw96549UU. 


    Figure 3. The RCS agents installed in the target systems>

    Although the dropper checks the existence of soldier.exe, it does not install the file for some unknown reason.


    Figure 4. Scoute.exe (the agent’s name in debug mode) is deployed to every user in \Users\[username]\Appdata


    Figure 5. Deployment of scoute.exe

    This finding is only the most recent among the numerous discoveries triggered by the Hacking Team leak. So far, three Adobe Flash zero-day vulnerabilities have been discovered from their files, although this particular finding gives more context on their activities. While we are not certain of who have been affected, the fact that the group dubs the tool “The Hacking Suite for Governmental Interception” which clarifies for whom the tool is intended.

    To prevent being affected by this, we recommend users to:

    • Make sure UEFI SecureFlash is enabled
    • Update the BIOS whenever there is a security patch
    • Set up a BIOS or UEFI password

    Admins managing servers can also opt to buy a server with physical BIOS write-protection, wherein the user will need to put a jumper or turn on a dip switch in order to update the BIOS.

     

    Timeline of posts related to the Hacking Team

    DATE UPDATE
    July 5 The Italian company Hacking Team was hacked, with more than 400GB of confidential company data made available to the public.
    July 7

    Three exploits – two for Flash Player and one for the Windows kernel—were initially found in the information dump. One of these [CVE-2015-5119] was a Flash zero-day.

    The Windows kernel vulnerability (CVE-2015-2387) existed in the open type font manager module (ATMFD.dll) and can be exploited to bypass the sandbox mitigation mechanism.

    The Flash zero-day exploit (CVE-2015-5119) was added into the Angler Exploit Kit and Nuclear Exploit Pack. It was also used in limited attacks in Korea and Japan.

    July 11 Two new Flash zero-day vulnerabilities, CVE-2015-5122 and CVE-2015-5123, were found in the hacking team dump.
    July 13 Further analysis of the hacking team dump revealed that the company used UEFI BIOS rootkit to keep their Remote Control System (RCS) agent installed in their targets’ systems.
    July 14 A new zero-day vulnerability (CVE-2015-2425) was found in Internet Explorer.
    July 16 On the mobile front, a fake news app designed to bypass Google Play was discovered.
    July 20 A new zero-day vulnerability (CVE-2015-2426) was found in Windows, which Microsoft fixed in an out-of-band patch.
    July 21 Analysis of the RCSAndroid spying tool revealed that Hacking Team can listen to calls and roots devices to get in.




    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon




    • KevinD

      Hello everyone. As an employee of Insyde, I’d like to share the following:

      ————————————————————————————–

      Insyde and other UEFI companies have reviewed the referenced hacks. Some companies have shared their analysis with Insyde.

      Insyde believes that the publicly released ]Hacking Team[ code and tools are using vulnerabilities that have since been mitigated. Recent InsydeH2O BIOSs do not have these issues. Security initiatives that were added to the UEFI 2.3.1 specification were added to the InsydeH2O code in 2012 to provide protections against this type of attack. Insyde works with the UEFI Forum to actively improve security on UEFI based PCs, tablets, servers, and embedded equipment.

      It appears that ]HT[ was using a stolen copy of an older version of the
      Insyde toolkit.

      Insyde works with our silicon vendor partners to increase protections on future platforms. Insyde believes that new technologies in new generations of processors and chipsets on UEFI based PCs, tablets, servers, and embedded equipment using security co-processors will increase the protection against BIOS hacks even more.

      Insyde works with all of the major OEMs and ODMs to reduce the risk of attacks on systems that use InsydeH2O products. OEM and ODM customers are advised to contact their Insyde support representative for documentation and assistance.

      An end user can protect their system by adding a BIOS password and by ensuring that SecureBoot is enabled. End users are advised to contact the manufacturer of their equipment if they suspect their equipment has been compromised.

      Security researchers are encouraged to report any vulnerabilities directly to Insyde
      using the contact information available on our website.

      ————————————————————————————–

      As a fellow end user and an Insyde employee, I’d like to thank everyone on this thread so far. This discussion has been intelligent, factual, and reasoned.

      One thing missed in this discussion is that there are a number of protections against writing to the BIOS storage devices. They are designed so that it’s not possible to disable these settings from a Windows user level app or even from a Windows kernel or driver level. I’m pretty sure the designers got these bits correct.

      Writing to the FV at run-time _shouldn’t_ be possible. If it is, then someone didn’t set all of the access protection bits correctly.

      • Adam

        Hello KevinD!

        I would ask one question. Does a simple BIOS upgrade and HDD zero-fill remove that rootkit completly from a laptop system or not?

        Is it sufficient or the rootkit hijacks BIOS firmware write calls with it’s own code?

        • KevinD

          Adam,

          There are no indications that this rootkit tries to stay persistent during a reflash of a system BIOS.

          A simple means of detection of an infection is to query your UEFI Variables for one named fTA.

          A BIOS update from your system vendor’s website should be enough to clear this infection from the BIOS.

          A review of the user files can provide an indication that the OS was infected. An OS install from clean media should be enough to remove the infection.

    • Cheryl Lintz

      Has anyone heard of the company Cenit Business Solutions LLC?

    • http://about.me/ariccio Alexander G. Riccio

      Did Hacking Team *ever* use `const`?? I’m surprised that nation-state grade malware ignores the *most* basic good software engineering practices.

      • 民主女神

        It’s because, Trend Micro just manage to scratch the surface tip of the iceberg. Someone with business model created around “offensive security” would never put their eggs all in one basket at any given time :)

      • TrendLabs

        Hi Alexander,

        I wouldn’t comment on their coding style. You can check the source code on Github: https://github.com/hackedteam/vector-edk

        To be frank, their technical skill is undeniable.

        – Philippe

        • http://about.me/ariccio Alexander G. Riccio

          > To be frank, their technical skill is undeniable.

          Well, that doesn’t mean that they’ve written good code with their skills 😉

          Hmm. Now I’m curious, the solution files that are posted on GitHub (aside from using vs2008) don’t seem to use static analysis.

          Has anybody tried to build with VS2013, with /analyze? I’m away from home, so I can’t – but it’d still be quite interesting to see if any nasty mistakes are in their code base!

          P.S. I really like how attentive you are to the comments. It’s great for the community as a whole.

    • Michael

      Since this is a UEFI *BIOS* rootkit, presumably a legacy free UEFI is not affected and it should be possible to protect yourself by disabling the BIOS backward compatibility options; it is usually called CSM / “Compatibility Support Module” in the UEFI menus.

      • TrendLabs

        Hi Michael,

        The persistence vector works on 64bit UEFI. Therefore, it doesn’t help to turn off CSM. Moreover, according to Wikileaks (HT’s email dumps), they have tested the vector against the following laptops and they believe it works on most laptop and desktop computers.

        1] Dell Latitude 6320
        2] Dell Precision t1600
        3] Asus X550C
        4] Asus F550C

        They have mentioned several issues on Toshiba and Acer.

        I hope this helps!

        -Philippe

    • Slim Amamou

      > we can’t rule out the possibility of remote installation. An example
      attack scenario would be: The intruder gets access to the target
      computer, reboots into UEFI shell (…)

      The intruder has no access to the target over network at this point. Hence the necessity of physical access to the machine

      • HaKr

        It seems that this could be installed remotely if not for Secure Boot. If Secure Boot was disabled, then a Windows virus could mount the manufacturer’s UEFI partition and edit the firmware to add their code. However, the Secure Boot signing could get in the way of running the code. However, if you have physical access, it is trivial to disable Secure Boot and manually add the rootkit.

        • TrendLabs

          Hi HaKr,

          There are two things: Secure Boot [3] and “Signed Firmware Update”.

          This is not the case of HT’s persistence vector. They put rkloader.mod and dropper.mod in a EFI file volume (FV), and not a UEFI partition on the hard disk. However, we should elaborate a bit on the question.

          First of all, Windows 8 / 8.1 / 10 warns you if you turn off
          secure boot. So they cannot turn off the option in BIOS configuration. Once Secure Boot is enabled (a common practice in the age of Windows 8, because it’s prerequisite to pass Windows “Logo” certification), theoretically, every firmware and option ROM loaded during system boot are checked for valid signatures.

          However, in the reference UEFI implementation, drivers on FV
          (hence on SPI, a chip where UEFI BIOS is stored) is allowed to execute without any authorization. [1]

          But there is an important question: How does HT flash infected
          UEFI firmware back to SPI? Many vendors have implemented “Signed Firmware Update” which checks BIOS signature and refuses to flash the firmware if the signature does not match. As we can see from a list of HT “tested” laptops (refer to Q2), the models support “signed firmware update” only if user upgrades the BIOS to a
          more recent version. [2] Therefore, there’s nothing preventing them from installing the bootkit into FV.

          There is still ways to break “signed firmware update”, as a MITRE study showed. [4]

          We have noticed that Intel Security’s chipsec scripts are included in HT’s code. For more information, refer to their presentation to DEF CON 22. [5]

          References:
          [1]https://www.syscan.org/index.php/download/get/6e597f6067493dd581eed737146f3afb/SyScan2014_CoreyKallenberg_SetupforFailureDefeatingSecureBoot.zip
          [2]http://en.community.dell.com/techcenter/extras/m/white_papers/20287278/download
          [3]https://technet.microsoft.com/en-us/library/hh824987.aspx
          [4]http://www.mitre.org/publications/technical-papers/defeating-signed-bios-enforcement
          [5]https://media.defcon.org/DEF%20CON%2022/DEF%20CON%2022%20presentations/Bulygin,%20Bazhaniul,%20Furtak,%20and%20Loucaides%20-%20Updated/DEFCON-22-Bulygin-Bazhaniul-Furtak-Loucaides-Summary-of-attacks-against-BIOS-UPDATED.pdf

      • TrendLabs

        Hi Slim Amamou,

        The intruder can use other ways to gain remote access (spear-phishing, vulnerabilities, malware, 0day) and theoretically it is not impossible to flash the UEFI once you become administrator. However, (as discussed in their leaked email), there are nuances among UEFI firmware releases and differences among laptop’s models and brands. Therefore, it is a safer play to gain physical access. If you remotely turn a laptop into a brick (i.e. failure in re-flashing the UEFI firmware), the victim can become really alerted.

        Another proof is that in uefi.py, they call “insyde.dll”, a Windows DLL that
        updates Insyde BIOS (a very popular BIOS for laptop). The whole process
        is possible on remote desktop.

        I hope this clarifies things. Thank you!

        – Philippe

    • Alex

      I found and published the UEFI hardware compatibility list here https://twitter.com/awfrazer/status/620613737985126401

      • TrendLabs

        Thanks for this, Alex!



     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice