Blue Team, Red Team e Purple Team: entenda as diferenças e descubra qual carreira seguir

Segunda-feira, 7h40. Numa empresa fictícia de logística, que vamos chamar de Transvale, o painel de monitoramento mostra algo fora do padrão: durante a madrugada, um servidor Linux que guarda arquivos de faturamento registrou dezenas de tentativas de login por SSH que falharam. Os nomes de usuário variam: admin, backup, financeiro, teste.

Ninguém sabe ainda se aquilo é um ataque, um script de backup com a senha antiga ou um colaborador que esqueceu a própria senha. O que se sabe é que o servidor registrou as falhas e que alguém precisa olhar para elas.

Agora imagine três pessoas olhando para o mesmo episódio, cada uma com uma pergunta diferente:

• Quem trabalha com Red Team pergunta: se um adversário tentasse isso de propósito, o que ele conseguiria? Com autorização formal e regras combinadas, essa pessoa reproduz um comportamento parecido, de forma controlada, contra uma conta de teste, para avaliar a exposição real do servidor.
• Quem trabalha com Blue Team pergunta: o que aconteceu de fato, e o que fazemos agora? Ela abre os registros, separa as falhas por conta, horário e origem, verifica se alguma tentativa teve sucesso e decide se o caso é um incidente.
• Quem conduz um exercício de Purple Team pergunta: quando o comportamento acontece, a empresa enxerga? E o alerta dispara? Essa pessoa coloca as duas visões lado a lado, compara o que foi executado com o que foi detectado e transforma as diferenças em melhorias.

Repare que ninguém aqui afirmou que o servidor foi invadido. Tentativas de login malsucedidas são um sinal que merece investigação, não a prova de um comprometimento. Saber separar uma coisa da outra é uma das primeiras habilidades de quem trabalha com segurança.

Vamos usar essa história como fio condutor. No fim do artigo, você vai reproduzi-la em miniatura no seu próprio laboratório e passar pelas três perspectivas.

Se você chegou agora, este é o segundo artigo da série Por Dentro da Cibersegurança. O primeiro, Como começar na cibersegurança do zero, apresenta as carreiras da área e monta a máquina virtual Ubuntu que vamos reaproveitar no laboratório de hoje.

O que é Blue Team? #

Blue Team é o conjunto de pessoas e práticas responsáveis por defender o ambiente: prevenir o que for possível, perceber o que escapou e responder quando algo acontece. Na história da Transvale, é quem recebe o alerta das falhas de login e precisa decidir o que ele significa.

A defesa se divide em várias atividades, que em empresas maiores viram funções separadas:

• Monitoramento e detecção: acompanhar os eventos do ambiente e os alertas gerados pelas ferramentas. É o trabalho central de um SOC (Security Operations Center).
• Investigação de alertas (triagem): para cada alerta, responder o que aconteceu, onde, quando, com qual conta e se é verdadeiro ou falso positivo.
• Resposta a incidentes: quando o alerta se confirma, conter o problema (bloquear uma conta, isolar uma máquina), eliminar a causa e recuperar o ambiente.
• Threat hunting: procurar sinais de atividade maliciosa que não geraram alerta, a partir de hipóteses. Por exemplo: "se alguém estivesse testando senhas devagar, para não disparar o limite, o que veríamos nos logs?".
• Engenharia de detecção: escrever, testar e manter as regras que geram os alertas, reduzindo falsos positivos sem perder os casos reais.
• Proteção de endpoints, redes e identidades: configurar e manter as defesas em computadores e servidores, no tráfego de rede e nas contas de usuário (autenticação forte, privilégios mínimos, revisão de acessos).

Ferramentas do Blue Team #

Ninguém precisa dominar todas antes do primeiro emprego. Cada empresa usa uma combinação diferente, e o que se transfere de uma para outra é o raciocínio: saber o que procurar num log, numa conexão de rede ou num processo.

Um turno real (e realista) de SOC #

Um analista de nível 1 começa o turno lendo a passagem de bastão do colega anterior: casos em aberto e o que ficou pendente. Depois, abre a fila de alertas.

O primeiro é "múltiplas falhas de autenticação" num servidor Linux, como o da Transvale. O roteiro da investigação é quase sempre o mesmo:

1. Quem? Quais contas aparecem nas falhas? Elas existem? São contas de pessoas ou de serviço?
2. De onde? Qual o endereço de origem? É interno, de VPN ou da internet? Já apareceu antes?
3. Quando? As falhas estão concentradas em poucos minutos ou espalhadas pela madrugada?
4. Deu certo? Existe algum login bem-sucedido da mesma origem depois das falhas? Essa é a pergunta que muda a gravidade do caso.
5. Faz sentido para o negócio? Há uma janela de manutenção, um script novo ou um chamado de senha bloqueada que explique o padrão?

Se a origem é um servidor de backup interno usando uma senha que expirou, o alerta é encerrado como falso positivo, com a justificativa registrada, e o time responsável é avisado. Se a origem é um endereço externo testando dezenas de nomes de usuário, e um deles teve sucesso, o caso é escalado para o nível 2 e para a resposta a incidentes.

Nos dois cenários, o entregável é o mesmo: um registro claro do que foi visto, do que foi concluído e por quê. Boa parte do trabalho de Blue Team é escrever bem.

O que é Red Team? #

Red Team é a prática de simular adversários reais, com autorização, para descobrir como a organização se sai diante de um ataque. A pergunta não é só "existem falhas?", mas "um adversário com este objetivo conseguiria alcançá-lo, e a defesa perceberia?".

Por isso um exercício de Red Team costuma ter um objetivo, combinado antes com a liderança: chegar a um servidor de faturamento, acessar a conta de um executivo, ler um conjunto específico de dados. O time avalia o caminho até lá, e a capacidade de detecção e resposta da empresa faz parte do que está sendo testado.

Pentest e Red Team não são a mesma coisa #

Essas diferenças são tendências do mercado, não regras: cada empresa e cada contrato definem o seu formato. Um ponto, porém, não muda.

O que um time ofensivo faz, na prática #

• Reconhecimento e avaliação de exposição: descobrir o que está visível para um atacante. Quais serviços estão acessíveis, quais versões rodam, que informações públicas ajudam um adversário. No caso da Transvale: o SSH do servidor de arquivos aceita conexões de onde? Aceita senha ou só chave?
• Emulação de técnicas de adversários: reproduzir técnicas documentadas de grupos reais, em vez de inventar ataques. É aqui que o MITRE ATT&CK entra, como veremos adiante.
• Teste de controles de defesa: verificar se o bloqueio de contas funciona, se a autenticação multifator está mesmo ativa, se o antivírus reage, se o SOC recebe o alerta.
• Relatório: o entregável de um time ofensivo é um documento. Uma descoberta que não é explicada com clareza, com evidências e recomendação, não ajuda a defesa.

Ferramentas do Red Team #

Ter essas ferramentas instaladas não faz de ninguém um profissional ofensivo. O que se usa depende do objetivo do exercício e do que o estudante já sabe. Quem roda um módulo do Metasploit sem entender redes, serviços e o sistema-alvo não consegue explicar o resultado, e explicar o resultado é o trabalho. Caldera e Atomic Red Team, por exemplo, fazem mais sentido depois que você já tiver um SIEM no laboratório para observar o que eles produzem.

O que é Purple Team? #

Purple Team é, sobretudo, uma abordagem: ofensiva e defesa trabalhando juntas, com a mesma lista de técnicas na mesa, para medir e melhorar a capacidade de detecção. Em algumas empresas existe uma equipe com esse nome; em muitas outras, "purple" é o nome do exercício, e quem participa são as mesmas pessoas do Red e do Blue Team.

A diferença para um exercício de Red Team tradicional é a transparência. Em vez de o time ofensivo trabalhar em segredo e entregar um relatório semanas depois, os dois lados combinam a técnica, executam juntos, olham os resultados na hora e ajustam.

O ciclo de um exercício de Purple Team #

1. Definir a técnica a ser avaliada. Por exemplo: tentativas de adivinhar senhas por SSH.
2. Planejar uma simulação autorizada. Em qual máquina, com qual conta, em qual horário, quantas tentativas, quem acompanha.
3. Executar a atividade. O lado ofensivo reproduz o comportamento e anota exatamente o que fez e quando.
4. Coletar evidências. O lado defensivo procura os registros gerados: logs, alertas, tráfego.
5. Verificar visibilidade e detecção. São duas perguntas diferentes: o evento foi registrado? E algum alerta foi gerado?
6. Identificar lacunas. O log não existia? Existia, mas não chegava ao SIEM? Chegava, mas nenhuma regra olhava para ele?
7. Melhorar os controles. Ativar um log, ajustar uma regra, mudar uma configuração.
8. Repetir o exercício. Só a repetição mostra se a melhoria funcionou.

MITRE ATT&CK: a linguagem comum #

Para que ofensiva e defesa conversem, as duas precisam chamar a mesma coisa pelo mesmo nome. O MITRE ATT&CK é uma base de conhecimento pública e gratuita que cataloga táticas e técnicas usadas por adversários reais, observadas em incidentes e relatórios públicos.

• Tática é o objetivo do adversário naquele momento: obter acesso inicial, obter credenciais, mover-se lateralmente.
• Técnica é como ele tenta alcançar esse objetivo: por exemplo, Brute Force (T1110).
• Subtécnica é uma variação mais específica: Password Guessing (T1110.001), Password Spraying (T1110.003).

Mapear o que você testa e o que você detecta nesse catálogo responde perguntas que, sem ele, ficam vagas: "das técnicas que os grupos que atacam o nosso setor usam, quantas a gente enxerga?". No laboratório, você vai fazer esse mapeamento para um caso concreto.

Comparação entre as áreas #

Como escolher sua carreira? #

"Blue é para quem gosta de defender, Red é para quem gosta de atacar" é uma simplificação que mais confunde do que ajuda. Quem defende bem precisa entender ataques a fundo, e quem testa bem passa boa parte do tempo pensando em como a defesa vai enxergar (ou não) o que ele faz. Algumas perguntas ajudam mais:

• Que tipo de problema prende sua atenção? Se você gosta de partir de um sintoma (um log estranho, um alerta) e reconstruir o que aconteceu, a investigação do Blue Team tende a ser atraente. Se você gosta de partir de um sistema e descobrir de que formas ele pode se comportar diferente do previsto, o trabalho ofensivo tende a agradar.
• Que ritmo você prefere? Operações de defesa trabalham com filas, prazos de resposta e, em muitas empresas, plantões ou escalas. Trabalhos ofensivos costumam ser organizados em projetos com início, meio e fim, e uma parte grande do tempo vai para o relatório.
• Você gosta de escrever? Os dois lados escrevem muito. O Blue Team documenta investigações e incidentes; o Red Team escreve relatórios técnicos e executivos. Quem não gosta de escrever sofre nos dois.
• Você gosta de construir? Engenharia de detecção e Purple Team atraem quem gosta de transformar conhecimento sobre ataques em regras, automações e métricas.

Na prática, muitos profissionais começam pelos mesmos fundamentos (redes, sistemas operacionais, logs e conceitos de segurança) e só depois se especializam. Muitos começam pelo SOC, porque é onde costuma haver mais vagas de entrada, e migram para outras áreas com a experiência. Outros começam em infraestrutura, desenvolvimento ou suporte e trazem essa bagagem. Não existe uma rota obrigatória, e mudar de lado mais tarde é comum.

O laboratório a seguir serve também como teste: repare em qual das três perspectivas você se diverte mais.

LAB 02 — Gerando e investigando eventos de autenticação no Linux #

Neste laboratório, você vai produzir de propósito um pequeno número de falhas de login SSH na sua própria máquina virtual, encontrar essas falhas nos logs, mapear o que viu no MITRE ATT&CK e documentar tudo como faria num exercício de Purple Team.

Ambiente e requisitos #

Use a VM cyberlab-ubuntu que você criou no LAB 01, com o adaptador de rede em NAT. Os comandos foram escritos para o Ubuntu 26.04 LTS e funcionam igual no Desktop e no Server.

Antes de começar, crie um snapshot da VM (menu Máquina do VirtualBox). Se algo der errado, você volta a este ponto em segundos.

Passo a passo #

1. 01

   Preparação do ambiente #

   Abra o terminal da VM. Primeiro, confirme a distribuição e a versão:

   bash

   cat /etc/os-release

   Procure as linhas PRETTY_NAME e VERSION_ID. Anote os valores: eles vão para o relatório, porque o comportamento dos logs muda entre versões.

   Agora verifique se o servidor SSH já está instalado. O cliente (ssh) vem no Ubuntu; o servidor (openssh-server) nem sempre:

   bash

   dpkg -l openssh-server

   Se a última linha começar com ii, ele está instalado. Se aparecer uma mensagem dizendo que nenhum pacote foi encontrado, instale:

   bash

   sudo apt update
   sudo apt install openssh-server

   Verifique o estado do serviço:

   bash

   systemctl status ssh.socket ssh.service --no-pager

   Nas versões recentes do Ubuntu, o SSH usa ativação por socket: o systemd escuta a porta 22 (ssh.socket ativo) e só inicia o serviço ssh.service quando chega a primeira conexão. Por isso, é normal ver o ssh.socket como active (listening) e o ssh.service como inactive antes do primeiro teste. Se os dois estiverem inativos, ative:

   bash

   sudo systemctl enable --now ssh.socket

   Descubra em qual porta e endereço o serviço escuta:

   bash

   sudo ss -tlnp | grep ':22'

   Saída ilustrativa:

   texto

   LISTEN 0  4096   0.0.0.0:22   0.0.0.0:*   users:(("systemd",pid=1,fd=104))
   LISTEN 0  4096      [::]:22      [::]:*   users:(("systemd",pid=1,fd=105))

   Você aprendeu no LAB 01 que 0.0.0.0 significa "aceito conexões de qualquer lugar que me alcance". O processo aparece como systemd por causa da ativação por socket; depois da primeira conexão, sshd também pode aparecer.

   Garanta que o SSH não esteja exposto. Quem alcança a VM? Com o adaptador em NAT e sem regras de redirecionamento de portas, ninguém de fora: nem a sua rede de casa, nem a internet. Confira no VirtualBox, em Configurações > Rede > Adaptador 1: o modo deve ser NAT e a lista de Redirecionamento de Portas deve estar vazia.

   Como camada extra, você pode ativar o firewall do Ubuntu, que por padrão bloqueia conexões de entrada e continua permitindo o tráfego local (127.0.0.1):

   bash

   sudo ufw enable
   sudo ufw status verbose

   Procure Default: deny (incoming) na saída. Você está acrescentando uma proteção, não removendo.

   Por fim, crie a conta exclusiva do laboratório:

   bash

   sudo adduser lab-alvo

   O comando pede uma senha e alguns dados opcionais (pode deixar em branco com Enter). Escolha uma senha forte e que você não usa em lugar nenhum: ela só existe para este exercício. Não adicione essa conta ao grupo sudo.

   Resultado esperado

   Você anotou a versão do Ubuntu, o openssh-server está instalado, a porta 22 aparece no ss e a conta lab-alvo existe (confira com id lab-alvo). A VM continua em NAT, sem redirecionamento de portas.

   Problemas comuns

   systemctl status diz que a unidade ssh.socket não existe: sua versão ou distribuição não usa ativação por socket. Use sudo systemctl enable --now ssh e siga normalmente. Outras situações estão em Problemas comuns e como resolver.

2. 02

   Perspectiva Red Team: gerar a atividade controlada #

   Agora você faz o papel de quem reproduz o comportamento. Num exercício real, tudo o que a ofensiva faz é anotado com horário, porque é isso que permite à defesa comparar depois. Comece registrando a hora de início:

   bash

   date "+%Y-%m-%d %H:%M:%S %Z"

   Tentativa A: senha errada para uma conta que existe. Conecte à própria VM como lab-alvo:

   bash

   ssh lab-alvo@127.0.0.1

   Na primeira conexão, o cliente mostra a impressão digital da chave do servidor e pergunta se você confia nela. Digite yes: você está conectando na sua própria máquina.

   Quando ele pedir a senha, digite uma senha errada. Repita até o cliente desistir. Por padrão, ele oferece três tentativas por conexão e termina com uma mensagem como Permission denied (publickey,password).

   Tentativa B: uma conta que não existe. Faça uma única tentativa com um usuário inventado e, quando a senha for pedida, digite qualquer coisa errada uma vez e depois pressione Ctrl + C:

   bash

   ssh teste-inexistente@127.0.0.1

   Repare que o servidor pede a senha mesmo para um usuário que não existe. É proposital: se ele respondesse "esse usuário não existe", ajudaria quem está tentando descobrir nomes válidos.

   Tentativa C: um login correto. Agora entre com a senha certa da lab-alvo e saia em seguida:

   bash

   ssh lab-alvo@127.0.0.1
   exit

   Esse sucesso é importante para a investigação: na vida real, a pergunta mais séria depois de várias falhas é se alguma tentativa deu certo.

   Registre a hora de término com o mesmo comando date e preencha a sua ficha:

   Campo	O que anotar
   Horário de início e fim	A saída dos dois date
   Contas usadas	lab-alvo (existe) e teste-inexistente (não existe)
   Endereço de origem	127.0.0.1
   Quantidade de tentativas	Quantas senhas erradas você digitou em cada conta, e o login correto
   Comportamento observado	As mensagens que o cliente mostrou em cada caso

   Resultado esperado

   Você tem uma ficha com horário, contas, origem, número exato de tentativas e o que o cliente respondeu. No total, foram poucas tentativas, todas manuais, além de um login correto.

   Problemas comuns

   Se o cliente responder Permission denied (publickey) sem pedir senha, a autenticação por senha está desativada no seu servidor (é comum em imagens de nuvem). Não mude a configuração: siga a alternativa descrita em Problemas comuns e como resolver.

3. 03

   Perspectiva Blue Team: encontrar e interpretar as evidências #

   Troque de papel. Agora você recebeu um aviso: "houve falhas de login no servidor cyberlab-ubuntu". O que os registros mostram?

   Onde estão os logs. No Ubuntu atual, o registro principal é o journal do systemd, consultado com journalctl. O arquivo clássico /var/log/auth.log só existe se o serviço rsyslog estiver instalado e ativo, o que varia conforme a versão e o tipo de instalação. Descubra como está a sua VM:

   bash

   systemctl is-active rsyslog
   ls -l /var/log/auth.log

   Se o rsyslog estiver ativo e o arquivo existir, você tem as duas fontes. Se não, use só o journal: todos os comandos abaixo funcionam com ele.

   Os eventos do SSH no seu intervalo de teste. Use os horários da sua ficha (os valores abaixo são exemplos; troque pelos seus):

   bash

   sudo journalctl -u ssh --since "2026-10-27 14:00" --until "2026-10-27 14:15" --no-pager

   O -u ssh filtra pela unidade do serviço SSH; --since e --until limitam o período. Se não lembrar os horários, use --since "30 min ago".

   Saída ilustrativa (os números de processo, portas e horários na sua VM serão outros):

   texto

   out 27 14:02:58 cyberlab-ubuntu sshd-session[2345]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1  user=lab-alvo
   out 27 14:03:01 cyberlab-ubuntu sshd-session[2345]: Failed password for lab-alvo from 127.0.0.1 port 51514 ssh2
   out 27 14:03:09 cyberlab-ubuntu sshd-session[2345]: Failed password for lab-alvo from 127.0.0.1 port 51514 ssh2
   out 27 14:03:15 cyberlab-ubuntu sshd-session[2345]: Failed password for lab-alvo from 127.0.0.1 port 51514 ssh2
   out 27 14:03:15 cyberlab-ubuntu sshd-session[2345]: Connection closed by authenticating user lab-alvo 127.0.0.1 port 51514 [preauth]
   out 27 14:06:40 cyberlab-ubuntu sshd-session[2401]: Invalid user teste-inexistente from 127.0.0.1 port 51600
   out 27 14:06:44 cyberlab-ubuntu sshd-session[2401]: Failed password for invalid user teste-inexistente from 127.0.0.1 port 51600 ssh2
   out 27 14:08:02 cyberlab-ubuntu sshd-session[2420]: Accepted password for lab-alvo from 127.0.0.1 port 51700 ssh2

   Desde o OpenSSH 9.8, as mensagens de cada conexão aparecem com o nome sshd-session; em versões mais antigas, aparecem como sshd. O filtro -u ssh pega as duas formas.

   Como ler uma linha. Pegue Failed password for lab-alvo from 127.0.0.1 port 51514 ssh2:

   Trecho	Significado
   out 27 14:03:01	Quando aconteceu, no fuso horário da VM
   cyberlab-ubuntu	Em qual máquina
   sshd-session[2345]	Qual programa registrou e o número do processo. Linhas com o mesmo número pertencem à mesma conexão
   Failed password	O resultado: senha recusada
   for lab-alvo	A conta. Com invalid user antes do nome, a conta não existe
   from 127.0.0.1	A origem da conexão
   port 51514	A porta de origem, escolhida pelo cliente. Muda a cada conexão

   Filtrar só o que interessa. Falhas, usuários inexistentes e sucessos:

   bash

   sudo journalctl -u ssh --since "30 min ago" --no-pager | grep -E "Failed password|Invalid user|Accepted"

   Quantas falhas de senha houve:

   bash

   sudo journalctl -u ssh --since "30 min ago" --no-pager | grep -c "Failed password"

   Falhas agrupadas por conta e origem:

   bash

   sudo journalctl -u ssh --since "30 min ago" --no-pager \
     | grep "Failed password" \
     | grep -oE "for (invalid user )?[^ ]+ from [^ ]+" \
     | sort | uniq -c

   Saída ilustrativa:

   texto

         3 for lab-alvo from 127.0.0.1
         1 for invalid user teste-inexistente from 127.0.0.1

   O grep -oE recorta só o trecho "conta + origem" de cada linha; o sort | uniq -c conta quantas vezes cada combinação aparece. É uma versão manual do que um SIEM faz automaticamente.

   Se você tiver o /var/log/auth.log, encontre os mesmos eventos lá:

   bash

   sudo grep "Failed password" /var/log/auth.log | tail -n 10

   Também vale olhar a linha do PAM (pam_unix(sshd:auth): authentication failure), o módulo do Linux que verifica a senha. Ela registra a mesma falha por outro componente, e pode aparecer num formato diferente dependendo da configuração. Em investigações, ter duas fontes que confirmam o mesmo fato é um bom sinal.

   Compare com a ficha da etapa 2. Esta é a parte mais importante. Para cada tentativa que você fez, existe um registro? Os horários batem? A quantidade bate? O login correto aparece como Accepted password? Se algo não bater, anote: uma diferença entre o que foi feito e o que foi registrado é exatamente o tipo de achado que um exercício de Purple Team procura.

   Resultado esperado

   Você encontrou no journal as falhas da lab-alvo, a tentativa com o usuário inexistente e o login correto, com horário, conta e origem, e comparou cada um com a sua ficha.

   Problemas comuns

   journalctl -u ssh não mostra nada, ou você recebe um aviso de permissão: veja Problemas comuns e como resolver.

4. 04

   Perspectiva Purple Team: da evidência à oportunidade de detecção #

   Agora junte os dois lados. Abra a página da técnica T1110.001 — Brute Force: Password Guessing no MITRE ATT&CK.

   A técnica descreve adversários tentando adivinhar senhas de contas, sem conhecê-las previamente, por meio de várias tentativas. Seja honesto com o que o seu laboratório mostra: quatro senhas erradas digitadas à mão não demonstram uma campanha de força bruta. O que elas produzem é o mesmo tipo de telemetria que uma campanha real produziria, em escala muito menor. É essa telemetria que você está estudando.

   Vale conhecer as técnicas vizinhas, porque a investigação pode levar a elas:

   • T1110.003 — Password Spraying: poucas senhas comuns testadas contra muitas contas. Nos logs, aparece como muitas contas diferentes vindas da mesma origem, com poucas falhas em cada uma.
   • T1021.004 — Remote Services: SSH: o uso do SSH para acessar máquinas remotamente, que é o que acontece depois de um login bem-sucedido.
   • T1078 — Valid Accounts: o uso de credenciais legítimas. Um login correto depois de várias falhas da mesma origem pode indicar que uma senha foi adivinhada.

   Com isso, o time pode construir uma hipótese de detecção:

   Se uma mesma origem acumular várias falhas de autenticação SSH em poucos minutos, contra uma ou mais contas, isso pode indicar tentativa de adivinhação de senhas (T1110.001) e merece triagem. Se a mesma origem tiver um login bem-sucedido logo depois, a prioridade aumenta.

   Os campos necessários. Para que uma regra funcione, cada evento precisa trazer:

   Campo	De onde vem, no seu log	Por que é necessário
   Horário	Início da linha	Contar eventos dentro de uma janela
   Máquina	cyberlab-ubuntu	Saber qual servidor está sendo alvo
   Resultado	Failed password, Accepted password	Separar falha de sucesso
   Conta	Depois de for	Agrupar por conta e identificar contas inexistentes
   Conta existe?	invalid user	Muitas contas inexistentes sugerem tentativa de adivinhar nomes
   Origem	Depois de from	Agrupar por quem está tentando

   A janela temporal e o limiar. Uma regra desse tipo diz algo como "N falhas da mesma origem em X minutos". Não existe número universal. Uma forma de começar é observar o comportamento normal do ambiente e escolher um valor acima dele. Para referência, o conjunto de regras padrão do Wazuh traz uma regra para o sshd (a 5763) que considera 8 falhas da mesma origem em 120 segundos; confira na documentação da versão que você usar. Limiar baixo demais gera alerta para quem simplesmente errou a senha; alto demais deixa passar quem tenta devagar de propósito.

   Possíveis falsos positivos. Antes de propor a regra, liste o que poderia dispará-la sem ser um ataque:

   • uma pessoa que esqueceu a senha ou está com o teclado na configuração errada;
   • um script de backup ou de monitoramento usando uma senha que expirou;
   • vários usuários legítimos saindo pelo mesmo endereço (uma VPN ou um NAT corporativo), somando falhas na mesma origem;
   • uma ferramenta de varredura de vulnerabilidades autorizada.

   Para cada um, pense em como diferenciá-lo: a origem é conhecida? A conta é de serviço? Existe um chamado aberto?

   A lacuna e a oportunidade de melhoria. No seu laboratório, a resposta para as perguntas do ciclo Purple é:

   • Visibilidade: sim. Os eventos foram registrados no journal, com todos os campos da tabela.
   • Detecção: não. Nenhum alerta foi gerado, porque o laboratório não tem um SIEM nem nenhuma regra olhando esses registros. Você só encontrou os eventos porque foi procurá-los.

   Registre isso como uma oportunidade de melhoria, não como um defeito: "os eventos necessários para detectar tentativas de adivinhação de senha por SSH existem, mas não há coleta centralizada nem regra de alerta. Recomendação: enviar os logs do journal para um SIEM e criar uma regra com janela e limiar definidos, validando-a com o mesmo exercício." É exatamente o caminho que esta série vai seguir nos próximos laboratórios.

   Resultado esperado

   Você tem uma hipótese de detecção escrita, a lista de campos, uma proposta de janela e limiar, quatro possíveis falsos positivos e a lacuna documentada: há visibilidade, mas não há detecção.

5. 05

   Documentação #

   Um exercício que não vira documento não ajuda ninguém, nem você daqui a três meses. Escreva um relatório curto com estas seções: objetivo, ambiente, data e horário, atividade executada, evidências coletadas, técnica MITRE relacionada, limitações, recomendações e conclusão.

   Modelo simplificado (os valores são exemplos; troque pelos seus):

   markdown

   # Relatório LAB 02: eventos de autenticação SSH no Linux
   
   **Data:** 27/10/2026, das 14h00 às 14h10 (horário de Brasília)
   **Autor:** Seu nome
   **Ambiente:** VirtualBox 7.2 · Ubuntu 26.04 LTS · OpenSSH Server · rede NAT
   
   ## Objetivo
   Gerar falhas de autenticação SSH controladas e verificar se o ambiente
   registra os dados necessários para detectar tentativas de adivinhação de senha.
   
   ## Atividade executada
   | Horário | Conta | Origem | Ação | Resultado |
   |---|---|---|---|---|
   | 14:03 | lab-alvo | 127.0.0.1 | 3 senhas erradas | Recusadas |
   | 14:06 | teste-inexistente | 127.0.0.1 | 1 senha errada | Recusada (usuário inexistente) |
   | 14:08 | lab-alvo | 127.0.0.1 | Senha correta | Aceita |
   
   ## Evidências
   - `journalctl -u ssh`: 4 linhas "Failed password" e 1 "Accepted password",
     com horário, conta e origem. Print em evidencias/01-journal-ssh.png
   - Contagem por conta e origem: evidencias/02-contagem.png
   - /var/log/auth.log: [presente / ausente nesta versão]
   
   ## Técnica MITRE ATT&CK
   T1110.001 (Brute Force: Password Guessing). A atividade gera a telemetria
   da técnica, mas não reproduz uma campanha real.
   
   ## Resultado da avaliação
   - Visibilidade: SIM. Todos os eventos foram registrados.
   - Detecção: NÃO. Não há SIEM nem regra de alerta neste ambiente.
   
   ## Limitações
   Poucas tentativas manuais, origem e destino na mesma máquina, sem coleta
   centralizada. Não avalia bloqueio de conta nem resposta a incidentes.
   
   ## Recomendações
   1. Centralizar os logs do journal num SIEM.
   2. Criar regra: N falhas da mesma origem em X minutos (proposta inicial: 5 em 5).
   3. Priorizar sucesso após falhas da mesma origem.
   4. Repetir este exercício para validar a regra.
   
   ## Conclusão
   O ambiente registra os eventos necessários, mas depende de busca manual.

   Evidências boas são verificáveis: prints com o comando e a saída inteiros, horários visíveis e nenhum dado pessoal.

   Resultado esperado

   Você tem um relatório com todas as seções, as evidências referenciadas e a conclusão de que há visibilidade sem detecção.

Limpeza #

Quando terminar e tiver salvo as evidências, desfaça o que não vai mais usar. Remova a conta do laboratório:

sudo deluser --remove-home lab-alvo

Se você instalou o servidor SSH só para este exercício e não vai usá-lo nos próximos, pare e desative:

sudo systemctl disable --now ssh.socket ssh.service

O firewall (ufw) pode continuar ativo: ele não atrapalha os próximos laboratórios e você vai aprender a configurá-lo melhor quando a VM ganhar vizinhas.

Problemas comuns e como resolver #

Checklist de aprendizado #

Desafios extras #

sudo journalctl -u ssh --since today -o short-iso --no-pager > eventos-ssh.txt

#!/usr/bin/env python3
"""Conta falhas de autenticação SSH por usuário, origem e janela de tempo.

Uso: python3 contar_falhas.py eventos-ssh.txt --janela 5 --limiar 5
"""
import argparse
import re
from collections import Counter
from datetime import datetime, timedelta

# Ex.: 2026-10-27T14:03:12-03:00 cyberlab sshd-session[2345]: Failed password for lab-alvo from 127.0.0.1 port 51514 ssh2
FALHA = re.compile(r"Failed password for (invalid user )?(?P<usuario>\S+) from (?P<origem>\S+) port")


def inicio_da_janela(momento, minutos):
    """Arredonda o horário para baixo, no começo da janela de N minutos."""
    resto = (momento.hour * 60 + momento.minute) % minutos
    return momento.replace(second=0, microsecond=0) - timedelta(minutes=resto)


def main():
    p = argparse.ArgumentParser()
    p.add_argument("arquivo", help="arquivo exportado do journalctl (formato short-iso)")
    p.add_argument("--janela", type=int, default=5, help="tamanho da janela em minutos")
    p.add_argument("--limiar", type=int, default=5, help="falhas na mesma janela para marcar como suspeito")
    args = p.parse_args()

    contagem = Counter()
    with open(args.arquivo, encoding="utf-8", errors="replace") as f:
        for linha in f:
            m = FALHA.search(linha)
            if not m:
                continue
            try:
                # os 19 primeiros caracteres são data e hora: 2026-10-27T14:03:12
                momento = datetime.strptime(linha[:19], "%Y-%m-%dT%H:%M:%S")
            except ValueError:
                continue  # linha fora do formato short-iso
            usuario = m["usuario"] + (" (inexistente)" if m.group(1) else "")
            contagem[(inicio_da_janela(momento, args.janela), usuario, m["origem"])] += 1

    if not contagem:
        print("Nenhuma linha 'Failed password' encontrada. Confira o arquivo e o formato (-o short-iso).")
        return

    print(f"{'Janela (início)':<17}  {'Usuário':<32} {'Origem':<16} {'Falhas':>6}")
    for (janela, usuario, origem), n in sorted(contagem.items()):
        alerta = "  <- acima do limiar" if n >= args.limiar else ""
        print(f"{janela:%Y-%m-%d %H:%M}  {usuario:<32} {origem:<16} {n:>6}{alerta}")
    print(f"\nTotal: {sum(contagem.values())} falhas. Janela de {args.janela} min, limiar de {args.limiar}.")


if __name__ == "__main__":
    main()

Certificações e trilhas de aprendizado #

Certificações organizam o estudo e ajudam a passar por filtros de currículo, mas nenhuma é obrigatória para começar e nenhuma substitui laboratório. As informações abaixo foram conferidas nas páginas oficiais em outubro de 2026. Preços variam e mudam com frequência; consulte sempre o site de cada certificadora.

Fundamentos (servem para qualquer caminho) #

Especialização em defesa (Blue Team) #

Especialização ofensiva (Red Team e pentest) #

Para depois, com experiência #

GIAC GCIH (Certified Incident Handler) cobre técnicas de ataque e tratamento de incidentes. É reconhecida e cara (o treinamento associado da SANS custa bem mais que o exame). Faz sentido quando você já trabalha com resposta a incidentes ou quando a empresa patrocina. Não é ponto de partida.

Uma ordem que faz sentido para iniciantes: fundamentos e laboratório primeiro; depois uma certificação de base (CC, Security+ ou CCNA Cybersecurity); só então uma especialização, escolhida a partir do que você gostou de fazer nos laboratórios. Gastar com uma certificação avançada antes de ter a base costuma resultar em decorar respostas sem conseguir aplicá-las.

Como o seu Home Lab vai evoluir #

O laboratório de hoje usou uma única VM conversando com ela mesma. A partir daqui, cada artigo acrescenta uma peça:

Essa é uma progressão sugerida. Os requisitos de hardware crescem a cada etapa, principalmente quando o SIEM entrar; confira os de cada laboratório antes de começar. A calculadora de hardware ajuda a descobrir até onde o seu computador vai.

A ideia da CS Academy é essa: aprender cibersegurança construindo e investigando o próprio ambiente, uma peça de cada vez. Para quem quiser ver o desenho completo de um laboratório que simula uma empresa, o Cyber Security Home Lab Pro ensina a montar, aula a aula, um ambiente com hipervisor Proxmox, firewall pfSense, Active Directory, o SIEM Wazuh, uma sandbox isolada e estações de ataque com alvos vulneráveis. É onde os três times deste artigo podem trabalhar no mesmo ambiente. Todo o software usado é gratuito, e a primeira aula é aberta.

Se ainda não for o momento, o Blueprint do Home Lab é um PDF gratuito com esse desenho: as zonas, um plano de redes de exemplo e o checklist de hardware.

Perguntas frequentes #

Preciso escolher entre Blue Team e Red Team logo no começo? #

Não. Os fundamentos são os mesmos: redes, sistemas operacionais, logs e conceitos de segurança. Faça laboratórios dos dois lados, como o deste artigo, e observe do que você gosta mais. A escolha fica mais fácil (e mais bem informada) depois de alguns meses de prática.

Purple Team é um cargo? #

Às vezes. Algumas empresas têm equipes ou vagas com esse nome, mas na maioria dos lugares Purple Team é uma forma de trabalhar: exercícios em que ofensiva e defesa colaboram para medir e melhorar a detecção. Os cargos mais próximos costumam ser engenheiro de detecção e especialista em emulação de adversários.

Qual dos três é mais acessível para quem está começando? #

As vagas de entrada mais comuns costumam estar na defesa, em SOCs e em empresas de serviços gerenciados de segurança. Entrar direto em ofensiva é possível, normalmente pelo pentest, mas exige uma base técnica mais larga. Purple Team quase sempre pede experiência prévia em pelo menos um dos lados.

Como praticar técnicas ofensivas sem cometer crime? #

Pratique só no seu próprio laboratório, em plataformas que autorizam expressamente os testes (ambientes de treino e CTFs) ou em programas de bug bounty, seguindo as regras de cada um. Fora disso, nenhum teste começa sem autorização por escrito do dono do sistema.

O laboratório deste artigo é um ataque de força bruta? #

Não. Você fez poucas tentativas manuais, contra uma conta criada para o exercício, na sua própria máquina. Isso gera o mesmo tipo de registro que uma tentativa de força bruta geraria, o que permite estudar a detecção com segurança. Uma campanha real envolve automação, volume e um alvo que não é seu.

Para fechar #

Volte à Transvale. As mesmas falhas de login renderam três aprendizados diferentes, e você acabou de passar pelos três:

• Como produzir uma atividade controlada: com autorização, limites claros, uma conta de teste e o registro exato do que foi feito.
• Como investigá-la: encontrar os eventos, ler cada campo, separar falha de sucesso e comparar o registro com o que realmente aconteceu.
• Como avaliar a detecção: perceber que registrar não é o mesmo que alertar, e transformar essa diferença numa recomendação concreta.

Nenhum dos três papéis funciona sozinho. A ofensiva sem a defesa produz relatórios que ninguém aplica; a defesa sem a ofensiva não sabe o que está deixando passar. É por isso que tanta gente na área circula entre os dois lados ao longo da carreira.

Guarde o relatório deste laboratório no seu portfólio, ao lado do LAB 01. Daqui a alguns artigos, quando você tiver um SIEM, vai repetir este exercício, e a linha "Detecção: NÃO" vai mudar.

No próximo artigo da série Por Dentro da Cibersegurança: "Como montar seu primeiro Home Lab de Cibersegurança: arquitetura, redes e virtualização". Vamos aprofundar a infraestrutura, colocar duas máquinas virtuais numa rede isolada e preparar o terreno para receber um SIEM. A origem das tentativas deixa de ser 127.0.0.1 e passa a ser outra máquina, como seria numa empresa.

• #carreira
• #blue team
• #red team
• #purple team
• #soc
• #mitre att&ck
• #ssh
• #journalctl
• #laboratório