Parte 1 — Linux
1.1 A filosofia: "tudo é arquivo"
No Linux, quase tudo é tratado como arquivo: um documento é arquivo, um disco é arquivo (/dev/sda), um processo tem representação em arquivo (/proc/1234), até uma conexão de rede aparece como arquivo. As mesmas ferramentas (cat, grep, ls) servem para inspecionar coisas muito diferentes. Imagine um escritório onde tudo — pessoas, salas, telefones — tem uma ficha padronizada no mesmo formato: você aprende a ler uma ficha e investiga qualquer coisa.
1.2 Estrutura de diretórios (FHS)
O Linux organiza tudo a partir da raiz / (não existe "C:"). É uma árvore invertida.
| Diretório | O que guarda | Relevância para cyber |
|---|---|---|
| /bin, /usr/bin | Comandos/executáveis | Binários adulterados = comprometimento |
| /sbin | Comandos de administração | — |
| /etc | Arquivos de configuração | Senhas, serviços, rede — ouro |
| /home | Pastas dos usuários | Dados, chaves SSH, histórico |
| /root | Pasta do superusuário | Alvo nobre |
| /var | Dados variáveis: logs (/var/log), web | A investigação vive aqui |
| /tmp | Temporários (limpo no boot) | Malware adora (gravável por todos) |
| /proc | Pseudo-arquivos de processos e kernel | Investigar processos em tempo real |
| /dev | Dispositivos (discos, terminais) | — |
| /boot | Kernel e arquivos de inicialização | — |
Dois lugares merecem seu olho de imediato: /etc (config, credenciais) e /var/log (o que aconteceu). Malware frequentemente se esconde em /tmp, /dev/shm ou pastas ocultas (que começam com ponto, tipo /home/user/.config/.oculto).
1.3 Terminal e shell
O shell é o interpretador de comandos (o mais comum é o Bash). É a interface mais poderosa do sistema — e por isso a mais visada.
pwd # onde estou
ls -la # lista tudo, com detalhes e ocultos
cd /var/log # mudar de diretório
cat arquivo # mostrar conteúdo
find / -name "*.conf" 2>/dev/null # procurar arquivos
grep "erro" log.txt # buscar texto dentro de arquivos
history # comandos digitados pelo usuárioO pipe | encadeia comandos (a saída de um vira entrada do outro), a essência do poder do Linux:
cat /etc/passwd | grep "/bin/bash" | wc -l # quantos usuários têm shell bash
ps aux | grep ssh # processos com "ssh" no nomeO history de um usuário (~/.bash_history) conta o que a pessoa (ou o atacante) digitou. Numa investigação, é uma das primeiras coisas a olhar — mas atacantes espertos limpam ou desabilitam o histórico, e isso, por si só, já é um indício.
1.4 Permissões — o coração do modelo de segurança do Linux
-rwxr-xr-- 1 julio devs 4096 Jan 10 12:00 script.sh
│└┬┘└┬┘└┬┘
│ │ │ └── outros: r-- (só ler)
│ │ └───── grupo: r-x (ler e executar)
│ └──────── dono: rwx (ler, escrever, executar)
└────────── tipo: - arquivo | d diretório | l linkCada trio é r(4) w(2) x(1), para dono → grupo → outros. Soma por categoria: rwx=7, rw-=6, r-x=5, r--=4. Então rwxr-xr-- = 754.
chmod 640 arquivo # dono rw, grupo r, outros nada
chmod +x script.sh # dá permissão de execução
chmod u+x,g-w arquivo # simbólico: +x pro dono, tira w do grupo
chown julio:devs arquivo # muda dono e grupoPermissões especiais que atacantes exploram:
| Bit | O que faz | Perigo |
|---|---|---|
| SUID | Executa com a permissão do dono do arquivo, não de quem roda | Binário root com SUID e explorável → escalada para root |
| SGID | Executa com a permissão do grupo | Similar |
| Sticky | Em pastas: só o dono do arquivo pode apagá-lo (ex.: /tmp) | Proteção |
find / -perm -4000 -type f 2>/dev/null # todos os binários com SUIDPermissões mal configuradas são uma das causas nº 1 de escalada de privilégio. Um script executável por "outros" que roda como root, um /etc/shadow legível por todos, um binário SUID vulnerável — tudo isso é caminho de usuário comum → root. Defesa: menor privilégio, auditar SUID/SGID e nunca dar 777 ("777" = todo mundo pode tudo = pesadelo).
1.5 Usuários e grupos
julio:x:1000:1000:Julio Martins:/home/julio:/bin/bash
│ │ │ │ │ │ │
user │ UID GID nome home shell
└── senha fica no shadow (o "x")/etc/passwd lista usuários (legível por todos); /etc/shadow guarda os hashes (só root lê), alvo de quebra offline; /etc/group os grupos. UID 0 = root — se qualquer conta tem UID 0, ela é root; atacantes criam contas UID 0 escondidas.
sudo comando # roda como root (registra em log!)
su - julio # troca para o usuário julio
sudo -l # o que EU posso rodar como sudo (recon de privilégio)Verificar /etc/passwd em busca de contas suspeitas (UID 0 indevido, usuários que ninguém criou), checar quem está no grupo sudo/wheel e revisar /etc/sudoers são passos básicos de auditoria. Uma configuração sudoers frouxa (usuário pode rodar vi como root) vira escalada trivial. E /etc/shadow roubado + hashcat/John = senhas comprometidas se forem fracas.
1.6 Processos
Um processo é um programa em execução, com um PID e um dono.
ps aux # todos os processos (a=todos, u=por usuário, x=sem terminal)
top / htop # monitor em tempo real (CPU, memória)
kill 1234 / kill -9 1234 # encerra / força
pstree # árvore de processos (quem é pai de quem)
ls -l /proc/1234/exe # qual binário roda (mesmo se deletado!)
cat /proc/1234/cmdline # linha de comando completaProcessos são onde o malware vive. Sinais de alerta: nome estranho, rodando de /tmp, binário deletado do disco mas ainda em memória (/proc/PID/exe aponta para "(deleted)" — evasão clássica), ou CPU absurda (cryptominer). A relação pai-filho denuncia: um nginx que vira "pai" de um shell bash é altamente suspeito — provável exploração.
1.7 Serviços e systemd
Em servidores, programas ficam como serviços (daemons) que iniciam sozinhos. O gerenciador padrão é o systemd.
systemctl status ssh # estado de um serviço
systemctl enable/disable nginx # iniciar / não iniciar no boot
systemctl list-unit-files --state=enabled # o que sobe no bootsystemd é vetor de persistência: um atacante cria um serviço malicioso que sobe a cada boot. Investigação: liste serviços habilitados e desconfie de units recém-criadas, com nomes que imitam legítimos ("systemd-helper", "network-manager2") ou que executam scripts de /tmp. Timers do systemd (systemctl list-timers) são a versão moderna do cron e também servem para persistência.
1.8 SSH — acesso remoto seguro
SSH (Secure Shell) administra um servidor Linux remotamente, criptografado. Porta padrão: 22. Autenticação por chave (par pública/privada) é melhor que senha.
ssh julio@192.168.1.10 # conectar
scp arquivo julio@servidor:/tmp/ # copiar via SSH
ssh-keygen -t ed25519 # gera o par de chaves
ssh-copy-id julio@servidor # instala a chave pública no servidorHardening (em /etc/ssh/sshd_config): desabilitar login de root (PermitRootLogin no), só chave (PasswordAuthentication no), mudar a porta (reduz ruído de bots) e usar MFA.
SSH é um dos serviços mais escaneados e atacados da internet (brute force constante na 22). O arquivo ~/.ssh/authorized_keys é vetor de persistência favorito: o atacante adiciona a própria chave pública e volta quando quiser, sem senha. Sempre confira chaves não reconhecidas. Logs em /var/log/auth.log.
1.9 Logs — a memória do sistema
| Arquivo | O que registra |
|---|---|
| /var/log/auth.log (Debian) / secure (RHEL) | Autenticação: logins, sudo, SSH |
| /var/log/syslog / messages | Mensagens gerais do sistema |
| /var/log/kern.log | Kernel |
| /var/log/cron | Execução de tarefas agendadas |
| /var/log/apache2/, /var/log/nginx/ | Acessos web |
journalctl -u ssh # só do serviço ssh
journalctl --since "1 hour ago" # janela de tempo
journalctl -p err # só erros
grep "Failed password" /var/log/auth.log # brute force
grep "Accepted" /var/log/auth.log # logins bem-sucedidos
last / lastb # últimos logins / logins que falharamLogs são a base da detecção e da perícia. Mas logs locais podem ser apagados pelo atacante (por isso empresas mandam para um SIEM central). Sinal de alerta: um auth.log com "buraco" temporal sugere que alguém limpou. A regra: quem apaga rastro, deixa o rastro de ter apagado.
1.10 Cron — o agendador de tarefas
┌───── minuto (0-59)
│ ┌─── hora (0-23)
│ │ ┌─ dia do mês (1-31)
│ │ │ ┌ mês (1-12)
│ │ │ │ ┌ dia da semana (0-7)
* * * * * comando
0 2 * * * /backup.sh # todo dia às 02:00
*/5 * * * * /script.sh # a cada 5 minutos
crontab -l # listar tarefas do usuário atual
cat /etc/crontab # crontab do sistema
ls /etc/cron.d/ # tarefas adicionaisCron é o mecanismo de persistência mais clássico do Linux: o atacante agenda algo que a cada X minutos reconecta o backdoor ou baixa payload. Investigação obrigatória: crontab -l de cada usuário, /etc/crontab, /etc/cron.d/, /etc/cron.daily|hourly|weekly. Uma linha que roda algo de /tmp ou faz curl | bash para um IP estranho é red flag máxima. Um cron "a cada 5 minutos" é candidato a beaconing.
1.11 Bash scripting — o básico que você usa em cyber
#!/bin/bash
ALVO="192.168.1.1"
if ping -c 1 "$ALVO" &>/dev/null; then
echo "$ALVO está online"
else
echo "$ALVO está offline"
fi
# laço: varrer uma faixa
for ip in $(seq 1 10); do
ping -c 1 192.168.1.$ip &>/dev/null && echo "192.168.1.$ip vivo"
doneConceitos-chave: variáveis ($VAR), condicionais (if), laços (for/while), redirecionamento (>, >>, 2>) e &&/||.
Você vai ler scripts o tempo todo, de administração legítima e de malware. Saber Bash te deixa entender o que um script faz antes de rodar (crucial ao analisar um curl | bash suspeito) e automatizar tarefas de SOC. grep, awk, sed, cut, sort, uniq são seus aliados para triturar logs.
Parte 2 — Windows
O parque corporativo do mundo é majoritariamente Windows, e o coração dele é o Active Directory. Para cyber em ambiente empresarial, dominar AD não é opcional.
2.1 Active Directory (AD) — a espinha dorsal da empresa
Em vez de cada computador ter sua lista de usuários e senhas (caos!), existe um cartório central que sabe quem é cada funcionário, a que setor pertence, o que pode fazer e autentica todo mundo. Esse cartório é o AD, e roda num servidor chamado Domain Controller (DC).
Floresta (Forest) ← container maior
└── Domínio: empresa.local ← unidade de administração/segurança
├── Unidades Organizacionais (OU) ← "pastas" para organizar
├── Usuários / Grupos / ComputadoresGrupos poderosíssimos: Domain Admins, Enterprise Admins, Administrators.
Em pentest/red team, o objetivo quase sempre é "Domain Admin" — controle total do domínio. Todo o campo de AD security gira em torno de como o atacante enumera o AD, escala privilégios e chega ao DC, e como o defensor detecta e barra isso. Grupos privilegiados devem ter o mínimo de membros e ser monitorados de perto.
2.2 DNS no ambiente Windows
O AD depende fortemente de DNS. Os clientes acham o DC através de registros DNS especiais (registros SRV). Sem DNS, o AD desmorona. Por isso, num ambiente Windows, o DC costuma ser também o servidor DNS.
O DNS interno mapeia toda a rede (nomes de servidores, DCs, serviços), então é uma mina de reconhecimento para o atacante. Ataques específicos de AD (envenenamento via LLMNR/NBT-NS) exploram como o Windows resolve nomes quando o DNS falha: o atacante responde no lugar e captura credenciais.
2.3 GPO — Group Policy Objects
É como o admin aplica configurações e regras em massa, de um lugar só. "Todos os PCs terão papel de parede X, senha mínima de 12 caracteres, USB bloqueado." O admin escreve uma vez (a GPO), vincula a uma OU, e vale para todos ali. Exemplos: política de senha, bloqueio de conta, restrições de software, mapeamento de drives, scripts de logon.
GPO é faca de dois gumes. Bem usada, é hardening em escala. Mas se um atacante modifica uma GPO, ele empurra malware para toda a rede de uma vez — um dos ataques mais devastadores em AD. Auditar quem pode editar GPOs e monitorar mudanças é essencial.
2.4 Autenticação: Kerberos e NTLM
Kerberos (moderno). Analogia do parque: você chega na bilheteria (o DC), mostra sua identidade e recebe uma pulseira mestra (TGT — Ticket Granting Ticket). Para entrar em cada brinquedo (serviço), mostra a pulseira e recebe um ingresso específico (TGS). Você nunca reapresenta a senha, só os tickets. Fluxo: login → pede TGT ao KDC (no DC) → KDC entrega o TGT → apresenta o TGT e pede um TGS para o serviço → apresenta o TGS ao serviço → acesso.
NTLM (legado). Desafio-resposta usando o hash da senha. Mais fraco, mas ainda existe por compatibilidade. É onde mora o Pass-the-Hash: basta o hash, sem a senha em texto.
Pass-the-Hash: autenticar com o hash NTLM roubado. Pass-the-Ticket: roubar e reutilizar tickets Kerberos. Kerberoasting: pedir TGS de contas de serviço e quebrar offline (senhas fracas que nunca expiram). Golden Ticket: com a chave da conta krbtgt, forjar TGTs válidos para qualquer usuário — controle quase absoluto. Defesa: desabilitar NTLM onde possível, senhas fortes em contas de serviço, monitorar pedidos de ticket anômalos e proteger a krbtgt.
2.5 PowerShell — o terminal de poder do Windows
É o Bash do Windows, orientado a objetos. Ferramenta de administração — e de ataque — mais poderosa da plataforma. Cmdlets no formato Verbo-Substantivo:
Get-Process # lista processos (equivale a ps)
Get-Service # lista serviços
Get-NetTCPConnection # conexões de rede (equivale a netstat)
Get-LocalUser # usuários locais
Get-EventLog -LogName Security -Newest 20
Get-ScheduledTask # tarefas agendadas
# Consultas ao AD:
Get-ADUser -Filter * # todos os usuários do domínio
Get-ADGroupMember "Domain Admins" # quem é admin do domínioPowerShell é adorado por atacantes: nativo, poderoso e roda na memória (fileless, sem tocar o disco, difícil de detectar por AV tradicional). Frameworks ofensivos inteiros são escritos nele. A resposta defensiva é o logging avançado: Script Block Logging e Module Logging registram o que foi executado, mesmo ofuscado. Monitorar comandos suspeitos (download de payload, -EncodedCommand em Base64, Invoke-Expression) é uma das detecções mais valiosas em Windows.
2.6 Serviços no Windows
Get-Service # PowerShell
sc query # prompt clássico
sc qc nome_do_servico # config de um serviço (qual binário roda)Serviços são vetor de persistência e escalada (como systemd no Linux). Falhas clássicas: unquoted service path (caminho sem aspas, permite injetar um executável no meio do caminho) e weak service permissions (usuário comum modifica o binário que roda como SYSTEM). Investigação: serviços recém-criados, com nomes que imitam legítimos ou apontando para binários em pastas suspeitas.
2.7 Registro do Windows (Registry)
Banco de dados central de configuração do Windows, organizado em "colmeias" (hives) e chaves.
| Hive | Abrev. | Conteúdo |
|---|---|---|
| HKEY_LOCAL_MACHINE | HKLM | Configurações do sistema (toda a máquina) |
| HKEY_CURRENT_USER | HKCU | Configurações do usuário logado |
| HKEY_CLASSES_ROOT | HKCR | Associações de arquivo |
| HKEY_USERS | HKU | Todos os perfis de usuário |
Acessar: regedit (gráfico) ou reg query.
O Registro é o paraíso da persistência no Windows. As chaves de execução automática ("Run keys") fazem programas iniciarem no logon:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunMalware adiciona uma entrada ali para renascer a cada login. Ferramentas como Autoruns (Sysinternals) listam tudo que inicia automaticamente — um dos primeiros passos ao caçar persistência.
2.8 Event Viewer — os logs do Windows
Logs mais importantes: Security (autenticação, logons, privilégios — o mais importante), System (serviços, drivers) e Application. Cada evento tem um Event ID:
| Event ID | Log | Significado |
|---|---|---|
| 4624 | Security | Logon bem-sucedido |
| 4625 | Security | Logon falhou (brute force em massa) |
| 4634 / 4647 | Security | Logoff |
| 4672 | Security | Logon com privilégios especiais (admin) |
| 4688 | Security | Novo processo criado |
| 4720 | Security | Conta de usuário criada |
| 4732 / 4728 | Security | Usuário adicionado a grupo privilegiado |
| 7045 | System | Novo serviço instalado (persistência!) |
| 1102 | Security | Log de auditoria foi limpo |
Get-WinEvent -LogName Security -MaxEvents 50
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625} # só falhasDominar Event IDs transforma um monte de logs numa história. Muitos 4625 seguidos de um 4624 = brute force que teve sucesso. Um 4720 fora do processo normal = atacante criando persistência. Um 1102 = alguém apagando rastros. O tipo de logon ("Logon Type") também importa: tipo 3 (rede), 10 (RDP) — revelam como alguém entrou.
Parte 3 — Investigação (onde os dois mundos se encontram)
Dado um sistema (Linux ou Windows) possivelmente comprometido, o que você olha? A lógica é a mesma; muda a ferramenta.
3.1 Investigar processos suspeitos
O que procurar: processo com nome estranho ou que imita legítimo (svch0st.exe, scvhost.exe), rodando de local incomum (/tmp, C:\Users\Public, %TEMP%), relação pai-filho anômala (Word abrindo PowerShell; nginx abrindo bash), binário deletado ainda em execução, consumo de CPU/rede anormal.
# LINUX
ps auxf # árvore de processos
ls -l /proc/<PID>/exe # binário real (detecta "(deleted)")
lsof -p <PID> # arquivos e conexões abertos
# WINDOWS
Get-Process | Sort-Object CPU -Descending
Get-CimInstance Win32_Process | Select ProcessId, ParentProcessId, CommandLine
# Ou Process Explorer (Sysinternals)3.2 Investigar conexões de rede
O que procurar: conexões de saída para IPs desconhecidos, portas incomuns escutando, e qual processo é dono de cada conexão.
# LINUX
ss -tulpn # portas em escuta + processo
ss -tanp # todas as conexões TCP + processo
lsof -i # arquivos de rede abertos
# WINDOWS
Get-NetTCPConnection -State Established
netstat -anob # conexões + processo (precisa admin)Correlacione: "esse processo estranho tem uma conexão estabelecida com um IP na Rússia na porta 4444" → processo suspeito + conexão suspeita = provável C2.
3.3 Investigar tarefas agendadas
# LINUX
crontab -l ; cat /etc/crontab ; ls -la /etc/cron.*
systemctl list-timers # timers do systemd
# WINDOWS
Get-ScheduledTask | Where-Object {$_.State -eq "Ready"}
Get-ScheduledTask | Get-ScheduledTaskInfo # última/próxima execução3.4 Caçar mecanismos de persistência
Persistência = como o atacante garante que volta mesmo após reboot. O checklist mental:
No Linux: cron (de cada usuário, /etc/cron*), timers do systemd, serviços novos/suspeitos, chaves em ~/.ssh/authorized_keys, arquivos de perfil (~/.bashrc, ~/.profile, /etc/profile) com comandos injetados, binários SUID novos, contas UID 0 indevidas, módulos de kernel suspeitos (rootkits).
No Windows: Run keys no Registro, tarefas agendadas, serviços recém-criados (Event 7045), pasta Startup (shell:startup), WMI event subscriptions, contas novas/adicionadas a grupos admin (Event 4720/4732), e Autoruns para varrer tudo de uma vez.
O atacante precisa executar código (processos), manter acesso (persistência), falar com o C2 (conexões) e não ser visto (logs). Toda investigação é procurar as pegadas dessas necessidades: onde ele está rodando, como volta após reboot, como fala com o C2 e o que tentou apagar.
Linux: /etc (config/credenciais), /var/log (o que aconteceu), /tmp (onde malware se esconde). Permissões rwx, octal (7=rwx), SUID = escalada. /etc/passwd (usuários), /etc/shadow (hashes), UID 0 = root. Processos: ps aux, /proc/PID, pai-filho anômalo = suspeito. Persistência: cron, systemd, authorized_keys, .bashrc. Logs: auth.log, journalctl.
Windows: AD = cartório central; DC = alvo supremo; Domain Admins = objetivo do atacante. Autenticação: Kerberos (TGT/TGS), NTLM (Pass-the-Hash). PowerShell = poder total (e fileless); habilitar Script Block Logging. Registro: Run keys = persistência clássica. Event Viewer: 4625 (falha), 4624 (sucesso), 4720 (conta criada), 7045 (serviço novo), 1102 (log limpo).
Investigação (ambos): processos → conexões → tarefas agendadas → persistência → logs adulterados. Conheça o normal para reconhecer o anormal.
Suba duas VMs: um Linux (Ubuntu/Debian) e um Windows (Server com AD, se conseguir). No Linux, crie um cron "malicioso" inofensivo (um echo a cada minuto) e depois encontre-o só investigando, como se não soubesse que existe. No Windows, adicione uma entrada numa Run key e localize-a com Autoruns. Fazer o papel de atacante e depois de defensor no mesmo laboratório é o jeito mais rápido de fixar isto.