A entrevista para analista pleno de cibersegurança com foco em pentest é significativamente mais técnica do que para posições júnior. O entrevistador espera que o candidato demonstre experiência prática — não apenas conhecimento teórico — e capacidade de raciocinar autonomamente diante de cenários novos. Respostas que apenas citam ferramentas sem explicar o raciocínio por trás do uso são consideradas superficiais nesse nível.

1. Descreva sua metodologia de pentest — do início ao relatório

A resposta esperada cobre as fases completas: Reconhecimento (OSINT passivo e ativo, enumeração de subdomínios, identificação de tecnologias), Scanning (Nmap, identificação de serviços e versões), Enumeração (detalhamento de superfície de ataque por serviço), Exploração (tentativa de exploração das vulnerabilidades identificadas, documentação de evidências), Pós-exploração (escalação de privilégios, movimentação lateral, acesso a dados sensíveis dentro do escopo), e Relatório (executivo para gestão, técnico para o time de remediação, com CVSS de cada achado e recomendações priorizadas).

A chave para uma resposta de nível pleno: mencionar que a metodologia é adaptada ao escopo e ao cliente — um pentest de aplicação web tem abordagem diferente de um pentest de infraestrutura interna.

2. Como você aborda o bypass de antivírus em um engagement?

Resposta de nível pleno cobre múltiplas técnicas e o raciocínio por trás de cada escolha: ofuscação de payload (encoding, encryption, packing), uso de living-off-the-land binaries (LOLBins — ferramentas nativas do Windows como certutil, bitsadmin, mshta), injeção de shellcode em processos legítimos (process injection), e uso de frameworks de C2 com perfis de comunicação que imitam tráfego legítimo.

Importante mencionar: o objetivo não é apenas bypassar — é entender quais técnicas o EDR do cliente detecta e quais não detecta, para que as recomendações de melhoria de detecção sejam precisas.

3. Explique como funciona um ataque de Pass-the-Hash

Pass-the-Hash (PtH) explora o protocolo NTLM do Windows: em vez de precisar da senha em texto claro, o atacante usa o hash NTLM da senha — capturado via Mimikatz ou equivalente após comprometer um sistema — para autenticar em outros sistemas que aceitam NTLM. A senha não precisa ser "quebrada" — o hash é a credencial.

Mitigações: desabilitar NTLM onde possível e forçar Kerberos, implementar Protected Users Security Group para contas privilegiadas (que não permitem autenticação NTLM), e usar contas de administrador local únicas por máquina (LAPS — Local Administrator Password Solution) para impedir que o hash de uma máquina comprometa outras.

4. O que é Kerberoasting e como detectar?

Kerberoasting explora o protocolo Kerberos do Active Directory: qualquer usuário autenticado pode solicitar um ticket de serviço (TGS) para qualquer conta de serviço com SPN registrado. Esse ticket é criptografado com o hash da senha da conta de serviço. O atacante solicita o ticket e tenta quebrá-lo offline — sem fazer ruído na rede além da solicitação inicial do ticket, que parece tráfego legítimo.

Detecção: monitorar Event ID 4769 no Active Directory — solicitações de TGS com tipo de criptografia RC4 (0x17) são suspeitas, pois contas legítimas modernas usam AES. Volume anormal de solicitações TGS de um único usuário é outro indicador.

5. Como você testa a segurança de uma API REST?

Abordagem estruturada: 1) Mapeamento de endpoints via documentação (Swagger/OpenAPI) e análise de tráfego com Burp Suite. 2) Teste de autenticação e autorização — cada endpoint exige autenticação? Usuário A pode acessar recursos do usuário B? (IDOR — Insecure Direct Object Reference). 3) Injeção — SQL, NoSQL, command injection nos parâmetros. 4) Exposição de dados — a API retorna mais dados do que o necessário? (Mass Assignment, Excessive Data Exposure). 5) Rate limiting — é possível fazer força bruta de credenciais ou enumeração de recursos sem ser bloqueado? 6) Segurança de tokens JWT — algoritmo fraco (none, HS256 com chave padrão), expiração adequada, validação de assinatura.

6. Descreva um achado complexo que você documentou e como o apresentou ao cliente

Esta pergunta avalia experiência real e capacidade de comunicação. A resposta deve incluir: qual era a vulnerabilidade e por que era complexa (encadeamento de vulnerabilidades, contexto específico do ambiente), como você reproduziu e documentou as evidências, qual o impacto de negócio real (não apenas o CVSS técnico), e como adaptou a apresentação para diferentes audiências — técnica para o time de TI, executiva para o board. Mencionar como acompanhou a remediação e fez o retest demonstra maturidade profissional além do pentest em si.

7. Como você lida com situações fora do escopo durante um engagement?

Durante um pentest, é comum encontrar vulnerabilidades em sistemas fora do escopo definido — um servidor de terceiros, uma aplicação não listada no contrato. A resposta correta: documentar o achado imediatamente, parar qualquer exploração adicional, notificar o ponto de contato do cliente sem demora, e aguardar instrução formal sobre como proceder. Continuar explorando fora do escopo, mesmo com boas intenções, cria responsabilidade legal e ética. O cliente decide se expande o escopo — não o pentester.

8. O que é um ataque de SQL Injection de segunda ordem?

SQL Injection de segunda ordem (também chamado de stored SQL Injection) ocorre quando um payload malicioso é armazenado no banco de dados em uma primeira requisição — sem causar efeito imediato porque é sanitizado na entrada — e depois recuperado e executado sem sanitização em uma segunda operação diferente. Mais difícil de detectar porque scanners automáticos frequentemente não correlacionam a entrada com a execução posterior. Exemplo: um nome de usuário como admin'-- pode ser armazenado com escape correto, mas quando recuperado por outra função que constrói uma query sem sanitizar, executa como SQL.

9. Como você mantém suas habilidades atualizadas?

Resposta de nível pleno vai além de "acompanho notícias". Menciona práticas concretas: estuda relatórios técnicos de grupos APT (Mandiant, CrowdStrike, CISA advisories), reproduz técnicas em laboratório próprio, participa de CTFs ou programas de bug bounty, lê pesquisas de segurança ofensiva (blogs como SpecterOps, posts do Project Zero), e acompanha repositórios de PoCs no GitHub para novas CVEs relevantes. Ter um homelab ativo onde testa técnicas novas é o diferencial que separa profissionais que evoluem dos que ficam estagnados.

10. Qual vulnerabilidade recente você achou mais interessante tecnicamente e por quê?

Esta pergunta não tem resposta certa — avalia curiosidade intelectual genuína e profundidade técnica. O que importa é a análise: por que a vulnerabilidade é interessante do ponto de vista técnico? Qual o mecanismo de exploração? O que ela revela sobre o design do sistema afetado? Como a mitigação funciona? Um candidato que responde com análise técnica própria — não apenas resumindo um artigo — demonstra que realmente estuda o campo, não apenas consome headlines. As certificações avançadas em pentest exigem exatamente esse nível de análise técnica.

Valide seu conhecimento e avance na carreira