El blog de seguridad de FireAI

Por FireAI Security & Research Team · Publicado

Persistencia de búsqueda en macOS: agentes de lanzamiento, elementos de inicio de sesión y tareas en segundo plano

Persistencia de búsqueda en macOS: agentes de lanzamiento, elementos de inicio de sesión y tareas en segundo plano

"Persistencia" es el término de seguridad para un problema específico: ¿cómo se organiza el código que se ejecutó una vez para ejecutarse nuevamente, automáticamente, después de reiniciar o iniciar sesión, sin que nadie lo reinicie manualmente? macOS ofrece al software legítimo muchas formas autorizadas de hacer exactamente eso (un verificador de actualizaciones, un cliente de sincronización de barra de menú, un asistente de controlador de impresora) y cada uno de esos mecanismos está igualmente disponible para algo que preferiría que no se ejecutara en absoluto. Este es un recorrido por los lugares reales para buscar, con los comandos reales y una descripción honesta de dónde pertenece y dónde no pertenece una herramienta centrada en la red como FireAI en esa imagen.

LaunchAgents y LaunchDaemons: los dos grandes

macOS inicia casi todo a través de launchd, controlado por archivos de lista de propiedades (.plist) en una pequeña cantidad de directorios conocidos. La técnica T1543.001 de MITRE ATT&CK describe el mecanismo claramente: al iniciar sesión, un proceso launchd por usuario carga plists de los directorios LaunchAgents del usuario y del sistema, y ​​un plist con RunAtLoad configurado en verdadero se ejecuta automáticamente en el momento en que se carga; no se necesita ninguna otra acción por parte de quien lo puso allí. La técnica enumera las tres ubicaciones que importan: /System/Library/LaunchAgents, /Library/LaunchAgents y ~/Library/LaunchAgents. MITRE señala algo que vale la pena recordar mientras se desplaza por una lista de estos archivos: los agentes instalados para la persistencia a menudo están "disfrazados... usando nombres que se asemejan a sistemas operativos o componentes de software legítimos"; el archivo que se parece a com.apple.something.plist merece una segunda mirada precisamente porque está tratando de no obtener uno.

LaunchDaemons, cubiertos por la técnica relacionada T1543.004, son la versión para todo el sistema que no requiere inicio de sesión: se ejecutan como root, comenzando en el arranque, desde /System/Library/LaunchDaemons/ o /Library/LaunchDaemons/. Debido a que instalar uno allí requiere privilegios administrativos para empezar, MITRE encuadra la ruta del demonio como una forma de convertir un punto de apoyo privilegiado inicial en algo que sobrevive a un reinicio, ejecutándose con acceso de nivel raíz a partir de ese momento, razón por la cual un archivo nuevo y desconocido que aparece en /Library/LaunchDaemons es una señal más fuerte que uno que aparece en la propia carpeta LaunchAgents de un usuario.

Terminal: enumera lo que realmente está registrado
ls -la ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
# compare this list against what you remember installing; anything you don't
# recognise is worth reading with: plutil -p /path/to/the.plist

Un archivo que existe en el disco y un trabajo que se está cargando son dos preguntas diferentes, y launchctl print responde a la segunda. Su página de manual lo describe como una impresión de "información sobre el servicio o dominio especificado": apunta a un dominio como system/ o gui/501/ (siendo 501 el UID de un usuario), enumera todos los servicios y puntos finales actualmente cargados en ese contexto, además del estado de cada uno:

Terminal: lo que realmente está cargado en este momento
launchctl print gui/$(id -u)
# example output, trimmed — a real run lists every loaded agent for your session
	"com.apple.someAgent" => {
		active count = 1
		path = /Library/LaunchAgents/com.apple.someAgent.plist
		state = running
	}

Elementos de inicio de sesión y gestión de tareas en segundo plano

La superficie de cara al usuario para gran parte de esto es el panel Elementos de inicio de sesión de Configuración del sistema, y ​​vale la pena comprobarlo con sus propios ojos, no solo con la línea de comando. La guía de soporte de Apple lo describe directamente: puede "elegir elementos de inicio de sesión que se abren automáticamente cuando inicia sesión", agregarlos o eliminarlos allí y permitir o denegar por separado aplicaciones que "realizan tareas cuando la aplicación no está abierta, como buscar actualizaciones de software o sincronizar datos". Esa segunda categoría cubre ayudas en segundo plano que no son elementos de inicio de sesión completos pero que aún se ejecutan sin supervisión.

Desde macOS Ventura, el sistema debajo de ese panel de configuración se llama comúnmente Administración de tareas en segundo plano (BTM) en la comunidad de seguridad: un servicio que rastrea cada agente de lanzamiento, demonio de inicio y elemento de inicio de sesión a medida que se registra, que es lo que permite que la Configuración del sistema le muestre una lista centralizada y en vivo en lugar de tener que buscar a mano en tres directorios plist. Existe una herramienta de línea de comandos no documentada, sfltool, que algunos investigadores utilizan para consultar esa base de datos más directamente con sfltool dumpbtm. Apple no incluye ninguna página de manual para ella y no se garantiza que su formato de salida se mantenga estable, así que trátelo como una curiosidad de investigación para probar en su propia máquina en lugar de algo sobre lo que construir un flujo de trabajo. La forma estable y admitida de ver la misma información sigue siendo el panel Elementos de inicio de sesión en Configuración del sistema, o launchctl print para el estado activo de un trabajo específico.

cron: más viejo, más silencioso, todavía ahí

launchd ha sido el programador preferido de Apple durante mucho tiempo, pero el demonio cron más antiguo de Unix todavía se envía y ejecuta todo lo programado en él. La página de manual de crontab describe el formato del archivo directamente: cada línea tiene cinco campos de hora/fecha (minuto, hora, día del mes, mes, día de la semana) seguidos del comando para ejecutar, con @reboot y cadenas abreviadas similares disponibles en lugar de los cinco campos en algunos sistemas. crontab -l, según la página del comando man crontab(1), "Mostrará el crontab actual en la salida estándar" para el usuario actual:

Terminal: comprobar el crontab propio y del root
crontab -l
sudo crontab -l -u root

Un resultado vacío para ambos es normal en la mayoría de las Mac actuales; es exactamente por eso que todo lo que hay ahí merece atención. cron no es atractivo y rara vez se verifica, que es precisamente la razón por la que todavía aparece como una ubicación de persistencia alternativa en los informes de incidentes.

Perfiles de configuración: persistencia con un rastro en papel

Un perfil de configuración puede instalar un LaunchDaemon, otorgar permisos de privacidad o enviar configuraciones a una flota de Mac; legítimamente, así es como funciona MDM (administración de dispositivos móviles). Ilegítimamente, un perfil es una forma documentada de hacer que los cambios se mantengan sin tocar directamente un archivo plist. La herramienta de línea de comandos profiles enumera lo que está instalado: profiles list muestra los perfiles instalados y, como señala su página de manual, ejecutarla como root con -all "enumerará todos los perfiles de configuración en el sistema" en lugar de solo los del usuario actual.

Terminal: todos los perfiles de configuración en Mac
sudo profiles list -all
sudo profiles show -all

Una Mac personal sin inscripción en MDM generalmente no debería tener ninguna, o solo las que usted haya instalado deliberadamente (una configuración de VPN, un perfil de trabajo). Vale la pena investigar un perfil que no recuerda haber instalado antes de eliminarlo, ya que profiles también admite la eliminación con protección con contraseña exactamente para ese paso.

Complementos de autorización y la cola larga

Más allá de los cuatro grandes mencionados anteriormente, hay una larga cola de mecanismos más pequeños y antiguos: servicio de directorio y complementos de autorización, importadores de Spotlight, generadores QuickLook, complementos de mosaicos Dock y archivos de inicio de shell que se ejecutan cada vez que se abre una nueva sesión de terminal. Aquí es donde una herramienta especialmente diseñada gana terreno frente a la verificación manual. KnockKnock de Objective-See, por ejemplo, enumera más de veinte categorías de ubicaciones de persistencia en una sola pasada, incluidos agentes de lanzamiento y demonios, elementos de inicio de sesión, extensiones de navegador, trabajos cron, extensiones de sistema y kernel, y complementos de servicio de directorio y autorización, y muestra el estado de firma de código de lo que encuentra en cada una. Su compañero, BlockBlock, toma la misma lista de ubicaciones y las observa continuamente, alertando en el momento en que se registra algo nuevo; Según su propia descripción, "supervisa las ubicaciones de persistencia comunes y alerta cada vez que se agrega un nuevo componente persistente", mostrando el proceso responsable, su estado de firma y permitiéndole permitir o bloquear en el momento.

Archivos de inicio de Shell: el cajón de sastre silencioso

Una ubicación más que vale la pena ver directamente, ya que no necesita plist ni ninguna instalación privilegiada: los archivos de configuración del shell. ~/.zshrc, ~/.zprofile y ~/.bash_profile se ejecutan cada vez que se abre una nueva sesión de terminal coincidente, y una sola línea adjunta (conectar a un script, exportar un PATH secuestrado, iniciar un proceso en segundo plano) es suficiente para restablecer un punto de apoyo cada vez que abres Terminal, sin nada que cargar en launchd y nada que launchctl print pueda mostrar. KnockKnock de Objective-See incluye exactamente esta categoría en su análisis, listada junto con agentes de lanzamiento y elementos de inicio de sesión como archivos de configuración de shell, por la misma razón que pertenece a este artículo: es lo suficientemente común y poco glamoroso como para que valga la pena comprobarlo en lugar de suponerlo.

Terminal: una lectura rápida, no un sustituto de la lectura real
cat -A ~/.zshrc ~/.zprofile ~/.bash_profile 2>/dev/null | less
# -A shows non-printing characters, which surfaces anything hidden with
# trailing whitespace or a carriage return trying to push it off-screen

Dónde encaja FireAI y dónde deliberadamente no

Para ser directo: FireAI no escanea /Library/LaunchDaemons, no lee archivos plist y no intenta detectar un nuevo elemento de inicio de sesión o perfil de configuración. Esa es una disciplina distinta de lo que hace FireAI, y las herramientas creadas específicamente para ella (KnockKnock y BlockBlock entre ellas) ya hacen bien ese trabajo. Lo que FireAI observa es el paso que viene después de la persistencia, y que cada uno de estos mecanismos eventualmente necesita si va a ser útil para quien lo instaló: una conexión de red. Un LaunchAgent que se ejecuta silenciosamente en cada inicio de sesión pero que nunca habla con la red es, desde el punto de vista de un firewall de red, invisible y, además, en la práctica, mucho menos útil para un atacante. En el momento en que abre un socket, las reglas por aplicación de FireAI se aplican como cualquier otro proceso: un binario desconocido firmado o no firmado que realiza su primera conexión activa un mensaje, con el razonamiento del modelo en el dispositivo mostrado en lenguaje sencillo, y cada decisión es visible, deshacer y exportable como una regla de texto posteriormente.

La manera honesta de unir las dos disciplinas: verifique las ubicaciones en este artículo en un cronograma que coincida con su tolerancia al riesgo (mensualmente es razonable para la mayoría de las personas, semanalmente si instala una gran cantidad de software de terceros) y deje que una herramienta de red lleve la carga en el medio, asumiendo que cualquier cosa que persista en silencio eventualmente tendrá que hablar para llegar a quien responde.

El papel de FireAI y de HisnLabs

FireAI does not scan for persistence — that is a different job, and tools like KnockKnock and BlockBlock already do it well; what FireAI watches is what that persisted code does the moment it opens a socket, which is the step every one of these mechanisms eventually has to take to be useful to whoever installed it.

FireAI es el propio producto de HisnLabs: un cortafuegos con IA integrada para Mac. Muestra, en lenguaje claro, cada conexión que hacen tus aplicaciones y te deja decidir qué sale de tu Mac; su IA funciona en el propio equipo, así que tu tráfico nunca se envía a HisnLabs ni a nadie más. El equipo de investigación en seguridad de HisnLabs es quien mantiene esas decisiones fiables: cataloga qué dominios son simple telemetría frente a un servicio real, sigue el país y la red detrás de una conexión, y entrena el modelo local (la función Autopilot) con tráfico real, sin que nada salga de tu Mac.

Puedes leer las decisiones técnicas detrás de esto, o probar FireAI durante 17 días, en FireAI, de HisnLabs.

Fuentes