Security researchers recently uncovered a newly developed Mac malware sample, which appears to have come from Hacking Team – a controversial Italian “malware-as-a-service” group infamously known for a massive leak of 400 GB of internal source code and proprietary information last July. Two variations of the malware sample were first uploaded to VirusTotal. Google’s free scanning service, the first week in February. VirusScan revealed that none of the major antivirus programs (0/54) detected the sample as malicious. It is still up for debate whether or not this malware came directly from Hacking Team – as many were surprised to hear Hacking Team was still around after the embarrassing data leak – or if someone repurposed leaked Hacking Team source code. The malware sample’s complexity and uniqueness has been questioned, but Synack Director of R&D and OS X expert, Patrick Wardle, performed a deep-dive analysis on the sample here, and provided additional commentary:
This sample of malware contains most of the same code as old Hacking Team malware, but it appears to install a new version of the old Hacking Team implant. It isn’t clear how this new malware gets installed, but one of the improvements of this new sample is that it does use some novel techniques to avoid detection. The malware utilizes Apple’s own native OS X encryption system that protects the binary contents of the application— making it the first malicious OS X implant installer I have ever seen to do so.
Last summer, at Blackhat, I gave a presentation entitled Writing Bad @$$ Malware for OS X. In this talk, I provided several suggestions as to how OS X malware could be improved. One thing I mentioned was leveraging Apple’s native encryption scheme as simple way to “protect” one’s malicious binaries. Now I’m sure other people have had the idea of using Apple’s encryption scheme to protect their malware and it’s really not that good an idea – But until now, I’d never encountered any malware that made use of this encryption scheme.
I was still able to break the encryption because Apple uses a static hard-coded key that has long been known to reverse engineering experts. Although the persistent implant was no longer protected via Apple’s native OS X encryption scheme at this point, I found that it was also packed. However, since it is a continually running process, its memory can be trivially dumped.
Running strings on the dumped (unpacked) memory of the implant quickly revealed, that yes indeed, it’s Hacking Team’s RCS implant – now with new few features and surprises that help it evade detection.
Due to the similarities of this sample with techniques used by Hacking Team in the past, Pedro Vilaca (security researcher at SentinelOne) also seems to believes that yes, this new sample is the work of Hacking Team, posting that he had “found some unique code in this dropper that did not exist in the source code leaked last year”. Vilaca suggested that either “someone is maintaining and updating the Hacking Team code … or that this fresh sample was compiled by Hacking Team themselves, and they are still ‘alive and kicking’ post-July hack.”
Key Takeaways: What we have seen here is an interesting new variant of OS X malware utilizing Apple’s native OS X encryption scheme, as well as custom packers, to avoid detection – further accompanied by the possible reemergence of the severely tarnished Hacking Team.
*For Patrick’s more detailed analyses of Mac malware, see his personal blog here (which also contains free OS X tools built by Patrick himself to help detect and protect against OS X malware!)