Hacking Team RCS implant installer analysis (Apple's encrypted binary)

Hacking Team RCS implant installer analysis (Apple's encrypted binary)

Recently, security personnel issued a message saying that Apple's encrypted binary library is used in Hacking Team's RCS implant Installer:

 

 

At last year's Black Hat conference, security personnel Patrick Wardle gave a speech titled "Writing Bad @ $ Malware for OS x", which provided some suggestions for improving OS X Malware, here, we mentioned how to use Apple's built-in encryption mechanism to protect the binary library of malware, as shown in. Hacking Team is using this method in the malware used to make another comeback this year.

 

TaskExplorer (a tool that enumerates and lists encrypted binary libraries worldwide) precisely detects the malware. It can also be determined that someone actually uses Apple's encryptor to protect malware.

Dropper)

The security personnel obtained the hash value of the binary database (sha256: 58e4e4853c6cfbb43afd49e5238042596ee5b78eca439c7d76bd95a34115a273) and used VirusTotal to check the hash value. The result is:

 

 

During the analysis, we can first determine that the binary database actually uses the OS X encryption mechanism provided by Apple. Check whether the load command flag of the _ TEXT segment in the binary library is set to SG_PROTECTED_VERSION_1 (0 × 8 ):

$ otool -l installLoad command 1        cmd LC_SEGMENT    cmdsize 328    segname __TEXT     vmaddr 0x00001000     vmsize 0x00004000    fileoff 0   filesize 16384    maxprot 0x00000007   initprot 0x00000005     nsects 4      flags 0x8

When IDA Pro is used for disassembly, the system will prompt:

 

Because the embedded installer is encrypted, it can be analyzed only after decryption. Apple's encryption mechanism uses the symmetric encryption algorithm (Blowfish), which can be easily cracked using static keys. In addition, the Classdump tool also contains an open-source implementation solution for encryptor. By compiling the decryption tool code, the implanted installer is decrypted:

./deprotect install installDecrypted$ otool -l installDecryptedLoad command 1  cmd LC_SEGMENT  cmdsize 328  segname __TEXT  vmaddr 0x00001000  vmsize 0x00004000  fileoff 0  filesize 16384  maxprot 0x00000007  initprot 0x00000005  nsects 4  flags 0x0

Can I perform in-depth analysis on the decrypted implant installer? The answer is no. Although it has been decrypted, it is still encapsulated. Check IDA's decompilation code (the flag is still 0 × 0), or use the filter of TaskExplorer for filtering (select # packed ):

 

The investigation found that HackingTeam is more inclined to use a custom package, so the memory dump can be used to achieve Analysis in IDA Pro. Some problems are encountered during the memory dump process. First, do not force lldb (Apple's debugger) to ignore the EXC_BAD_ACCESS exception. That is to say, if the unblocked code encounters a similar exception, it will not be handed over to the debugger. The following error message is displayed:

$ lldb installDecryptedCurrent executable set to 'installDecrypted' (i386).(lldb) process launchProcess 714 launched: '/Users/user/Desktop/installDecrypted' (i386)Process 714 stopped* thread #1: tid = 0x39e1, 0x0000709d installDecrypted, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS

Other memory dump tools require that the process is running, and the embedded installer will be terminated immediately after completion. Therefore, the researchers decided to write an extensible dynamic library (for example) to solve the problem.

 

After loading the embedded installer, unban it, pause it, connect to lldb, and dump the unblocked binary library code:

$ ps aux | grep [i]nstallDecrypteduser 519 1.9 0.8 658408 17276 s000$ lldb -p 519...(lldb) memory read --outfile /tmp/dumped.txt 0x7000 0xBFFFF --force

Jump back to IDA Pro, load the memory dump file, and perform in-depth analysis:

 

Because dump memory segments are used, IDA analysis is not comprehensive. Through the combination of static analysis and dynamic analysis, you can use fs_usage to clearly obtain process details:

$ sudo fs_usage -w -f filesystem | grep installexecve /Users/user/Library/Preferences/8pHbqThW/_9g4cBUb.psropen /Users/user/Library/Preferences/8pHbqThW/Bs-V7qIU.cYLwrite F=8 B=0x8f0 

The implant program is permanently implanted ~ /Library/Preferences/8 pHbqThW/_ 9g4cBUb. This file is executed and Its encrypted data file Bs-V7qIU.cYL is also placed in ~ /Library/Preferences/8 pHbqThW/directory.

Permanent implantation (RCS)

Permanent implantation (_ 9g4cBUb. psr, sha256: slave) will become the startup proxy of the user once it is saved and executed on the disk:

$ sudo fs_usage -w -f filesystem | grep _9g4cBUb.psrlstat64 /Users/user/Library/LaunchAgents/com.apple.FinderExtAvt.plistHFS_update /Users/user/Library/LaunchAgentsWrData[A] /Users/user/Library/LaunchAgents/.dat.nosync028d.8bNgnerename /Users/user/Library/LaunchAgents/.dat.nosync0289.8bNgne

You can use the BlockBlock tool to check and prevent such permanent installation:

 

You can also use the KnockKnock tool to find the binary library for persistent installation:

 

By running the string direction in the memory of the dump, the implant is indeed HackingTeams RCS:

$ ps aux | grep [_]9g4cBUb.psruser 649 1.9 0.8 658408 17276 s000 Users/user/Library/Preferences/8pHbqThW/_9g4cBUb.psr$ sudo ./readmem -p 649 -m -o dumped.bin---------------------------------Readmem v0.6 - (c) 2012, 2013 fG!---------------------------------[DEBUG] Found main binary mach-o image @ 0x1000![DEBUG] Executing get_image_size[DEBUG] Executing dump_binary[DEBUG] Dumping __TEXT at 1000 with size 6b000 (buffer:38000)[DEBUG] Dumping __DATA at 6c000 with size 38000 (buffer:a3000)[DEBUG] Dumping __OBJC at a4000 with size 7000 (buffer:db000)[DEBUG] Dumping __LINKEDIT at ab000 with size 6608 (buffer:e2000)[OK] Full binary dumped to dumped.bin!

Summary

With the development of hacking technology, more and more OS x malware may use Apple's OS X secret mechanism. You may view ~ /Library/Preferences/8 pHbqThW/containing _ 9g4cBUb. psr and/orBs-V7qIU.cYL directory to check whether the device is infected. If infected, you can delete the entire directory and delete ~ /Library/LaunchAgents/com. apple. FinderExtAvt. plist file.

Because traditional anti-virus solutions cannot block the malware, you can use other tools, such as BlockBlock, KnockKnock, and TaskExplorer.