The communication involves a kext utilizing kev_msg_post to send data to a user-mode application through a system socket. Objective-See’s BlockBlock tool uses this technique to correlate persistent file I/O events with the responsible process. Abuse of kev_msg_post can allow malicious kexts to exfiltrate sensitive kernel-level information or trigger actions in user-mode without detection by conventional monitoring tools. This technique is relevant to defenders because it provides a stealthy mechanism for malware to operate within macOS, potentially leading to undetected data theft, privilege escalation, or system compromise.

Attack Chain

1. A malicious kext is loaded into the macOS kernel, often requiring elevated privileges or exploiting a vulnerability.
2. The kext uses the kev_vendor_code_find function to obtain a vendor ID associated with the kext (e.g., “com.objective-see”).
3. The kext registers for process execution events using kauth or MAC policies.
4. When a new process is created, the kext’s callback function is triggered.
5. The kext populates a kev_msg structure with process information, including the process ID (PID), user ID (UID), parent process ID (PPID), and path to the executable.
6. The kext calls the undocumented kev_msg_post function to broadcast the process information to a system socket.
7. A user-mode application with a socket connected to the same vendor ID receives the broadcasted message, extracting the process information.
8. The attacker can use the process information for malicious purposes, such as injecting code into the new process, monitoring its activity, or terminating it.

Impact

Successful exploitation could allow attackers to monitor and manipulate processes on a compromised macOS system without detection by standard userland monitoring tools. This could lead to data exfiltration, privilege escalation, or other malicious activities. Due to the nature of the kernel, even a single successful compromise can lead to complete system compromise.

Recommendation

• Monitor for the loading of unsigned or untrusted kernel extensions using system integrity monitoring tools that track kext loading events.
• Implement detections for user-mode applications creating system sockets with the SYSPROTO_EVENT protocol, as described in the “Receiving the Data in User-Mode” section. This can be done using an endpoint detection and response (EDR) solution or auditd.
• Develop YARA rules to scan kernel memory for the presence of kexts using the undocumented kev_msg_post function to detect malicious kexts attempting to communicate outside kernel space.
• Audit the use of ioctl calls with SIOCGKEVVENDOR and SIOCSKEVFILT to detect user-mode applications attempting to filter for specific kernel events, using the code samples from the “Receiving the Data in User-Mode” section as reference.

Attack Chain

1. Attacker gains initial access to the system (e.g., through exploitation or social engineering).
2. Attacker executes a malicious binary or script.
3. The malicious process creates or modifies a file on the system.
4. The Endpoint Security Framework captures the file I/O event.
5. The file monitor, leveraging the Endpoint Security Framework, receives a notification about the event.
6. The file monitor extracts information about the event, including the process ID, path, code-signing information, and the type of file event (e.g., create, write).
7. Based on the extracted information, the file monitor determines if the event is malicious (e.g., rapid creation of encrypted files, persistence attempt).
8. The file monitor alerts the user or security system about the malicious activity.

Impact

A successful attack can lead to various detrimental outcomes, including data encryption by ransomware, persistent malware installation, and unauthorized access to sensitive information. File monitors, such as the one described, aim to detect and prevent such attacks. Without proper file monitoring, malicious activities can go unnoticed, leading to significant data loss, system compromise, and financial damage. The Endpoint Security Framework intends to address the limitations of previous monitoring solutions.

Recommendation

• Enable Endpoint Security Framework event collection to monitor file creation events using the ES_EVENT_TYPE_NOTIFY_CREATE event type described in the overview.
• Deploy the Sigma rule for detecting file creation by unsigned processes to identify potentially malicious activity (see Sigma rule below).
• Monitor for processes with missing or invalid code-signing information, as these may be indicators of malicious activity, using the Endpoint Security Framework’s process information detailed in the overview.