En Huntress, nuestro objetivo es servir al 99%. Aunque Windows sigue liderando el mercado de endpoints empresariales de forma abrumadora, Apple está comenzando a ganar terreno, aumentando su participación de mercado empresarial cada año.
Debido al creciente número de Mac en las empresas, Huntress se propuso igualar su agente de Windows con un equivalente para Mac. Veamos nuestro nuevo agente para Mac, qué buscamos, por qué lo hacemos y hacia dónde nos dirigimos.
El agente de Huntress para macOS
Por ahora, el enfoque principal de nuestro agente es observar los Launch Items. Esto se refiere a los Launch Daemons y los Launch Agents. Antes de profundizar en cada uno, hablemos de por qué es importante recopilarlos.
Si tu teléfono o computadora alguna vez se comportó de forma extraña y lo llevaste a un taller de reparación o a tu departamento de TI, es muy probable que lo primero que te pidan hacer sea "apagarlo y volver a encenderlo". No solo es un buen paso de triage, sino que también tiene un efecto sobre el posible malware.
Para que el malware sea realmente eficaz, debe persistir. Esto significa que si reiniciar tu computadora desactiva el malware, este no es muy sofisticado.
Los autores de malware, en su mayoría, entienden que reiniciar la computadora será uno de los primeros pasos en el proceso de triage, así que suelen buscar que su malware persista. Esto significaría que reiniciar la computadora simplemente volvería a ejecutar el malware, infectando al usuario final una y otra vez.
Por eso empezamos por aquí.
Tipos de persistencia
Existen muchas formas de persistencia en macOS, y aunque Huntress actualmente solo monitorea los Launch Items (Launch Daemons y Launch Agents), hay planes para expandir esa capacidad a otros mecanismos de persistencia.
Por ahora solo recopilamos estos dos por una razón: son, por mucho, los más comunes. Ambos se usan con frecuencia de forma legítima; lamentablemente, esto también significa que los actores de amenazas prefieren usar esta vía para crear persistencia, con la esperanza de esconderse entre los demás Launch Items.
Launch Daemons
Los Launch Daemons son archivos de listas de propiedades (plist) que residen en una de varias ubicaciones posibles del disco. Estos se ejecutan a nivel del sistema, por lo que no son específicos de ningún usuario. Esto significa que se iniciarán cuando arranque el sistema.
Cuando el sistema arranca, se procesan los plist, lo que significa que ejecutan un binario al que apuntan. Si el plist está en el directorio System, entonces está protegido por System Integrity Protection (SIP). Todo lo que se encuentre ahí estará firmado por Apple, mientras que los desarrolladores fuera de ese ámbito tendrán que instalar sus Launch Daemons en la Library raíz.
Ubicaciones
/System/Library/LaunchDaemons/
/Library/LaunchDaemons/
Launch Agents
De forma similar a los Launch Daemons en el sentido de que ejecutan binarios específicos desde un plist, los Launch Agents solo se usan dentro del contexto de una sesión de usuario interactiva. Mientras que los Launch Daemons se ejecutan a nivel del sistema, estos requieren una sesión de usuario. Esto significa que los Launch Agents suelen tener permisos más restrictivos, ya que no se pueden ejecutar a nivel del sistema.
Por esta razón, también existe un directorio de Launch Agents en la carpeta de inicio del usuario (indicada por la virgulilla ~ a continuación). Estos Launch Items están diseñados para apuntar a ejecutables (binarios Mach-O). Si el usuario desea que se ejecute un script al iniciar en su lugar, deberá usar una opción de persistencia distinta.
Los Launch Agents son la forma más común en que los desarrolladores hacen persistir su software y, lamentablemente, probablemente también la forma más común en que persiste el malware. Dado que verás con frecuencia Launch Agents provenientes de fuentes legítimas (piensa en software de MDM, servicios de Google o actualizadores de Microsoft), es importante involucrar a una persona en el proceso. En Huntress, nuestros analistas del SOC revisan estos elementos para verificar su validez y origen.
Ubicaciones
/System/Library/LaunchAgents/
/Library/LaunchAgents/
~/Library/LaunchAgents/
Login Hooks
Ubicado en el directorio raíz /Library/Preferences, este plist contiene un subconjunto de pares clave/valor (objetos de diccionario) que pueden activar la ejecución de un script al iniciar o cerrar sesión. Puedes agregar un login/logout hook simplemente escribiendo un script y luego definiendo ese script como el valor en el plist (clave: LoginHook, valor: /ruta/al/script). Puedes crear esta entrada ejecutando:
sudo defaults write /Library/Preferences/com.apple.loginwindow LoginHook /ruta/al/script
Esto generará el siguiente plist:
Podemos ver el Login Hook apuntando a nuestro script. Ahora, cada vez que iniciemos sesión, se ejecutará nuestro script.
Ubicación
/Library/Preferences/com.apple.loginwindow.plist
Login Items
Estos elementos, visibles para el usuario en la interfaz, se encuentran en las Preferencias del Sistema del usuario. Desde ahí, los usuarios pueden elegir qué aplicaciones se inician automáticamente al iniciar sesión.
Esto es más común en aplicaciones que el usuario quiere abrir justo al iniciar sesión. Mucha gente usa esto para abrir su navegador preferido, gestores de contraseñas o aplicaciones de actualización. Esto se hace a nivel de usuario, así que cada usuario individual puede tener su propia selección.
Ese panel de Preferencias del Sistema lee los elementos de una lista de propiedades binaria de Apple.
Ubicación
~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm
Cron
Usar tareas cron es un método un poco más antiguo, de estilo Unix, para infectar usuarios, y aunque su uso es mucho más raro hoy en día en macOS, todavía es posible lograr persistencia usando cron.
En macOS, esto se logra usando crontabs. Se puede hacer escribiendo una "expresión cron" y guardándola en un archivo, para luego registrar esa expresión cron mediante el comando crontab. Esto la ejecutará según un horario especificado por el usuario.
Una nota de la página principal de crontab:
(Nota de Darwin: Aunque cron(8) y crontab(5) son compatibles oficialmente en Darwin, su funcionalidad ha sido absorbida por launchd(8), que ofrece una forma más flexible de ejecutar comandos automáticamente. Consulta launchctl(1) para más información.)
Ubicaciones
/usr/lib/cron/jobs
/usr/lib/cron/tabs
/var/at/tabs
Scripts periódicos
Los scripts periódicos tienen cierta similitud con cron, pero en su lugar hay tres ubicaciones de carpetas que ejecutarán automáticamente tu script según una cadencia predeterminada. Hay una opción diaria, semanal y mensual.
Estas cadencias se aplican mediante sus propios Launch Daemons protegidos por SIP.
Los scripts que estos ejecutan se almacenan en el directorio /etc/periodic/. Si colocas tu script en una de estas ubicaciones, se ejecutará según el cronograma de su carpeta principal.
Ubicaciones
/etc/periodic/daily
/etc/periodic/weekly
/etc/periodic/monthly
Overrides
El archivo overrides es un plist relativamente sencillo que, aunque se usa con poca frecuencia, todavía puede usarse para persistir en macOS. Este plist está diseñado para anular un valor en un LaunchDaemon o LaunchAgent, así que sin importar si un valor 'Disabled' está configurado como true o no en uno de esos plists, el valor presente en el archivo overrides será el que se implemente.
Por ejemplo, si escribí un plist llamado myApp.plist y tenía la clave Disabled configurada como “true” (lo que efectivamente deshabilita la carga de mi plist), pero en el plist overrides tenía una entrada que configuraba ese valor como “false,” la próxima vez que ejecuté sudo launchctl load ~/Library/LaunchAgent/myApp.plist, ese plist se cargaría aunque en myApp.plist diga que debería estar deshabilitado.
Este es un método poco común de persistencia usado por actores de amenazas, pero aún podría ser potencialmente aprovechado por adversarios.
Ubicación
/var/db/launchd.db/com.apple.launchd/overrides.plist
Emond (macOS 12 y anteriores)
Emond, que significa event monitor daemon, es un daemon que se ejecuta al iniciar el sistema operativo. Hay una colección de archivos en el directorio /etc/emond.d/ que contiene archivos como rules plists que pueden escribirse para activar ciertos elementos en momentos específicos (inicio, periódico).
El investigador de seguridad Chris Ross de Zoom ha explicado en gran detalle cómo los atacantes podrían potencialmente aprovechar emond en su blog.
Nota: a partir de macOS Ventura 13.0, emond y sus archivos asociados ya no están presentes en el disco.
System Extensions
Dejé System Extensions para el final porque son algo anómalas en comparación con los otros tipos de persistencia mencionados anteriormente. Es una forma de persistir, pero en la mayoría de los otros tipos de los que he hablado aquí pueden ser algo fácilmente usados como arma por actores de amenazas.
System Extensions son increíblemente más difíciles, y no creo haber visto un caso en el que hayan sido abusadas. System Extensions están integradas en el desarrollo de aplicaciones y junto a él, y pueden aprovecharse para acceder a APIs de más bajo nivel del sistema, como Endpoint Security o DriverKit.
No cualquiera puede usar una System Extension. De hecho, para usar una, tienes que solicitar un entitlement directamente a Apple y explicar cómo usarás ese entitlement dentro de la aplicación que estás desarrollando. El proceso de verificación, según mi entender, es bastante exhaustivo y riguroso.
Ubicación
/Library/SystemExtensions/
Conclusión
La persistencia es el enfoque principal del malware, ya que le permite seguir ejecutándose en el sistema infectado incluso después de reiniciar la máquina. Tener visibilidad de estos elementos es fundamental para proteger a los usuarios finales. Es el mejor punto de partida al analizar malware de Mac, por eso empezamos por ahí. Queríamos asegurarnos de poder caminar antes de empezar a correr, así que esto es solo el comienzo de nuestro agente de macOS.
