CLI/TUI em Python para triagem forense de sistemas Ubuntu — detecta e corrige mecanismos de persistência com coleta de artefatos, correlação de linha do tempo e integração com Wazuh.
Triagem forense para sistemas Ubuntu em execução — coleta automatizada de artefatos, detecção de persistência e remediação guiada em cerca de um minuto.
Quando você suspeita que um sistema Linux foi comprometido, os primeiros 30-40 minutos geralmente são gastos executando os mesmos dez comandos em sequência: verificar processos em execução, procurar tarefas cron estranhas, fazer grep de LD_PRELOAD, escanear authorized_keys em busca de novas entradas, auditar sudoers. Cada etapa é manual, com troca de contexto e propensa a erros sob pressão. Perca uma fonte — digamos, /etc/sudoers.d/ em vez de apenas /etc/sudoers, ou crontabs de usuário além de /etc/cron.d/ — e você tem um quadro incompleto.
As opções existentes não resolvem isso de forma limpa. O lynis é um auditor de hardening, não uma ferramenta de triagem — ele reporta fraquezas de configuração em um sistema limpo e gera ruído em um sistema comprometido. O chkrootkit e o rkhunter verificam assinaturas de rootkits conhecidos, mas são cegos a técnicas de persistência novas, como timers systemd abusados ou entradas cron com aparência legítima. Consultas genéricas de SIEM exigem infraestrutura de logs que pode não existir no sistema que você está analisando. E suítes forenses como o Volatility visam imagens de memória, não um shell ativo em um host em execução.
A lacuna é uma ferramenta que roda no sistema em execução agora mesmo, cobre os vetores de persistência mais comuns, correlaciona atividade entre fontes de log em uma linha do tempo e diz exatamente o que olhar — sem exigir um agente externo, um banco de dados ou uma conexão com a internet.
O ubuntils roda em quatro estágios sequenciais:
/proc, tabelas cron, unidades systemd, chaves SSH, arquivos sudoers, definições de ambiente, integridade de pacotes (dpkg --verify), configuração PAM/NSS e módulos de kernel carregados. A maioria dos coletores termina em um ou dois segundos; o dpkg --verify, que reverifica cada arquivo de pacote instalado, domina — uma varredura completa levou de 29 a 68 segundos em uma VM desktop Ubuntu 26.04 arm64.--rules — sobre os artefatos coletados, produzindo uma lista de achados classificada e com pontuação de confiança em cerca de um segundo.--json).O próprio ubuntils não faz chamadas de rede, e todos os recursos — incluindo regras personalizadas e correlação — rodam contra artefatos coletados localmente. A única forma de os achados saírem do host é a integração com o Wazuh: se um agente Wazuh estiver instalado, um scan ao vivo grava seus achados em um arquivo local que o agente então envia ao seu manager. Passe --no-wazuh para desativar isso em uma execução.
ubuntils scan permanece inalterado por tudo abaixo — ele continua 100% ativo, em host único, e cada flag existente funciona de forma idêntica. Dois comandos adicionais, collect e analyze, dividem o mesmo pipeline de detecção/linha do tempo em um fluxo de trabalho offline de adquirir-e-analisar para casos em que você não pode (ou não quer) executar a detecção diretamente no host sob investigação — consulte Análise offline: collect e analyze abaixo, incluindo suas ressalvas de cobertura de detecção.
Ubuntu 22.04+ e qualquer sistema com PEP 668 (recomendado):
Ubuntu 22.04+ bloqueia pip install em todo o sistema. Use pipx — ele gerencia o ambiente de forma transparente para que você nunca precise pensar nisso:
sudo apt install pipx -y
pipx ensurepath # then open a new shell
git clone https://github.com/asmitdesai/ubuntils.git
cd ubuntils
pipx install -e .
ubuntils scan # not `ubuntils scan` — see below
Execute-o como seu usuário normal: scan e collect se re-invocam sob sudo. Digitar ubuntils … você mesmo falha com command not found, porque o secure_path do sudo não inclui ~/.local/bin, onde o pipx coloca o comando. Se você precisar iniciá-lo a partir de um shell root, chame o binário instalado pelo caminho (~youruser/.local/bin/ubuntils scan), ou instale em um ambiente virtual:
python3 -m venv .venv
.venv/bin/pip install -e .
.venv/bin/ubuntils scan
Sistemas mais antigos / instalação manual:
git clone https://github.com/asmitdesai/ubuntils.git
cd ubuntils
pip install -r requirements.txt -e .
ubuntils scan
ubuntils requer root para acesso completo aos artefatos. Se você executar ubuntils scan como um usuário não-root, ele se re-invocará automaticamente com sudo usando o mesmo interpretador Python (por caminho absoluto), de modo que o ambiente correto seja usado sem encaminhar seu PATH para o processo root. Todo comando externo (ss, dpkg, systemctl, …) é resolvido em um caminho de busca fixo, pertencente ao root, nunca o seu PATH. Executar sem root ignorará /etc/shadow, algumas entradas de /proc e arquivos cron protegidos, e registrará avisos para cada um.
Somente detecção — TUI interativa:
ubuntils scan
Detecção com saída JSON salva em arquivo:
ubuntils scan --json > /tmp/triage-$(hostname)-$(date +%Y%m%d).json
Detecção com pré-visualização de remediação via CLI (dry run — nenhuma alteração aplicada):
ubuntils scan --remediate
Detecção com remediação via CLI aplicada:
ubuntils scan --remediate --confirm
Versão para impressão:
ubuntils version
Colete um pacote à prova de adulteração para análise posterior ou offline:
ubuntils collect --output /path/to/bundle.tar.gz
Analisar um pacote previamente coletado (não requer root):
ubuntils analyze /path/to/bundle.tar.gz --json
Analise uma imagem forense montada ou uma árvore de sistema de arquivos extraída em vez de um pacote:
ubuntils analyze --root /mnt/forensic-image --json
Consulte Análise offline: coletar e analisar para o formato do bundle e — importante — o que a análise offline não consegue detectar em comparação com um scan ao vivo.