Tag: Hacking Team

Hacking Team analysis

~ hucktech ~ Leave a comment

Ethan Heilman has written a  nice document researching the core-packer that the Hacking Team’s malware uses.

We investigate how Italian malware vendor Hacking Team obfuscated
their malware, specifically the custom software they developed for
this task called core-packer. This analysis was a joint project
between Will Cummings (@dubbelyew) and Ethan Heilman (@Ethan_Heilman).

Core-packer’s first commit is Oct 2012, nine days after Citizen Lab
released a report “Backdoors are Forever: Hacking Team and the
Targeting of Dissent?” on Hacking Team’s malware. It seems likely that
core-packer was developed to prevent future disclosures by increasing
the stealth of Hacking Team’s malware. In fact in response to the
Citizen Lab they wrote talking points to assure their clients that
malware was safe to use. One of these talking points was that they
were implementing “technical measures”, perhaps referring to
core-packer.

Hmm, WordPress embeds the entire article if I use the URL as-is, so I’ll split the URL in half, you’ll have to recombine it, sorry.

http://ethanheilman.tumblr
.com/post/128708937890/a-brief-examination-of-hacking-teams-crypter

Hacking Team had other bootkits

~ hucktech ~ Leave a comment

Vlad Tsyrklevich wrote an excellent aritcle on the 0-day market via analyzing the Wikileak’ed Hacking Team emails:

http://tsyrklevich.net/2015/07/22/hacking-team-0day-market/
https://twitter.com/vlad902/status/623950714247749632

Most have already read about the UEFI malware that it used, including this Intel ATR analysis:
http://www.intelsecurity.com/advanced-threat-research/blog.html

Beyond this UEFI malware, Vlad’s analysis of the Wikileaks email revealed at least 2 other firmware exploits that Hacker Team appeared to have been using:

08/19/13,  ASUS BIOS device driver LPE, Firefox RCE added

02/24/14, “Apple iOS Remote Forced Access-Point Association”/“Apple iOS Remote Forced Firmware Update Avoidance” no longer available, OpenPAM (used on BSDs) LPE added

See Vlad’s blog for pointers to other Wikileaks.org-based email articles on these two entries.

I wish there was a list of former 0-days, at least the firmware subset… I also wish there was a safe place to download the “Uefi_windows_persistent.zip” and “Z5WE1X64.fd” files listed in the Intel ATR blog.

Intel analysis of Hacking Team UEFI malware

~ hucktech ~ Leave a comment

[[
UPDATE: IntelSecurity.com web site has changed, the ATR blog URL is broken. Updated URL:
http://www.intelsecurity.com/advanced-threat-research/ht_uefi_rootkit.html_7142015.html
]]

A quick follow-up to the Hacking Team UEFI malware story. There’s been a lot of mainstream coverage on this news. I just found out about this blog entry by the Intel Advanced Threat Research (ATR) team:

http://www.intelsecurity.com/advanced-threat-research/blog.html

It’s analysis of the malware is excellent, and worth reading. Unlike other news stories on Hacking Team, this blog shows you how to check if your system is infected. They used CHIPSEC[1] and UEFItool[2] to analyse this malware, two excellent tools for UEFI forensic analysis. Study this Intel blog post for a very topical example of how to use CHIPSEC to protect your system from bootkits.

[1] https://firmwaresecurity.com/2015/06/10/chipsec-v1-2-0-released/
https://github.com/chipsec/chipsec
[2] https://firmwaresecurity.com/2015/05/25/tool-mini-review-uefitool/
https://github.com/LongSoft/UEFITool

Hacking Tool should remind people that they don’t have a clue what modules are burned into their firmware. Many firmware solutions target enterprise sales, so they’re happy to have phone-home style technology in their systems, to track their assets. Malware authors can take advantage of these remote control features, like Hacking Team is doing. Windows OEMs generally screw up Windows with various bloatware; unlike with OS software, you cannot undo firmware bloatware, the OEM won’t permit you to rebuilt the firmware image (unless you have a Tunnel Mountain or MinnowBoard), and the OEM doesn’t provide standalone UEFI drivers/services so that you could rebuilt your firmware from coreboot.org and/or tianocore.org plus the delta of blobs (OEM/IHV drivers). Then, we could focus on reliability of the open source codebase and the handful of closed-source firmware drivers, instead of relying on the IBV/OEM to give us black-box fimware updates when they feel like it. OEMs: give us better firmware options!