Hacking ético

O que é hacking ético?

O hacking ético é uma metodologia de testes de segurança na qual especialistas autorizados copiam as táticas, técnicas e procedimentos de atacantes reais contra um alvo definido. O propósito é ofensivo, a intenção é defensiva. O que o separa de uma invasão criminosa não é a técnica, e sim o consentimento, o escopo e a prestação de contas.

Ele se apoia em três condições. O proprietário aprova um alvo de avaliação, que pode ser parte ou a totalidade da superfície de ataque. As duas partes combinam o que os avaliadores podem e não podem fazer. E cada achado volta ao proprietário com a evidência necessária para corrigi-lo.

Hackers maliciosos e hackers éticos se apoiam nas mesmas aptidões: curiosidade, paciência e o hábito de perguntar o que acontece se. O texto da Fluid Attacks sobre a ética do hacking sustenta que a diferença aparece nos efeitos da prática de cada grupo, não na habilidade.

O que o hacking ético não é

Rodar um scanner não é hacking ético. A varredura de vulnerabilidades compara padrões conhecidos e reporta candidatos; um hacker ético decide o que atacar, tenta e mostra a consequência.

Também não é um ataque sem limites. Um teste sem alvo de avaliação escrito, sem regras combinadas e sem um caminho de escalonamento não é hacking ético de escopo mais amplo. É um incidente à espera de uma explicação.

Por que o hacking ético importa

Os testes automatizados encontram vulnerabilidades que se parecem com algo que já viram antes. O hacking ético encontra as que dependem do contexto: para que serve a aplicação, quem pode fazer o quê, e quais duas falhas de aparência inofensiva viram um problema sério quando encadeadas.

O que a varredura automatizada deixa na mesa

A documentação da Fluid Attacks coloca um número no teto. A varredura de vulnerabilidades sozinha "finds only 10% to 30% of the total risk exposure of a system", e só os testes manuais podem confirmar o resto, incluindo os "business flows that need an environment, authentication, or test data".

O benchmark concorda. 73,2 % das 1.201 vulnerabilidades da aplicação avaliada estavam atrás de autenticação, que é o território onde um scanner chega por último e o hacking ético chega primeiro.

Severidade, não volume

Volume é o placar errado para o hacking ético. No relatório State of Attacks 2026, que cobre 1.119.396 vulnerabilidades reportadas entre 1º de janeiro e 31 de dezembro de 2025, as ferramentas automatizadas identificaram 88,4 % dos achados e o trabalho manual identificou os 11,6 % restantes.

Mas 87 % das vulnerabilidades de severidade crítica foram identificadas por revisão manual. Os achados de ferramentas automatizadas tiveram média de 15,5 unidades CVSSF; os do trabalho manual, 93,2, seis vezes mais. Esses números vêm somente do plano Advanced.

Hacking ético, pentesting e red teaming

O hacking ético é a categoria ampla; um pentest e um exercício de red team são duas maneiras de fazê-lo. Um pergunta o que está quebrado neste alvo. O outro pergunta se a organização sequer notaria um adversário.

Os dois são hacking ético e os dois são executados por hackers éticos. A distinção que vale a pena manter é a de cima, não a que ordena as avaliações por tipo de alvo. Ordenar por alvo — aplicações web, aplicações móveis, APIs, infraestrutura em nuvem — descreve tipos de pentesting, não tipos de hacking ético.

Hacking ético na Fluid Attacks

A Fluid Attacks é uma empresa de segurança ofensiva cujo hacking ético roda continuamente nos sistemas dos clientes, sob o plano Advanced, ao lado de scanners próprios e IA. É assim que esse trabalho acontece, inclusive onde ele para.

O que avaliamos e sob quais regras

Cada trabalho parte de um alvo de avaliação que o cliente aprova e roda sob controles escritos para cada risco que testar em produção carrega. A Fluid Attacks define a intensidade e o ritmo de cada teste, não usa técnicas de força bruta não autorizadas e executa primeiro em um ambiente fora de produção qualquer teste que possa afetar a disponibilidade.

Duas regras decidem o resto. A Fluid Attacks sempre testa a partir dos próprios endereços IP, de modo que um alerta falso em um WAF ou SOC é resolvido na hora. E, conforme a documentação, "if a pentester has any doubt during a test, the pentester stops the test". O endpoint e o canal ficam sob controle total, com um modelo Zero Trust.

Como decidimos onde atacar em seguida

A cobertura não é o objetivo aqui. Como coloca a documentação da plataforma, "manual techniques and AI-SAST use statistical risk prioritization instead of file coverage as their operating objective". Um método pode testar todos os arquivos e ainda assim deixar passar uma vulnerabilidade crítica.

Modelos estatísticos escolhem quais sistemas recebem atenção, pesando quanto e há quanto tempo um sistema mudou, quais arquivos mudam mais, quantos autores os tocaram e seu histórico de vulnerabilidades em comparação com outros sistemas.

Esses modelos alimentam cinco times de ataque independentes: Systems, Criticals, Escapers, Deterministic e Reattack, e mais de um pode trabalhar o mesmo sistema ao mesmo tempo quando a prioridade de risco pede.

O que uma pessoa encontrou e 36 ferramentas não

Benchmark da Fluid Attacks contra uma aplicação web com 1.201 vulnerabilidades conhecidas equivalentes a 461.500 unidades CVSSF.

A diferença que importa está na última coluna. O hacking ético encontrou 743 vulnerabilidades que nenhuma ferramenta encontrou: 61,9 % do total, carregando 86,8 % da exposição ao risco. O pentest manual aprofunda o porquê.

Cada achado é revisado antes de o cliente ver

Um relatório não vai direto para o cliente. Ele entra como rascunho e passa por uma revisão por pares que pode devolvê-lo com qualquer uma de nove observações: redação, evidência, pontuação, consistência, omissão, nomenclatura, falso positivo, duplicado ou outra.

Três delas — nomenclatura, falso positivo e duplicado — encerram o ciclo com uma rejeição; as demais voltam para correção. Os revisores repetem o ciclo "with as many review cycles as necessary", e só então o cliente o vê. Essa é a metade sem brilho do hacking ético, e é do que é feito um resultado de 100 % de precisão.

Nove tipos de observação que um revisor pode devolver antes de o cliente ver o achado.

O que não avaliamos

Quatro limites decidem se este tipo de hacking ético serve ou não para um sistema.

• Sem código-fonte não há teste: um ambiente registrado sem o código-fonte fica fora do escopo.

• *Nem plataformas low-code nem servidores de e-mail*: a metodologia precisa de código-fonte em um repositório Git.

• Sem avaliação versão por versão: os testes miram a última versão de cada componente, e cada achado fica atado ao commit, ao binário ou ao ambiente onde apareceu.

• Sem SLA formal de tempo de detecção: existe um SLA de exatidão de 90 %, medido com F-scores ponderados por severidade, mas nenhuma promessa sobre quão rápido algo é encontrado.

Mais um, sobre o benchmark acima. A ferramenta automatizada com melhor desempenho foi o scanner da própria Fluid Attacks, não um produto de terceiros, e um recall de 22,7 % ainda significa deixar passar três de cada quatro vulnerabilidades. O alvo era uma aplicação controlada e vulnerável por padrão, não um sistema em produção, então esses números se leem como uma comparação entre métodos, não como uma previsão.

As cinco fases do hacking ético

O hacking ético roda em cinco fases: reconhecimento, enumeração, análise, exploração e relatório. Antes da primeira, o proprietário define e aprova o escopo e o alvo de avaliação, que pode ser aplicações web ou móveis, APIs e microsserviços, clientes pesados, infraestrutura em nuvem, redes e hosts, dispositivos IoT ou tecnologia operacional.

No hacking ético, o reconhecimento passivo quase não deixa rastro, enquanto o ativo aumenta bastante a chance de detecção. A quarta fase é onde, como já disse Andres Roldan, VP of Hacking da Fluid Attacks, o hacking ético se separa de uma ferramenta automatizada: a ferramenta identifica, a pessoa explora.

Essas fases não são uma convenção privada. A Fluid Attacks mapeia seus requisitos de segurança para metodologias reconhecidas em seu Database: 41 definições de controle do PTES e 12 do NIST SP 800-115, mapeadas para 51 e 25 requisitos.

Lógica de negócio: o que o hacking ético alcança e os scanners não

Vulnerabilidades de lógica de negócio são falhas no que uma aplicação tem permissão de fazer, não em como ela foi programada. A aplicação funciona exatamente como foi escrita; as regras que ela impõe estão erradas. Nenhuma ferramenta de correspondência de padrões as reconhece, porque não há padrão: só um processo que o hacking ético mostra que nunca deveria ter sido concluído.

O OWASP Web Security Testing Guide v4.2 dedica a elas uma categoria inteira, a seção 4.10, cujos nove testes se leem como coisas que só uma pessoa pode tentar: forjar requisições, quebrar verificações de integridade, abusar dos tempos de um processo e burlar fluxos de trabalho por completo.

O catálogo da Fluid Attacks tem as versões concretas. A fraqueza 013, referência insegura a objetos, descreve um mecanismo de autorização que "does not prevent one user from accessing another users data by modifying the key value that identifies it", mapeada para o requisito 176. A fraqueza 005 cobre a escalação de privilégios e a fraqueza 014 cobre a funcionalidade insegura: um recurso que faz parte do sistema e que um atacante pode usar para prejudicá-lo.

Uma falha de autorização em uma aplicação que de resto funciona: fraqueza 013, requisito 176.

O que transforma isso em achados é o pivoting, que a documentação de comparação da Fluid Attacks define como explorar vulnerabilidades "together or one after the other", para encontrar caminhos de ataque com impactos mais severos do que explorar cada uma separadamente. No hacking ético, uma falha de severidade média costuma ser crítica assim que se mostra que ela é o primeiro passo de uma cadeia.

Como o hacking ético reporta e divulga vulnerabilidades

O relatório fecha o ciclo dentro da organização do cliente; a divulgação o fecha com todo o resto. O hacking ético usa marcos públicos para os dois: identificadores CVE para nomear uma vulnerabilidade sem ambiguidade e CVSS para comunicar a severidade.

A pesquisa sobre software de terceiros termina em outro lugar. O programa CVE autoriza organizações que chama de CNAs — "vendor, researcher, open source, CERT, hosted service, bug bounty provider, and consortium organizations" — a atribuir identificadores e publicar registros dentro do próprio escopo. Hoje são 564 CNAs de 43 países.

A Fluid Attacks é uma delas desde 2 de junho de 2021, admitida pelo MITRE como CNA do tipo pesquisador. Como escreveu Andres Roldan, VP of Hacking, ao analisar o desempenho dos CNAs pesquisadores:

"Our scope is any software that is not within the scope of other CNAs".

Na prática isso é a lista pública de advisories, filtrável por quem encontrou cada vulnerabilidade: o scanner de AI SAST, os pentesters da própria Fluid Attacks ou pentesters externos. As entradas recentes nomeiam o pesquisador: Andres Ramos, por uma injeção de comandos do sistema operacional no PingTools Network Utilities 4.64, com pontuação 8.6 High. É assim que encontrar vulnerabilidades de dia zero e praticar divulgação responsável se parece quando está documentado e não apenas declarado.

Cada advisory nomeia o pesquisador que o encontrou e o CVE atribuído.

A mesma disciplina corre ao contrário. A Fluid Attacks testa a própria tecnologia com técnicas automatizadas e manuais, roda pipelines que incluem exploits e linters rigorosos, e opera um programa de bug bounty aberto a qualquer pessoa, com recompensas conforme o impacto. Quando um pesquisador externo reporta algo, a equipe de resposta combina com ele uma data de publicação e pergunta se ele quer crédito.

Dentro de um trabalho, o hacking ético termina com verificação e não com um PDF: os reataques manuais são ilimitados e uma pessoa testa de novo cada achado manual.

Ferramentas, habilidades e certificações do hacking ético

As ferramentas aceleram o hacking ético; elas não o executam. A Fluid Attacks publica o instrumental que seus analistas usam — 59 ferramentas, atualizado em 3 de novembro de 2026 — e descreve o papel delas com precisão: "the security analysts of Fluid Attacks use the automation of these tools to make their security testing faster".

O instrumental está publicado e datado: 59 ferramentas, em 3 de novembro de 2026.

As habilidades decidem mais do que qualquer uma delas. Os pentesters da Fluid Attacks têm 202 certificações de 59 tipos diferentes, e suas acreditações incluem penetration testing pela CREST, além do status de CNA. Eles são empregados, não colaboradores pagos por achado.

▶️ Vídeo: um meetup sobre como se certificar em pentest de IA com as credenciais AIRTP+ e C-AI/MLPen. (Em espanhol).

Para aprofundar: como se tornar um hacker ético cobre o terreno técnico e não técnico por trás do hacking ético como carreira.

Quem precisa de hacking ético e como escolher um fornecedor

Onde um padrão ou um regulador pede um teste de penetração, o hacking ético deixa de ser opcional: o serviço da Fluid Attacks valida requisitos de 67 padrões. O caso é mais amplo do que conformidade: qualquer organização que desenvolva o próprio software ou exponha produtos na Internet é um alvo, e ciberataques como o ransomware e o phishing não consultam antes o tamanho da empresa.

Escolher um fornecedor de hacking ético é mais fácil com perguntas concretas do que com folhetos:

• Quem faz os testes? Empregados com contrato, ou um grupo rotativo de pesquisadores independentes.

• Quantas certificações e de quais tipos? Peça a contagem, não adjetivos.

• O serviço explora ou apenas reporta? Explorar e pivotar são capacidades distintas de detectar.

• Há pesquisa própria? Os advisories publicados mostram se um fornecedor encontra vulnerabilidades de dia zero ou apenas lê sobre elas.

• Como as correções são verificadas? Pergunte quantos reataques manuais estão incluídos e quem os executa.

• Como a exatidão é medida? Reportar os próprios falsos negativos contra um SLA é uma promessa mais difícil do que reportar achados.

Conclusões

O hacking ético conquista seu lugar em um programa de segurança por uma razão: ele produz evidência de explorabilidade que nenhum outro método produz. Um scanner diz que uma porta não tem fechadura. O hacking ético a atravessa e diz o que há dentro da sala.

Essa evidência custa tempo, e fingir o contrário não ajuda ninguém. Pessoas não trabalham no ritmo de uma máquina, e por isso o hacking ético fica ao lado dos testes automatizados e não no lugar deles: automação para amplitude e padrões conhecidos, pessoas para lógica de negócio e para tudo o que está atrás de autenticação.

Os fornecedores que valem a contratação mostram a metodologia, as acreditações e a pesquisa publicada antes de você assinar qualquer coisa.

Perguntas frequentes

O que um hacker ético encontra que um scanner não?

Vulnerabilidades de lógica de negócio, cadeias de ataque e quase tudo o que está atrás de autenticação. No benchmark da Fluid Attacks contra uma aplicação web com 1.201 vulnerabilidades conhecidas, um pentester encontrou 743 que nenhuma ferramenta automatizada encontrou: 61,9 % do total, carregando 86,8 % da exposição ao risco. A varredura sozinha cobre de 10 % a 30 % da exposição ao risco de um sistema.

Hacking ético e pentesting são a mesma coisa?

Não. Um pentest é uma forma de hacking ético, e um exercício de red team também; o hacking ético é a categoria mais ampla que cobre os dois. Um pentest pergunta o que pode ser explorado em um alvo definido. Um exercício de red team pergunta se a organização detectaria um adversário real e responderia.

O que são vulnerabilidades de lógica de negócio?

Falhas no que uma aplicação permite, mais do que em como ela foi escrita. O código roda certo e as regras que ele impõe estão erradas: um usuário que aprova a própria transação, um fluxo concluído fora de ordem, uma função usada mais vezes do que o permitido. O OWASP Web Security Testing Guide v4.2 dedica a elas a seção 4.10 e nove testes distintos.

Como funciona a divulgação responsável?

O pesquisador reporta a falha em privado a quem é dono do software e combina uma data de publicação para que a correção saia primeiro. Antes de reportar, ele reúne evidência. Uma CVE Numbering Authority atribui um identificador e o advisory é publicado depois. O programa lista 564 CNAs de 43 países.

A Fluid Attacks faz hacking ético e como isso é verificado?

Sim, continuamente, nos sistemas dos clientes sob o plano Advanced, que inclui Pentesting as a Service (PTaaS), Secure Code Review e engenharia reversa. Cada achado passa por uma revisão por pares de nove pontos antes de o cliente ver, os reataques manuais são ilimitados e o serviço tem um SLA de exatidão de 90 % medido com F-scores ponderados por severidade.

Coloque um hacker nisso antes que outro o faça

Nosso PTaaS leva hacking ético às suas aplicações continuamente, sob regras que você aprova, e prova quanto vale uma vulnerabilidade antes que ela te custe algo. Teste gratuito · Fale conosco.