Forense de shell no Linux: o que o Atuin revela (e esconde) sobre o histórico de comandos
O SANS Internet Storm Center analisou as fragilidades do histórico de shell tradicional em sistemas Unix/Linux e como a ferramenta Atuin muda esse cenário ao substituir o arquivo plano .bash_history por um banco SQLite com metadados ricos por comando. O texto explica quais campos passam a ficar disponíveis para um perito e alerta para armadilhas de interpretação quando há sincronização de histórico entre múltiplas máquinas.
O artigo do SANS ISC, publicado em 7 de agosto de 2026, parte de um problema conhecido de quem faz perícia em sistemas Linux: o histórico de shell tradicional é um dos registros de atividade mais pobres do sistema. Arquivos como .bash_history ficam em memória durante a sessão e só são gravados em disco quando o shell é encerrado corretamente, não possuem timestamp por padrão na maioria das configurações, têm tamanho limitado (descartando comandos antigos por rotação) e podem ser apagados ou desativados pelo próprio usuário com um simples "unset HISTFILE" ou histórico em /dev/null.
O Atuin ataca esse problema trocando o arquivo plano por um banco SQLite local, inicializado via hook no arquivo de configuração do shell (bashrc, zshrc etc.). Cada comando executado passa a ser gravado com contexto muito mais rico do que um simples texto: diretório de trabalho no momento da execução, duração do comando, código de saída, identificador de sessão, hostname da máquina e timestamp em nanosegundos no padrão UTC. A ferramenta também oferece sincronização opcional entre máquinas com criptografia ponta-a-ponta, permitindo consolidar o histórico de um mesmo usuário em vários hosts.
Para quem faz análise forense, isso é ao mesmo tempo uma oportunidade e uma cilada. Do lado positivo, o banco SQLite viabiliza reconstrução de sessões inteiras por agrupamento de session_id, correlação de comandos com seus códigos de retorno e diretórios, e recuperação de registros "soft-deleted" que a ferramenta apenas marca como removidos sem apagar fisicamente — um alvo clássico para técnicas de carving em bancos SQLite e nos arquivos WAL (write-ahead log) associados.
Do lado das armadilhas, o artigo chama atenção para um ponto que pode levar a atribuições erradas: como o Atuin sincroniza histórico entre máquinas, a presença de um comando no banco de uma estação não prova que ele foi executado localmente ali — pode ter chegado via sync de outro host do mesmo usuário. Na direção oposta, a ausência de um comando também não prova que ele não ocorreu: filtros de histórico configuráveis permitem omissão seletiva, e shells não-interativos (scripts, comandos via SSH sem PTY, cron) frequentemente escapam da captura do Atuin da mesma forma que escapavam do histórico tradicional.
Na prática, a recomendação que fica implícita para o investigador é tratar o Atuin como uma fonte adicional e mais granular, não como substituto de uma reconstrução de timeline baseada em múltiplas fontes: logs de auditoria (auditd), histórico de outros shells presentes no sistema, artefatos de sessão SSH e metadados do sistema de arquivos. A cadeia de custódia técnica exige documentar de onde cada entrada do banco Atuin veio (execução local vs. sincronização) antes de usá-la como evidência de uma ação específica naquela máquina.