# Beephish — Simulação de Phishing e Gestão de Risco Humano

> Eduque, teste e monitore seus colaboradores contra phishing. Plataforma brasileira de Gestão de Risco Humano com +100.000 usuários treinados.

Canonical: https://beephish.com/blog/alem-do-click-rate-o-que-importa

A taxa de clique provavelmente é o indicador mais conhecido de uma campanha de phishing simulado. Sua popularidade tem uma explicação simples: é fácil calcular, fácil comparar e fácil apresentar. Se enviamos uma campanha para mil pessoas e cinquenta clicam, temos uma taxa de clique de 5%. Se, alguns meses depois, esse número cai para 3%, existe uma indicação de que alguma coisa mudou no comportamento da população testada.

O problema técnico começa quando tentamos utilizar esse percentual para responder perguntas para as quais ele não foi construído. Uma taxa de clique não mostra, sozinha, quantas pessoas reconheceram o ataque, quantas reportaram a mensagem, quanto tempo a organização levou para detectar a campanha, se os mesmos usuários estão repetindo o comportamento ou se as identidades que clicaram possuem algum contexto de risco relevante.

Também existe outro problema: campanhas diferentes não são necessariamente comparáveis. Um phishing genérico sobre redefinição de senha pode produzir um resultado completamente diferente de um cenário contextualizado para determinada área. Se compararmos os dois percentuais sem considerar essa diferença, podemos concluir que houve evolução ou regressão quando, na realidade, apenas modificamos a dificuldade do teste.

Por isso, medir a evolução de um programa de phishing exige sair da lógica de uma única métrica e começar a trabalhar com um conjunto de sinais que represente diferentes etapas da interação entre a pessoa e a ameaça.

## **Clique é um sinal, não uma conclusão**

O primeiro passo é compreender exatamente o que estamos medindo quando registramos um clique. Tecnicamente, ele representa uma interação com determinado elemento da campanha. Dependendo da simulação, essa interação pode ser abrir um link, acessar uma página ou iniciar alguma outra ação monitorada.

Esse evento é importante porque demonstra que o cenário conseguiu produzir engajamento suficiente para levar a pessoa até uma etapa seguinte. Entretanto, existe uma diferença significativa entre clicar em um link e concluir toda a cadeia que um atacante esperava.

Uma pessoa pode clicar e perceber imediatamente que existe algo errado. Outra pode acessar a página, inserir credenciais e tentar autenticar. Uma terceira pode executar uma ação adicional solicitada pelo cenário. Se todas forem contabilizadas simplesmente como “usuários que clicaram”, perdemos informações importantes sobre a profundidade da interação.

Por isso, campanhas mais maduras deveriam registrar diferentes etapas do comportamento. O click rate continua existindo, mas pode ser acompanhado por indicadores como credential submission rate, attachment interaction, execução de ações simuladas ou outros eventos compatíveis com o cenário utilizado.

Essa separação permite observar até onde as pessoas avançaram na cadeia de ataque, em vez de reduzir todo o comportamento a uma decisão binária entre clicar e não clicar.

## **Submissão de credencial ou dados precisam ser analisado separadamente**

Quando uma campanha simula uma página de autenticação, o fornecimento de credenciais representa uma etapa diferente do clique. Uma pessoa pode acessar a página e interromper a interação ao perceber inconsistências. Outra pode continuar e inserir usuário e senha.

Do ponto de vista de medição, essas situações não deveriam ter exatamente o mesmo peso.

O credential submission rate permite compreender quantas pessoas ultrapassaram a primeira interação e chegaram a uma ação que, em um ataque real, poderia produzir comprometimento de identidade. Isso se torna especialmente relevante em campanhas que simulam Microsoft 365, Google Workspace, VPNs, portais corporativos ou outras aplicações nas quais o objetivo do atacante é obter credenciais.

Ainda assim, precisamos evitar transformar credential submission em uma representação absoluta de risco. A presença de MFA, autenticação resistente a phishing, políticas de acesso condicional e outros controles modifica significativamente o impacto potencial de uma credencial capturada.

É justamente aqui que começamos a perceber por que métricas comportamentais e contexto técnico precisam conversar. A simulação mostra aquilo que a pessoa fez. A arquitetura de segurança mostra quais consequências aquele comportamento poderia produzir.

## **Taxa de reporte mostra a capacidade de defesa da população**

Se click rate mede uma interação indesejada, report rate mede um comportamento desejável. Essa diferença é importante porque programas de conscientização não deveriam observar apenas falhas.

Uma pessoa que identifica uma mensagem suspeita e utiliza o mecanismo de reporte da organização está produzindo um sinal de segurança. Em uma campanha simulada, isso demonstra reconhecimento do cenário. Em um ataque real, o mesmo comportamento pode fornecer ao SOC ou ao time responsável um indicador antecipado de que uma campanha está em andamento.

Por isso, report rate deveria ocupar uma posição muito mais importante nos dashboards de conscientização. O cálculo básico é simples: quantas pessoas reportaram a mensagem em relação à população que recebeu a campanha. Entretanto, a interpretação pode ser enriquecida quando combinamos essa informação com outros eventos.

Uma pessoa pode clicar e depois reportar. Outra pode reportar sem interagir. Uma terceira pode simplesmente ignorar a mensagem. Essas três situações representam comportamentos diferentes e deveriam permanecer distinguíveis no modelo.

Também precisamos tomar cuidado para não interpretar qualquer crescimento do report rate como evolução automática. Se as campanhas se tornam excessivamente previsíveis, usuários podem começar a reportar qualquer mensagem minimamente incomum. Isso melhora a métrica, mas pode aumentar significativamente o volume operacional recebido pela equipe responsável.

Por isso, quando possível, o programa também deve observar a qualidade dos reports e a capacidade de distinguir mensagens realmente suspeitas de comunicações legítimas.

[![](https://kvlbuwxkkllobkgvzsam.supabase.co/storage/v1/object/public/blog-content/inline/1780320814605-15vsqx.png)](#fale-com-especialista)

## **Tempo até o reporte pode ser tão importante quanto a taxa**

Saber quantas pessoas reportaram é importante, mas saber quando ocorreu o primeiro reporte adiciona uma dimensão operacional extremamente útil.

Imagine uma campanha real enviada para centenas de colaboradores. Se alguém identifica e reporta a mensagem em dois minutos, a equipe de segurança pode iniciar a investigação enquanto grande parte dos destinatários ainda nem abriu o e-mail. Se o primeiro reporte acontece três horas depois, a janela de exposição é muito maior.

Esse comportamento pode ser representado pelo time-to-report, especialmente pelo tempo até o primeiro reporte e pela distribuição dos reports ao longo do tempo.

Em simulações, essa métrica ajuda a avaliar se a organização está desenvolvendo capacidade coletiva de detecção. O objetivo deixa de ser apenas ensinar cada pessoa a não clicar e passa a incluir a capacidade de produzir rapidamente sinais para o time de segurança.

Em organizações que integram o botão de reporte com ferramentas de análise de e-mail, SIEM, SOAR ou processos do SOC, essa métrica se torna ainda mais relevante porque conecta comportamento humano à capacidade operacional de resposta.

Podemos começar a enxergar o colaborador não apenas como alguém que precisa evitar um erro, mas como um sensor distribuído dentro da arquitetura de segurança.

## **Reincidência ajuda a separar eventos de padrões**

Uma taxa média de clique não mostra se os eventos estão distribuídos pela população ou concentrados nas mesmas identidades.

Esse é um problema importante. Imagine duas campanhas com 5% de clique. Na primeira, praticamente todas as pessoas que clicaram nunca haviam apresentado aquele comportamento antes. Na segunda, metade dos cliques vem de um grupo que já repetiu o mesmo comportamento em diversas campanhas anteriores. O percentual agregado é semelhante, mas o segundo cenário apresenta uma informação adicional que merece atenção.

Por isso, precisamos acompanhar reincidência. Isso pode ser feito observando eventos por identidade dentro de janelas temporais definidas. A janela é importante porque três cliques em campanhas realizadas ao longo de quatro anos possuem significado diferente de três cliques em dois meses.

Também é necessário considerar o tipo de cenário. Repetir um comportamento diante do mesmo vetor pode indicar uma necessidade específica. Já interações com ataques completamente diferentes podem representar outro padrão.

Essa análise permite sair do conceito simplista de “repeat clicker” e trabalhar com algo mais útil: quais comportamentos estão se repetindo, em quais contextos e durante qual período.

## **A evolução individual também precisa aparecer**

Se acompanhamos reincidência, precisamos acompanhar o movimento contrário. Uma pessoa pode ter clicado em campanhas anteriores, recebido uma intervenção e posteriormente demonstrado evolução consistente. Talvez deixe de interagir com cenários semelhantes, passe a reportá-los rapidamente ou apresente comportamento positivo em campanhas mais sofisticadas.

Se o dashboard mostra apenas o histórico acumulado de falhas, essa pessoa continuará parecendo de alto risco mesmo depois de modificar seu comportamento.

Por isso, métricas de phishing precisam considerar temporalidade. Eventos recentes normalmente devem ter maior relevância para a compreensão do estado atual do que eventos antigos, especialmente quando existem evidências de mudança posterior.

Isso não significa apagar o histórico. Ele continua útil para compreender trajetória e reincidência. Mas histórico e estado atual são coisas diferentes. Uma arquitetura de Human Risk Management precisa ser capaz de preservar ambos.

## **A dificuldade do cenário precisa fazer parte dos dados**

Comparar campanhas sem considerar dificuldade é um dos problemas mais comuns na análise de phishing simulation. Uma campanha extremamente óbvia pode produzir 1% de clique. Um spear phishing bem contextualizado pode produzir 7%. Concluir simplesmente que a organização piorou seria incorreto se os dois testes possuem níveis de dificuldade completamente diferentes.

O desafio é que dificuldade não é uma característica perfeitamente objetiva. Ela pode variar de acordo com a população. Um cenário sobre folha de pagamento pode ser muito convincente para uma área e completamente irrelevante para outra.

Mesmo assim, é possível estruturar atributos que ajudem na comparação. Podemos registrar se o cenário utiliza personalização, impersonation, urgência, página de autenticação, anexos, QR Codes, contexto corporativo, marcas conhecidas ou outras técnicas. Também podemos classificar campanhas em níveis de complexidade definidos pelo próprio programa.

Com o tempo, os resultados históricos ajudam a calibrar essa classificação. Se determinados tipos de cenário consistentemente produzem maior interação em populações semelhantes, essa informação pode contribuir para uma avaliação mais realista da dificuldade.

O objetivo não é criar uma fórmula universal para dizer que uma campanha possui dificuldade 7,3. É evitar comparar percentuais como se todos os testes fossem equivalentes.

## **Comparações precisam considerar populações equivalentes**

O mesmo princípio vale para quem recebeu a campanha. Se uma simulação é enviada para toda a organização e outra apenas para um grupo altamente exposto, comparar diretamente os percentuais pode gerar interpretações incorretas. Áreas, funções, regiões, tempo de empresa e outros fatores podem modificar significativamente o resultado.

Por isso, análises de tendência precisam trabalhar, sempre que possível, com populações comparáveis.

Isso não significa fragmentar o dashboard até que cada pessoa se torne uma categoria própria. O objetivo é permitir cortes suficientes para identificar diferenças relevantes. Área de negócio, função, nível de privilégio, grupo de risco ou outros segmentos podem ajudar a descobrir padrões escondidos pela média corporativa.

Essa segmentação também permite identificar uma situação importante: a organização pode estar melhorando como um todo enquanto determinados grupos permanecem estáveis ou até pioram. É justamente nesses grupos que uma intervenção direcionada pode gerar maior retorno.

## **Métricas comportamentais precisam encontrar o contexto de risco**

Até aqui, praticamente todas as métricas poderiam existir dentro de uma boa plataforma de phishing simulation. O salto para Human Risk Management acontece quando começamos a correlacionar esses comportamentos com contexto externo ao programa de awareness.

Imagine duas pessoas que forneceram credenciais na mesma campanha. Uma possui acesso limitado a aplicações de baixo impacto. A outra possui privilégios administrativos e acesso a ambientes críticos. O comportamento observado foi igual, mas o risco potencial é claramente diferente.

Da mesma forma, uma identidade altamente exposta a ataques direcionados pode merecer atenção mesmo apresentando bom desempenho nas campanhas. O fato de nunca ter clicado em uma simulação não elimina o risco associado à sua exposição, aos privilégios que possui ou ao impacto potencial de um comprometimento.

Isso significa que métricas de phishing não deveriam ser utilizadas isoladamente para determinar Human Risk Score. Elas são uma fonte de telemetria comportamental que precisa ser combinada com identidade, exposição, contexto e impacto.

Essa separação também evita um erro conceitual importante: transformar um phishing score em Human Risk Score apenas mudando o nome do indicador.

## **Um dashboard de phishing precisa mostrar mais do que uma porcentagem**

Quando reunimos esses elementos, o dashboard começa a mudar. Click rate continua presente porque é uma métrica útil. Credential submission mostra a profundidade da interação. Report rate apresenta comportamento positivo. Time-to-report ajuda a compreender velocidade de detecção. Reincidência mostra padrões. Evolução individual permite reconhecer mudança. Dificuldade e tipo do cenário fornecem contexto para comparação, enquanto segmentação ajuda a identificar concentrações que desaparecem na média organizacional.

Não precisamos necessariamente condensar tudo isso em um único número. Em alguns casos, tentar criar um índice universal pode esconder novamente as diferenças que estamos tentando compreender.

É mais útil construir uma visão capaz de responder perguntas. Estamos reduzindo interações perigosas? As pessoas estão reportando mais rapidamente? Os mesmos indivíduos continuam apresentando dificuldades? Quais tipos de ataque produzem maior suscetibilidade? Quais populações precisam de atenção? As intervenções realizadas estão modificando o comportamento?

Essas perguntas ajudam muito mais na gestão do programa do que simplesmente saber se a taxa corporativa passou de 4,2% para 3,8%.

## **De KPI de campanha para telemetria de comportamento**

A principal evolução acontece quando deixamos de tratar cada campanha como um evento isolado e começamos a enxergar o conjunto das interações como uma fonte contínua de telemetria.

Uma simulação produz vários sinais. A pessoa recebeu o cenário, abriu ou ignorou a mensagem, interagiu com algum elemento, avançou para etapas adicionais, reportou ou não reportou e realizou essas ações dentro de determinada sequência temporal. Campanhas posteriores mostram se esse comportamento se repete ou muda.

Quando conectamos esses sinais à identidade, conseguimos construir histórico. Quando adicionamos contexto de função, exposição, privilégios e impacto, conseguimos compreender melhor o risco. Quando aplicamos uma intervenção e continuamos observando os sinais seguintes, conseguimos avaliar se ela produziu mudança.

É nesse ponto que phishing simulation deixa de funcionar apenas como um mecanismo periódico para produzir uma taxa de clique e passa a ocupar um papel muito mais interessante dentro de Human Risk Management.

A taxa de clique continua importante, mas agora representa apenas uma das dimensões observadas. O objetivo técnico deixa de ser produzir o menor percentual possível e passa a ser construir evidências suficientes para entender como as pessoas respondem às ameaças, onde existem padrões relevantes e quais intervenções realmente modificam esses comportamentos.

Quando conseguimos fazer isso, deixamos de perguntar apenas “quantas pessoas clicaram nesta campanha?” e começamos a responder uma pergunta muito mais útil para segurança: “o que os comportamentos observados ao longo do tempo nos dizem sobre o risco e sobre a evolução das pessoas que estamos tentando proteger?”.

---
Fonte: Beephish — https://beephish.com