macOS Auto Start
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Esta seção é fortemente baseada na série de blogs Além dos bons e velhos LaunchAgents, o objetivo é adicionar mais Locais de Autostart (se possível), indicar quais técnicas ainda estão funcionando atualmente com a versão mais recente do macOS (13.4) e especificar as permissões necessárias.
Aqui você pode encontrar locais de início úteis para bypass de sandbox que permitem que você simplesmente execute algo escrevendo em um arquivo e esperando por uma ação muito comum, uma quantidade determinada de tempo ou uma ação que você geralmente pode realizar de dentro de uma sandbox sem precisar de permissões de root.
/Library/LaunchAgents
Gatilho: Reinicialização
Root necessário
/Library/LaunchDaemons
Gatilho: Reinicialização
Root necessário
/System/Library/LaunchAgents
Gatilho: Reinicialização
Root necessário
/System/Library/LaunchDaemons
Gatilho: Reinicialização
Root necessário
~/Library/LaunchAgents
Gatilho: Re-login
~/Library/LaunchDemons
Gatilho: Re-login
Como fato interessante, launchd tem uma lista de propriedades incorporada na seção Mach-o __Text.__config que contém outros serviços bem conhecidos que o launchd deve iniciar. Além disso, esses serviços podem conter RequireSuccess, RequireRun e RebootOnSuccess, o que significa que eles devem ser executados e concluídos com sucesso.
Claro, não pode ser modificado devido à assinatura de código.
launchd é o primeiro processo executado pelo kernel do OX S na inicialização e o último a terminar na desligamento. Ele deve sempre ter o PID 1. Este processo irá ler e executar as configurações indicadas nos plists ASEP em:
/Library/LaunchAgents: Agentes por usuário instalados pelo administrador
/Library/LaunchDaemons: Daemons em todo o sistema instalados pelo administrador
/System/Library/LaunchAgents: Agentes por usuário fornecidos pela Apple.
/System/Library/LaunchDaemons: Daemons em todo o sistema fornecidos pela Apple.
Quando um usuário faz login, os plists localizados em /Users/$USER/Library/LaunchAgents e /Users/$USER/Library/LaunchDemons são iniciados com as permissões dos usuários logados.
A principal diferença entre agentes e daemons é que os agentes são carregados quando o usuário faz login e os daemons são carregados na inicialização do sistema (já que existem serviços como ssh que precisam ser executados antes que qualquer usuário acesse o sistema). Além disso, os agentes podem usar GUI enquanto os daemons precisam ser executados em segundo plano.
Existem casos em que um agente precisa ser executado antes do login do usuário, esses são chamados de PreLoginAgents. Por exemplo, isso é útil para fornecer tecnologia assistiva no login. Eles também podem ser encontrados em /Library/LaunchAgents (veja aqui um exemplo).
Novos arquivos de configuração de Daemons ou Agents serão carregados após a próxima reinicialização ou usando launchctl load <target.plist> É também possível carregar arquivos .plist sem essa extensão com launchctl -F <file> (no entanto, esses arquivos plist não serão carregados automaticamente após a reinicialização).
É também possível descarregar com launchctl unload <target.plist> (o processo apontado por ele será encerrado),
Para garantir que não há nada (como uma substituição) impedindo um Agent ou Daemon de executar, execute: sudo launchctl load -w /System/Library/LaunchDaemos/com.apple.smdb.plist
Liste todos os agentes e daemons carregados pelo usuário atual:
Se um plist é de propriedade de um usuário, mesmo que esteja em pastas de daemon de sistema amplo, a tarefa será executada como o usuário e não como root. Isso pode prevenir alguns ataques de escalonamento de privilégios.
launchd é o primeiro processo em modo usuário que é iniciado a partir do kernel. O início do processo deve ser bem-sucedido e ele não pode sair ou falhar. Ele é até mesmo protegido contra alguns sinais de término.
Uma das primeiras coisas que launchd faria é iniciar todos os daemons como:
Daemons de temporizador baseados em tempo para serem executados:
atd (com.apple.atrun.plist): Tem um StartInterval de 30min
crond (com.apple.systemstats.daily.plist): Tem StartCalendarInterval para iniciar às 00:15
Daemons de rede como:
org.cups.cups-lpd: Escuta em TCP (SockType: stream) com SockServiceName: printer
SockServiceName deve ser uma porta ou um serviço de /etc/services
com.apple.xscertd.plist: Escuta em TCP na porta 1640
Daemons de caminho que são executados quando um caminho especificado muda:
com.apple.postfix.master: Verificando o caminho /etc/postfix/aliases
Daemons de notificações do IOKit:
com.apple.xartstorageremoted: "com.apple.iokit.matching" => { "com.apple.device-attach" => { "IOMatchLaunchStream" => 1 ...
Porta Mach:
com.apple.xscertd-helper.plist: Está indicando na entrada MachServices o nome com.apple.xscertd.helper
UserEventAgent:
Isso é diferente do anterior. Ele faz com que launchd inicie aplicativos em resposta a eventos específicos. No entanto, neste caso, o binário principal envolvido não é launchd, mas /usr/libexec/UserEventAgent. Ele carrega plugins da pasta restrita pelo SIP /System/Library/UserEventPlugins/ onde cada plugin indica seu inicializador na chave XPCEventModuleInitializer ou, no caso de plugins mais antigos, no dicionário CFPluginFactories sob a chave FB86416D-6164-2070-726F-70735C216EC0 de seu Info.plist.
Escrita: https://theevilbit.github.io/beyond/beyond_0001/ Escrita (xterm): https://theevilbit.github.io/beyond/beyond_0018/
Útil para contornar sandbox: ✅
Bypass TCC: ✅
Mas você precisa encontrar um aplicativo com um bypass TCC que execute um shell que carregue esses arquivos
~/.zshrc, ~/.zlogin, ~/.zshenv.zwc, ~/.zshenv, ~/.zprofile
Gatilho: Abrir um terminal com zsh
/etc/zshenv, /etc/zprofile, /etc/zshrc, /etc/zlogin
Gatilho: Abrir um terminal com zsh
Root necessário
~/.zlogout
Gatilho: Sair de um terminal com zsh
/etc/zlogout
Gatilho: Sair de um terminal com zsh
Root necessário
Potencialmente mais em: man zsh
~/.bashrc
Gatilho: Abrir um terminal com bash
/etc/profile (não funcionou)
~/.profile (não funcionou)
~/.xinitrc, ~/.xserverrc, /opt/X11/etc/X11/xinit/xinitrc.d/
Gatilho: Esperado para ser acionado com xterm, mas não está instalado e mesmo após a instalação, este erro é gerado: xterm: DISPLAY is not set
Ao iniciar um ambiente de shell como zsh ou bash, certos arquivos de inicialização são executados. O macOS atualmente usa /bin/zsh como o shell padrão. Este shell é acessado automaticamente quando o aplicativo Terminal é iniciado ou quando um dispositivo é acessado via SSH. Embora bash e sh também estejam presentes no macOS, eles precisam ser invocados explicitamente para serem usados.
A página de manual do zsh, que podemos ler com man zsh, tem uma longa descrição dos arquivos de inicialização.
Configurar a exploração indicada e sair e entrar novamente ou até mesmo reiniciar não funcionou para mim para executar o aplicativo. (O aplicativo não estava sendo executado, talvez precise estar em execução quando essas ações forem realizadas)
Escrita: https://theevilbit.github.io/beyond/beyond_0021/
~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist
Gatilho: Reiniciar reabrindo aplicativos
Todos os aplicativos a serem reabertos estão dentro do plist ~/Library/Preferences/ByHost/com.apple.loginwindow.<UUID>.plist
Portanto, para fazer os aplicativos reabertos lançarem o seu próprio, você só precisa adicionar seu aplicativo à lista.
O UUID pode ser encontrado listando esse diretório ou com ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformUUID/{print $4}'
Para verificar os aplicativos que serão reabertos, você pode fazer:
Para adicionar um aplicativo a esta lista você pode usar:
Útil para contornar sandbox: ✅
Contorno do TCC: ✅
O uso do Terminal para ter permissões FDA do usuário que o utiliza
~/Library/Preferences/com.apple.Terminal.plist
Gatilho: Abrir o Terminal
Em ~/Library/Preferences estão armazenadas as preferências do usuário nos Aplicativos. Algumas dessas preferências podem conter uma configuração para executar outros aplicativos/scripts.
Por exemplo, o Terminal pode executar um comando na Inicialização:
Essa configuração é refletida no arquivo ~/Library/Preferences/com.apple.Terminal.plist assim:
Então, se o plist das preferências do terminal no sistema puder ser sobrescrito, a funcionalidade open pode ser usada para abrir o terminal e esse comando será executado.
Você pode adicionar isso a partir da linha de comando com:
Útil para contornar sandbox: ✅
Contorno de TCC: ✅
Uso do Terminal para ter permissões FDA do usuário que o utiliza
Qualquer lugar
Gatilho: Abrir o Terminal
Se você criar um .terminal script e abri-lo, o aplicativo Terminal será automaticamente invocado para executar os comandos indicados nele. Se o aplicativo Terminal tiver alguns privilégios especiais (como TCC), seu comando será executado com esses privilégios especiais.
Experimente com:
Você também pode usar as extensões .command, .tool, com conteúdo de scripts de shell regulares e eles também serão abertos pelo Terminal.
Se o terminal tiver Acesso Total ao Disco, ele poderá completar essa ação (note que o comando executado será visível em uma janela do terminal).
Escrita: https://theevilbit.github.io/beyond/beyond_0013/ Escrita: https://posts.specterops.io/audio-unit-plug-ins-896d3434a882
/Library/Audio/Plug-Ins/HAL
Root necessário
Gatilho: Reiniciar coreaudiod ou o computador
/Library/Audio/Plug-ins/Components
Root necessário
Gatilho: Reiniciar coreaudiod ou o computador
~/Library/Audio/Plug-ins/Components
Gatilho: Reiniciar coreaudiod ou o computador
/System/Library/Components
Root necessário
Gatilho: Reiniciar coreaudiod ou o computador
De acordo com as escritas anteriores, é possível compilar alguns plugins de áudio e carregá-los.
Escrita: https://theevilbit.github.io/beyond/beyond_0028/
/System/Library/QuickLook
/Library/QuickLook
~/Library/QuickLook
/Applications/AppNameHere/Contents/Library/QuickLook/
~/Applications/AppNameHere/Contents/Library/QuickLook/
Plugins QuickLook podem ser executados quando você aciona a pré-visualização de um arquivo (pressione a barra de espaço com o arquivo selecionado no Finder) e um plugin que suporta esse tipo de arquivo está instalado.
É possível compilar seu próprio plugin QuickLook, colocá-lo em uma das localizações anteriores para carregá-lo e, em seguida, ir para um arquivo suportado e pressionar espaço para acioná-lo.
Isso não funcionou para mim, nem com o LoginHook do usuário nem com o LogoutHook do root
Escrita: https://theevilbit.github.io/beyond/beyond_0022/
Você precisa ser capaz de executar algo como defaults write com.apple.loginwindow LoginHook /Users/$USER/hook.sh
Localizado em ~/Library/Preferences/com.apple.loginwindow.plist
Eles estão obsoletos, mas podem ser usados para executar comandos quando um usuário faz login.
Esta configuração é armazenada em /Users/$USER/Library/Preferences/com.apple.loginwindow.plist
Para deletá-lo:
O usuário root é armazenado em /private/var/root/Library/Preferences/com.apple.loginwindow.plist
Aqui você pode encontrar locais de início úteis para bypass de sandbox que permitem que você simplesmente execute algo escrevendo em um arquivo e esperando condições não tão comuns como programas específicos instalados, ações de usuário "incomuns" ou ambientes.
Escrita: https://theevilbit.github.io/beyond/beyond_0004/
Útil para contornar a sandbox: ✅
No entanto, você precisa ser capaz de executar o binário crontab
Ou ser root
Bypass TCC: 🔴
/usr/lib/cron/tabs/, /private/var/at/tabs, /private/var/at/jobs, /etc/periodic/
Root necessário para acesso de gravação direto. Não é necessário root se você puder executar crontab <file>
Gatilho: Depende do trabalho cron
Liste os trabalhos cron do usuário atual com:
Você também pode ver todos os cron jobs dos usuários em /usr/lib/cron/tabs/ e /var/at/tabs/ (necessita de root).
No MacOS, várias pastas executando scripts com certa frequência podem ser encontradas em:
Lá você pode encontrar os cron jobs regulares, os at jobs (não muito utilizados) e os periodic jobs (principalmente usados para limpar arquivos temporários). Os jobs periódicos diários podem ser executados, por exemplo, com: periodic daily.
Para adicionar um user cronjob programaticamente, é possível usar:
Writeup: https://theevilbit.github.io/beyond/beyond_0002/
~/Library/Application Support/iTerm2/Scripts/AutoLaunch
Trigger: Abrir iTerm
~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt
Trigger: Abrir iTerm
~/Library/Preferences/com.googlecode.iterm2.plist
Trigger: Abrir iTerm
Scripts armazenados em ~/Library/Application Support/iTerm2/Scripts/AutoLaunch serão executados. Por exemplo:
ou:
O script ~/Library/Application Support/iTerm2/Scripts/AutoLaunch.scpt também será executado:
As preferências do iTerm2 localizadas em ~/Library/Preferences/com.googlecode.iterm2.plist podem indicar um comando a ser executado quando o terminal iTerm2 é aberto.
Essa configuração pode ser ajustada nas configurações do iTerm2:
E o comando é refletido nas preferências:
Você pode definir o comando a ser executado com:
Altamente provável que existam outras maneiras de abusar das preferências do iTerm2 para executar comandos arbitrários.
Escrita: https://theevilbit.github.io/beyond/beyond_0007/
Útil para contornar sandbox: ✅
Mas o xbar deve estar instalado
Contorno do TCC: ✅
Solicita permissões de Acessibilidade
~/Library/Application\ Support/xbar/plugins/
Gatilho: Uma vez que o xbar é executado
Se o popular programa xbar estiver instalado, é possível escrever um script shell em ~/Library/Application\ Support/xbar/plugins/ que será executado quando o xbar for iniciado:
Writeup: https://theevilbit.github.io/beyond/beyond_0008/
Útil para contornar sandbox: ✅
Mas o Hammerspoon deve ser instalado
Contorno TCC: ✅
Ele solicita permissões de Acessibilidade
~/.hammerspoon/init.lua
Gatilho: Uma vez que o hammerspoon é executado
Hammerspoon serve como uma plataforma de automação para macOS, aproveitando a linguagem de script LUA para suas operações. Notavelmente, suporta a integração de código AppleScript completo e a execução de scripts de shell, aprimorando significativamente suas capacidades de script.
O aplicativo procura um único arquivo, ~/.hammerspoon/init.lua, e quando iniciado, o script será executado.
Útil para contornar sandbox: ✅
Mas o BetterTouchTool deve estar instalado
Contorno TCC: ✅
Ele solicita permissões de Automação-Curtas e Acessibilidade
~/Library/Application Support/BetterTouchTool/*
Esta ferramenta permite indicar aplicativos ou scripts a serem executados quando alguns atalhos são pressionados. Um atacante pode ser capaz de configurar seu próprio atalho e ação a serem executados no banco de dados para fazer com que ele execute código arbitrário (um atalho pode ser apenas pressionar uma tecla).
Útil para contornar sandbox: ✅
Mas o Alfred deve estar instalado
Contorno TCC: ✅
Ele solicita permissões de Automação, Acessibilidade e até mesmo Acesso Completo ao Disco
???
Permite criar fluxos de trabalho que podem executar código quando certas condições são atendidas. Potencialmente, é possível para um atacante criar um arquivo de fluxo de trabalho e fazer o Alfred carregá-lo (é necessário pagar pela versão premium para usar fluxos de trabalho).
Escrita: https://theevilbit.github.io/beyond/beyond_0006/
Útil para contornar sandbox: ✅
Mas o ssh precisa estar habilitado e em uso
Contorno TCC: ✅
O uso do SSH deve ter acesso FDA
~/.ssh/rc
Gatilho: Login via ssh
/etc/ssh/sshrc
Root necessário
Gatilho: Login via ssh
Para ativar o ssh requer Acesso Completo ao Disco:
Por padrão, a menos que PermitUserRC no em /etc/ssh/sshd_config, quando um usuário faz login via SSH, os scripts /etc/ssh/sshrc e ~/.ssh/rc serão executados.
Escrita: https://theevilbit.github.io/beyond/beyond_0003/
~/Library/Application Support/com.apple.backgroundtaskmanagementagent
Gatilho: Login
Payload de exploração armazenado chamando osascript
/var/db/com.apple.xpc.launchd/loginitems.501.plist
Gatilho: Login
Root necessário
Em Preferências do Sistema -> Usuários & Grupos -> Itens de Login você pode encontrar itens a serem executados quando o usuário faz login. É possível listá-los, adicionar e remover pela linha de comando:
Esses itens são armazenados no arquivo ~/Library/Application Support/com.apple.backgroundtaskmanagementagent
Os itens de login também podem ser indicados usando a API SMLoginItemSetEnabled, que armazenará a configuração em /var/db/com.apple.xpc.launchd/loginitems.501.plist
(Consulte a seção anterior sobre Itens de Login, esta é uma extensão)
Se você armazenar um arquivo ZIP como um Item de Login, o Archive Utility o abrirá e, se o zip foi, por exemplo, armazenado em ~/Library e continha a pasta LaunchAgents/file.plist com um backdoor, essa pasta será criada (não é por padrão) e o plist será adicionado, de modo que na próxima vez que o usuário fizer login novamente, o backdoor indicado no plist será executado.
Outra opção seria criar os arquivos .bash_profile e .zshenv dentro do HOME do usuário, para que, se a pasta LaunchAgents já existir, essa técnica ainda funcione.
Escrita: https://theevilbit.github.io/beyond/beyond_0014/
Necessita executar at e deve estar habilitado
As tarefas at são projetadas para agendar tarefas únicas a serem executadas em determinados momentos. Ao contrário dos trabalhos cron, as tarefas at são automaticamente removidas após a execução. É crucial notar que essas tarefas são persistentes entre reinicializações do sistema, marcando-as como potenciais preocupações de segurança sob certas condições.
Por padrão, elas estão desativadas, mas o usuário root pode habilitá-las com:
Isso criará um arquivo em 1 hora:
Verifique a fila de trabalhos usando atq:
Acima, podemos ver dois trabalhos agendados. Podemos imprimir os detalhes do trabalho usando at -c JOBNUMBER
Se as tarefas AT não estiverem habilitadas, as tarefas criadas não serão executadas.
Os arquivos de trabalho podem ser encontrados em /private/var/at/jobs/
O nome do arquivo contém a fila, o número do trabalho e o horário em que está agendado para ser executado. Por exemplo, vamos dar uma olhada em a0001a019bdcd2.
a - esta é a fila
0001a - número do trabalho em hex, 0x1a = 26
019bdcd2 - tempo em hex. Representa os minutos passados desde a época. 0x019bdcd2 é 26991826 em decimal. Se multiplicarmos por 60, obtemos 1619509560, que é GMT: 2021. Abril 27., Terça-feira 7:46:00.
Se imprimirmos o arquivo do trabalho, descobrimos que contém as mesmas informações que obtivemos usando at -c.
Escrita: https://theevilbit.github.io/beyond/beyond_0024/ Escrita: https://posts.specterops.io/folder-actions-for-persistence-on-macos-8923f222343d
Útil para contornar sandbox: ✅
Mas você precisa ser capaz de chamar osascript com argumentos para contatar System Events para poder configurar Ações de Pasta
Bypass TCC: 🟠
Possui algumas permissões básicas do TCC, como Desktop, Documents e Downloads
/Library/Scripts/Folder Action Scripts
Root necessário
Gatilho: Acesso à pasta especificada
~/Library/Scripts/Folder Action Scripts
Gatilho: Acesso à pasta especificada
Ações de Pasta são scripts automaticamente acionados por mudanças em uma pasta, como adicionar, remover itens ou outras ações, como abrir ou redimensionar a janela da pasta. Essas ações podem ser utilizadas para várias tarefas e podem ser acionadas de diferentes maneiras, como usando a interface do Finder ou comandos de terminal.
Para configurar Ações de Pasta, você tem opções como:
Criar um fluxo de trabalho de Ação de Pasta com Automator e instalá-lo como um serviço.
Anexar um script manualmente via a Configuração de Ações de Pasta no menu de contexto de uma pasta.
Utilizar OSAScript para enviar mensagens de Evento Apple para o System Events.app para configurar programaticamente uma Ação de Pasta.
Este método é particularmente útil para embutir a ação no sistema, oferecendo um nível de persistência.
O seguinte script é um exemplo do que pode ser executado por uma Ação de Pasta:
Para tornar o script acima utilizável por Ações de Pasta, compile-o usando:
Após o script ser compilado, configure as Ações de Pasta executando o script abaixo. Este script habilitará as Ações de Pasta globalmente e anexará especificamente o script compilado anteriormente à pasta Desktop.
Execute o script de configuração com:
Esta é a maneira de implementar essa persistência via GUI:
Este é o script que será executado:
Compile-o com: osacompile -l JavaScript -o folder.scpt source.js
Mova-o para:
Então, abra o aplicativo Folder Actions Setup, selecione a pasta que você gostaria de monitorar e selecione no seu caso folder.scpt (no meu caso, eu a chamei de output2.scp):
Agora, se você abrir essa pasta com o Finder, seu script será executado.
Essa configuração foi armazenada no plist localizado em ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist em formato base64.
Agora, vamos tentar preparar essa persistência sem acesso à GUI:
Copie ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist para /tmp para fazer um backup:
cp ~/Library/Preferences/com.apple.FolderActionsDispatcher.plist /tmp
Remova as Ações de Pasta que você acabou de definir:
Agora que temos um ambiente vazio
Copie o arquivo de backup: cp /tmp/com.apple.FolderActionsDispatcher.plist ~/Library/Preferences/
Abra o Folder Actions Setup.app para consumir essa configuração: open "/System/Library/CoreServices/Applications/Folder Actions Setup.app/"
E isso não funcionou para mim, mas essas são as instruções do relatório :(
Relatório: https://theevilbit.github.io/beyond/beyond_0027/
Útil para contornar sandbox: ✅
Mas você precisa ter instalado um aplicativo malicioso dentro do sistema
Bypass TCC: 🔴
~/Library/Preferences/com.apple.dock.plist
Gatilho: Quando o usuário clica no aplicativo dentro do dock
Todos os aplicativos que aparecem no Dock estão especificados dentro do plist: ~/Library/Preferences/com.apple.dock.plist
É possível adicionar um aplicativo apenas com:
Usando alguma engenharia social, você poderia se passar, por exemplo, pelo Google Chrome dentro do dock e realmente executar seu próprio script:
Writeup: https://theevilbit.github.io/beyond/beyond_0017
Útil para contornar o sandbox: 🟠
Uma ação muito específica precisa acontecer
Você acabará em outro sandbox
Bypass do TCC: 🔴
/Library/ColorPickers
Root necessário
Gatilho: Use o seletor de cores
~/Library/ColorPickers
Gatilho: Use o seletor de cores
Compile um seletor de cores bundle com seu código (você pode usar este aqui, por exemplo) e adicione um construtor (como na seção Protetor de Tela) e copie o bundle para ~/Library/ColorPickers.
Então, quando o seletor de cores for acionado, seu código também deve ser executado.
Note que o binário que carrega sua biblioteca tem um sandbox muito restritivo: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/LegacyExternalColorPickerService-x86_64.xpc/Contents/MacOS/LegacyExternalColorPickerService-x86_64
Escrita: https://theevilbit.github.io/beyond/beyond_0026/ Escrita: https://objective-see.org/blog/blog_0x11.html
Útil para contornar sandbox: Não, porque você precisa executar seu próprio aplicativo
Contorno do TCC: ???
Um aplicativo específico
Um exemplo de aplicativo com uma Extensão de Sincronização do Finder pode ser encontrado aqui.
Os aplicativos podem ter Extensões de Sincronização do Finder. Esta extensão será incorporada a um aplicativo que será executado. Além disso, para que a extensão possa executar seu código, ela deve ser assinada com algum certificado de desenvolvedor da Apple válido, deve ser sandboxed (embora exceções relaxadas possam ser adicionadas) e deve ser registrada com algo como:
Writeup: https://theevilbit.github.io/beyond/beyond_0016/ Writeup: https://posts.specterops.io/saving-your-access-d562bf5bf90b
/System/Library/Screen Savers
Root necessário
Gatilho: Selecione o protetor de tela
/Library/Screen Savers
Root necessário
Gatilho: Selecione o protetor de tela
~/Library/Screen Savers
Gatilho: Selecione o protetor de tela
Crie um novo projeto no Xcode e selecione o template para gerar um novo Protetor de Tela. Em seguida, adicione seu código a ele, por exemplo, o seguinte código para gerar logs.
Compile e copie o pacote .saver para ~/Library/Screen Savers. Depois, abra a GUI do Protetor de Tela e, se você apenas clicar nele, deve gerar muitos logs:
Observe que, devido ao fato de que dentro das permissões do binário que carrega este código (/System/Library/Frameworks/ScreenSaver.framework/PlugIns/legacyScreenSaver.appex/Contents/MacOS/legacyScreenSaver) você pode encontrar com.apple.security.app-sandbox, você estará dentro do sandbox comum de aplicativos.
Saver code:
writeup: https://theevilbit.github.io/beyond/beyond_0011/
Útil para contornar o sandbox: 🟠
Mas você acabará em um sandbox de aplicativo
Bypass TCC: 🔴
O sandbox parece muito limitado
~/Library/Spotlight/
Gatilho: Um novo arquivo com uma extensão gerenciada pelo plugin do spotlight é criado.
/Library/Spotlight/
Gatilho: Um novo arquivo com uma extensão gerenciada pelo plugin do spotlight é criado.
Root necessário
/System/Library/Spotlight/
Gatilho: Um novo arquivo com uma extensão gerenciada pelo plugin do spotlight é criado.
Root necessário
Some.app/Contents/Library/Spotlight/
Gatilho: Um novo arquivo com uma extensão gerenciada pelo plugin do spotlight é criado.
Novo aplicativo necessário
Spotlight é o recurso de busca integrado do macOS, projetado para fornecer aos usuários acesso rápido e abrangente aos dados em seus computadores. Para facilitar essa capacidade de busca rápida, o Spotlight mantém um banco de dados proprietário e cria um índice analisando a maioria dos arquivos, permitindo buscas rápidas tanto por nomes de arquivos quanto por seu conteúdo.
O mecanismo subjacente do Spotlight envolve um processo central chamado 'mds', que significa 'servidor de metadados'. Este processo orquestra todo o serviço Spotlight. Complementando isso, existem vários daemons 'mdworker' que realizam uma variedade de tarefas de manutenção, como indexar diferentes tipos de arquivos (ps -ef | grep mdworker). Essas tarefas são possibilitadas por meio de plugins importadores do Spotlight, ou ".mdimporter bundles", que permitem que o Spotlight entenda e indexe conteúdo em uma ampla gama de formatos de arquivo.
Os plugins ou .mdimporter bundles estão localizados nos lugares mencionados anteriormente e, se um novo bundle aparecer, ele é carregado em um minuto (não é necessário reiniciar nenhum serviço). Esses bundles precisam indicar quais tipos de arquivo e extensões podem gerenciar, assim, o Spotlight os usará quando um novo arquivo com a extensão indicada for criado.
É possível encontrar todos os mdimporters carregados executando:
E, por exemplo, /Library/Spotlight/iBooksAuthor.mdimporter é usado para analisar esse tipo de arquivo (extensões .iba e .book, entre outras):
Se você verificar o Plist de outros mdimporter, pode não encontrar a entrada UTTypeConformsTo. Isso ocorre porque é um Identificadores de Tipo Uniforme (UTI) embutido e não precisa especificar extensões.
Além disso, os plugins padrão do sistema sempre têm precedência, então um atacante só pode acessar arquivos que não são indexados pelos próprios mdimporters da Apple.
Para criar seu próprio importador, você pode começar com este projeto: https://github.com/megrimm/pd-spotlight-importer e então mudar o nome, o CFBundleDocumentTypes e adicionar UTImportedTypeDeclarations para que suporte a extensão que você gostaria de suportar e refletir isso em schema.xml.
Então mude o código da função GetMetadataForFile para executar seu payload quando um arquivo com a extensão processada for criado.
Finalmente, construa e copie seu novo .mdimporter para um dos três locais anteriores e você pode verificar sempre que ele for carregado monitorando os logs ou verificando mdimport -L.
Parece que isso não está mais funcionando.
Escrita: https://theevilbit.github.io/beyond/beyond_0009/
/System/Library/PreferencePanes
/Library/PreferencePanes
~/Library/PreferencePanes
Parece que isso não está mais funcionando.
Aqui você pode encontrar locais de início úteis para bypass de sandbox que permitem que você simplesmente execute algo escrevendo em um arquivo sendo root e/ou exigindo outras condições estranhas.
Escrita: https://theevilbit.github.io/beyond/beyond_0019/
/etc/periodic/daily, /etc/periodic/weekly, /etc/periodic/monthly, /usr/local/etc/periodic
Root necessário
Gatilho: Quando chegar a hora
/etc/daily.local, /etc/weekly.local ou /etc/monthly.local
Root necessário
Gatilho: Quando chegar a hora
Os scripts periódicos (/etc/periodic) são executados devido aos daemons de lançamento configurados em /System/Library/LaunchDaemons/com.apple.periodic*. Note que os scripts armazenados em /etc/periodic/ são executados como o proprietário do arquivo, então isso não funcionará para uma potencial escalada de privilégios.
Existem outros scripts periódicos que serão executados indicados em /etc/defaults/periodic.conf:
Se você conseguir escrever em qualquer um dos arquivos /etc/daily.local, /etc/weekly.local ou /etc/monthly.local, ele será executado mais cedo ou mais tarde.
Observe que o script periódico será executado como o proprietário do script. Portanto, se um usuário comum for o proprietário do script, ele será executado como esse usuário (isso pode prevenir ataques de escalonamento de privilégios).
Escrita: Linux Hacktricks PAM Escrita: https://theevilbit.github.io/beyond/beyond_0005/
Root sempre necessário
Como o PAM está mais focado em persistência e malware do que em execução fácil dentro do macOS, este blog não dará uma explicação detalhada, leia as escritas para entender melhor essa técnica.
Verifique os módulos PAM com:
Uma técnica de persistência/escalonamento de privilégios que abusa do PAM é tão simples quanto modificar o módulo /etc/pam.d/sudo adicionando no início a linha:
Então vai parecer algo assim:
E, portanto, qualquer tentativa de usar sudo funcionará.
Observe que este diretório é protegido pelo TCC, então é altamente provável que o usuário receba um aviso solicitando acesso.
Outro bom exemplo é o su, onde você pode ver que também é possível fornecer parâmetros para os módulos PAM (e você também poderia backdoor este arquivo):
Writeup: https://theevilbit.github.io/beyond/beyond_0028/ Writeup: https://posts.specterops.io/persistent-credential-theft-with-authorization-plugins-d17b34719d65
Útil para contornar o sandbox: 🟠
Mas você precisa ser root e fazer configurações extras
Bypass do TCC: ???
/Library/Security/SecurityAgentPlugins/
Root necessário
Também é necessário configurar o banco de dados de autorização para usar o plugin
Você pode criar um plugin de autorização que será executado quando um usuário fizer login para manter a persistência. Para mais informações sobre como criar um desses plugins, consulte os writeups anteriores (e tenha cuidado, um mal escrito pode te trancar fora e você precisará limpar seu mac a partir do modo de recuperação).
Mova o pacote para o local a ser carregado:
Finalmente, adicione a regra para carregar este Plugin:
O evaluate-mechanisms informará o framework de autorização que precisará chamar um mecanismo externo para autorização. Além disso, privileged fará com que seja executado pelo root.
Acione-o com:
E então o grupo staff deve ter acesso sudo (leia /etc/sudoers para confirmar).
Escrita: https://theevilbit.github.io/beyond/beyond_0030/
/private/etc/man.conf
Root necessário
/private/etc/man.conf: Sempre que man é usado
O arquivo de configuração /private/etc/man.conf indica o binário/script a ser usado ao abrir arquivos de documentação man. Assim, o caminho para o executável pode ser modificado para que sempre que o usuário usar man para ler alguma documentação, um backdoor seja executado.
Por exemplo, definido em /private/etc/man.conf:
E então crie /tmp/view como:
Escrita: https://theevilbit.github.io/beyond/beyond_0023/
Útil para contornar sandbox: 🟠
Mas você precisa ser root e o apache precisa estar em execução
Contorno TCC: 🔴
Httpd não tem permissões
/etc/apache2/httpd.conf
Root necessário
Gatilho: Quando o Apache2 é iniciado
Você pode indicar em /etc/apache2/httpd.conf para carregar um módulo adicionando uma linha como:
Dessa forma, seu módulo compilado será carregado pelo Apache. A única coisa é que você precisa assiná-lo com um certificado Apple válido, ou precisa adicionar um novo certificado confiável no sistema e assiná-lo com ele.
Então, se necessário, para garantir que o servidor será iniciado, você pode executar:
Exemplo de código para o Dylb:
Writeup: https://theevilbit.github.io/beyond/beyond_0031/
Útil para contornar sandbox: 🟠
Mas você precisa ser root, auditd estar em execução e causar um aviso
Bypass TCC: 🔴
/etc/security/audit_warn
Root necessário
Gatilho: Quando auditd detecta um aviso
Sempre que auditd detecta um aviso, o script /etc/security/audit_warn é executado. Então você poderia adicionar seu payload nele.
Você pode forçar um aviso com sudo audit -n.
Isso está obsoleto, então nada deve ser encontrado nessas diretórios.
O StartupItem é um diretório que deve estar posicionado dentro de /Library/StartupItems/ ou /System/Library/StartupItems/. Uma vez que este diretório é estabelecido, ele deve conter dois arquivos específicos:
Um script rc: Um script shell executado na inicialização.
Um arquivo plist, especificamente nomeado StartupParameters.plist, que contém várias configurações.
Certifique-se de que tanto o script rc quanto o arquivo StartupParameters.plist estejam corretamente colocados dentro do diretório StartupItem para que o processo de inicialização os reconheça e utilize.
Não consigo encontrar este componente no meu macOS, então para mais informações, verifique o writeup
Writeup: https://theevilbit.github.io/beyond/beyond_0023/
Introduzido pela Apple, emond é um mecanismo de registro que parece estar subdesenvolvido ou possivelmente abandonado, mas ainda permanece acessível. Embora não seja particularmente benéfico para um administrador de Mac, este serviço obscuro poderia servir como um método sutil de persistência para atores de ameaças, provavelmente não percebido pela maioria dos administradores de macOS.
Para aqueles cientes de sua existência, identificar qualquer uso malicioso de emond é simples. O LaunchDaemon do sistema para este serviço busca scripts para executar em um único diretório. Para inspecionar isso, o seguinte comando pode ser usado:
Escrita: https://theevilbit.github.io/beyond/beyond_0018/
/opt/X11/etc/X11/xinit/privileged_startx.d
Root necessário
Gatilho: Com XQuartz
XQuartz não está mais instalado no macOS, então se você quiser mais informações, confira a escrita.
É tão complicado instalar kext mesmo como root que eu não considerarei isso para escapar de sandboxes ou mesmo para persistência (a menos que você tenha um exploit)
Para instalar um KEXT como um item de inicialização, ele precisa ser instalado em um dos seguintes locais:
/System/Library/Extensions
Arquivos KEXT incorporados no sistema operacional OS X.
/Library/Extensions
Arquivos KEXT instalados por software de terceiros
Você pode listar os arquivos kext atualmente carregados com:
Para mais informações sobre extensões de kernel, ver esta seção.
Escrita: https://theevilbit.github.io/beyond/beyond_0029/
/usr/local/bin/amstoold
Root necessário
Aparentemente, o plist de /System/Library/LaunchAgents/com.apple.amstoold.plist estava usando este binário enquanto expunha um serviço XPC... o problema é que o binário não existia, então você poderia colocar algo lá e, quando o serviço XPC fosse chamado, seu binário seria chamado.
Não consigo mais encontrar isso no meu macOS.
Escrita: https://theevilbit.github.io/beyond/beyond_0015/
/Library/Preferences/Xsan/.xsanrc
Root necessário
Gatilho: Quando o serviço é executado (raramente)
Aparentemente, não é muito comum executar este script e eu não consegui encontrá-lo no meu macOS, então, se você quiser mais informações, verifique a escrita.
Isso não está funcionando nas versões modernas do MacOS
Também é possível colocar aqui comandos que serão executados na inicialização. Exemplo de script rc.common regular:
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
