Remote iOS Attacks Targeting Journalists: More Than One Threat Actor?

ZecOps is proud to share that we detected multiple exploits by the threat actors that recently targeted Aljazeera’s journalists before it was made public. The attack detection was automatically detected using ZecOps Mobile DFIR.

In this blog post, we’ll share our analysis of the post-exploitation kernel panics observed on one of the targeted devices.

Key details on the attacks targeting journalists in Middle East:

• First known attack: earliest signs of compromise on January 17th, 2020.
• Was the attack successful: Yes – the device shows signs for successfully planted malware / rootkit.
• Persistence: The device shows signs for a persistent malware that is capable of surviving reboots. It is unclear if the device was re-infected following an OS update, or that the malware also persisted between OS updates.
• Attack Impact: The threat-operators were able to continuously access the device microphone, camera, and data including texts, and emails for the entire period.
• Attribution: We named this threat actor Desert Cobra. We do not rule out that NSO (aka “NSO Group”) was involved in the other reporters’ cases that was published today by Citizen Labs. We refrain from naming the particular threat actor that targeted one of the victims in Citizen-Labs report, NSO, due to some activities that do not add-up with our Mobile Threat Intelligence on NSO. We also do not rule out that this device was potentially compromised by more than one threat actor simultaneously.
• OS Update? We do recommend updating to the latest iOS version, however we have no evidence that this actually fixes any of the vulnerabilities that were exploited by this threat operator(s).

Post-exploitation Panic Analysis

A tale of two panics: MobileMail and mediaanalysisd: kauth_cred_t corruption

The following stack backtrace of the MobileMail panic indicates that the panic happened on function kauth_cred_unref:

panic(cpu 2 caller 0xfffffff02a2f47f0): "kfree: size 8589934796 > kalloc_largest_allocated 21938176"
_func_fffffff007b747f0 + 0 ~ (kfree + 340)
sfree() + 28
_func_fffffff008debd5c + 68 ~ (_mpo_cred_check_label_update + 2904)
_func_fffffff008df5f48 + 92 ~ (_sandbox_hook_policy_syscall + 6488)
_func_fffffff008df5d8c + 300 ~ (_sandbox_hook_policy_syscall + 6252)
_func_fffffff008de309c + 64 ~ (_check_boolean_entitlement + 1716)
_func_fffffff0081538e8 + 76 ~ (audit_session_unref)
_func_fffffff007f3f790 + 200 ~ (kauth_cred_unref)
...
 _vn_open_auth + 1612
 _open1 + 256
 _open + 528

kauth_cred_unref frees credential structures from the kernel. The following is the stack backtrace of the mediaanalysisd panic, it also panicked on function “kauth_cred_unref”:

_func_fffffff008db5d4c + 260 ~ (_sandbox_hook_policy_syscall + 6212)         
       0xfffffff010795e50  ldr x8, [x21]                  
       0xfffffff010795e54  str x8, [x19, x22, lsl #3]     
       0xfffffff010795e58  b 0x01db5e78    // 0xfffffff01254bcd0 
       0xfffffff010795e5c  ldr x9, [x8] 
 _func_fffffff008da305c + 64 ~ (_check_boolean_entitlement + 1716)
 _func_fffffff00814783c + 76 ~ (audit_session_unref)
 _func_fffffff007f336f4 + 200 ~ (kauth_cred_unref)
...
_func_fffffff007cebec8 + 444 ~ (_copyin + 4560)
_copyin + 2224

Function “kauth_cred_free” calls by “kauth_cred_unref”, code as follows:

static void kauth_cred_free(kauth_cred_t cred)
{
assert(os_atomic_load(&cred->cr_ref, relaxed) == 0);
#if CONFIG_MACF
mac_cred_label_destroy(cred);
#endif
AUDIT_SESSION_UNREF(cred); // ← call kfree, panic inside
FREE_ZONE(cred, sizeof(*cred), M_CRED);
}

Both of the panics happened inside “AUDIT_SESSION_UNREF”, which means the credential structure of the processes was corrupted.

A classic way to gain root access for a kernel exploit is to replace the credential structure of an attacker controlled process with the kernel credentials. Please note that it doesn’t necessarily mean MobileMail or mediaanalysisd was controlled, the corruption of the credential structures could have also happened due to wrong offsets during exploitation.

ZecOps customers: no further action is required. The deployed systems detect these activities. The complete report and full IOC list is available in ZecOps Threat Intelligence feed.