1.

INTRODUÇÃO

Hackerrangers.com e todos os seus domínios são propriedade e operados pela Perallis

Security. Para efeitos deste guia, denomina-se “usuário” a pessoa física ou jurídica que
contrata o serviço de simulação de phishing no escopo da licença de uso da plataforma
Hacker Rangers.

Conforme o disposto nos termos de uso da plataforma, o usuário é responsável por realizar
todas as configurações e medidas necessárias em seus sistemas para viabilizar os disparos
de e-mails inerentes ao serviço contratado, incluindo, mas não limitado a: liberação dos
domínios indicados pela Perallis e verificação preventiva de validade dos e-mails
destinatários. Os colaboradores da Perallis não possuem autorização para acessar e/ou
realizar alterações em sistemas internos do usuário, ou qualquer outro externo à plataforma
Hacker Rangers.

Sendo certo que as configurações corretas são essenciais para a devida prestação do
serviço, este guia visa esclarecer os requisitos necessários para viabilizar o disparo de
simulações de phishing.

Destaca-se que cada empresa utiliza estruturas técnicas, metodologias, configurações,

ferramentas e sistemas próprios à sua atividade, de forma que não é realisticamente
possível citar todos os cenários. Toda citação neste guia deve ser interpretada como um rol
exemplificativo e as orientações devem ser adaptadas à realidade do usuário. Para disparar
uma campanha de phishing com sucesso, o usuário deve estar ciente de todas as
ferramentas utilizadas na segurança corporativa e realizar a liberação conforme necessário.

Aconselha-se que os times de segurança e de infraestrutura corporativa estejam cientes do

uso da funcionalidade de simulação de phishing, a fim de evitar sobrecarga causada por
denúncias indevidas dos colaboradores sobre a tentativa de phishing, bem como para que
os times não causem acidentalmente um bloqueio, prejudicando a eficácia da campanha
com falsos positivos/negativos.

2. FERRAMENTAS GERALMENTE UTILIZADAS QUE PODEM PRECISAR DE

LIBERAÇÃO

● Servidores de e-mail (exemplos: G-Suite, Outlook, Protonmail)

● Ferramentas antispam (exemplos: SpamHero, Heimdal, ESET, Malwarebytes,
Hornet)
● Gateways de e-mail (exemplos: Proofpoint, Sauk, Fortinet, Cloudflare)
● Gateways de internet (exemplo: Zscaler)
● Antivírus (exemplos: Bitdefender, Kaspersky, Sophos)
● Firewalls (exemplos: Cisco, WatchGuard, Netgear, TinyWall)
● IDS
● IPS
● SIEMs.
Destaca-se que nem todas essas ferramentas irão filtrar/bloquear o recebimento de e-mails,
algumas podem bloquear o acesso ao site, impedindo que o colaborador carregue a página
de destino e não contabilizando o clique do destinatário na simulação de phishing (falso
negativo). É de responsabilidade do usuário conhecer a infraestrutura da empresa e definir
quais pontos devem ser liberados para que a simulação ocorra com sucesso.

3. INFORMAÇÕES NECESSÁRIAS

Esta seção apresenta as informações necessárias para viabilizar o recebimento dos e-mails
e a abertura correta do site pelos destinatários durante a simulação de phishing.

As informações a serem consideradas vão depender das características de cada ferramenta

utilizada pelo usuário. Enquanto algumas possuem alta granularidade e admitem a inclusão
de múltiplas informações, permitindo a liberação integral e adequada, outras são mais
limitadas/ordinárias. Ou seja, quanto maior a granularidade da ferramenta (mais
informações puderem ser incluídas), maior a chance de sucesso de uma simulação.

3.1 SERVIDORES DE E-MAIL AWS SES E IPS FIXOS

A plataforma Hacker Rangers utiliza os servidores da AWS SES para disparar os e-mails. O
usuário deve garantir que a infraestrutura autorize o recebimento de e-mails dessa origem.

O usuário deve permitir o recebimento de e-mails que tenham como origem os servidores
de e-mail cujos IPs são 23.251.225.190 e 23.251.225.191. Todos os e-mails de simulação
de phishing serão enviados por servidores de e-mail que estejam configurados com esses
IPs.

3.2 CABEÇALHO “MESSAGE-ID”

Todos os e-mails de simulação possuem o cabeçalho “message-id” presente e utilizam o

domínio “sa-east-1.amazonses.com”. O prefixo é variável e gerado automaticamente pelo
sistema e estará no formato “{conjunto de caracteres}@sa-east-1.amazonses.com”.

Exemplo:

Message-ID:
010101467a0b401c-502fb3b2-d1b7-11e2-87e1-626a7b67e924-100300@sa-east-1.amazon
ses.com

3.3 CABEÇALHO “FROM”

Todos os e-mails de simulação possuem o cabeçalho “from” presente e seu conteúdo

dependerá do Remetente escolhido. Atualmente, a plataforma conta com 8 domínios para
serem utilizados como remetente e diversos prefixos. O usuário pode solicitar ao time da
Hacker Rangers para a criação de novos prefixos (ressaltando a não criação de prefixos
relacionados a marcas) e/ou a contratação de um dos planos para novos domínios. O
cabeçalho estará no formato “{Nome} <{prefixo}@{domínio escolhido}>”.

Exemplos:

From: Administração <adminstração@contatorh.com.br>

From: Miguel Silva <mi.sil@cobrancacorp.com.br>
From: Maria Oliveira <maria.oliveira@ofertatodahora.com.br>
From: Recursos humanos <rh@pesquisaoonline.com.br>
From: Loja Exemplo <exemplo@humanrcorp.store>
From: Não responder <nao-responder@humanrcorp.online>
From: Mensagem automática <no-reply@humanrcorp.com>

3.3 CABEÇALHO “DKIM” E “SPF”

Todos os e-mails de simulação possuem o cabeçalho “dkim” e “spf” presentes. Os

cabeçalhos “dkim” conterão a assinatura digital do e-mail, o domínio escolhido no
Remetente e o domínio da AWS SES (@amazonses.com). Os cabeçalhos “spf” conterão
um dos IPs dos servidores de e-mails e o subdomínio “alternativemail”, cujo domínio
dependerá do Remetente escolhido.

Exemplos (com o domínio “mlcpo.com”):

spf=
smtp.mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alt
ernativemail.mlcpo.com
Received-SPF: client-ip=23.251.225.190;
dkim=pass header.i=@mlcpo.com header.s=aaaaaaaaaa11111111aaaaaaaaaaaaaa
header.b=xXXxxxXx;
dkim=pass header.i=@amazonses.com
header.s=bbbbbbbbb222222222bbbbbbbbbb4bbb header.b=xXXxxxXx;
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=xxxxxxxxxxxxxxxxxxxxx; d=mlcpo.com; t=1111111111;
h=Mime-Version:Date:From:Message-Id:Subject:To:Content-Type:Content-Transfer-Encodin
g; bh=ZXhlbXBsb2V4ZW1wbG9leGVtcGxvZXhlbXBsb2V4ZW1wbG8=;
b=ZXhlbXBsb2V4ZW1wbG9leGVtcGxvZXhlbXBsb2V4ZW1wbG9leGVtcGxvZXhlbXBsb2V4
ZW1wbG9leGVtcGxvZXhlbXBsb2V4ZW1wbG9leGVtcGxvZXhlbXBsb2V4ZW1wbG9leGVtc
G==
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=xxxxxxxxxxxxxxxxxxxxx; d=amazonses.com; t=111111111111111;
h=Mime-Version:Date:From:Message-Id:Subject:To:Content-Type:Content-Transfer-Encodin
g:Feedback-ID; bh=ZXhlbXBsb2V4ZW1wbG9leGVtcGxvZXhlbXBsb2V4ZW1wbG8=;
b=ZXhlbXBsb2V4ZW1wbG9leGVtcGZW1wbG9leGVtcGxvZXhlbXBsb2V4ZW1wbG9leGVtc
GxvZXhlbXBsb2V4ZW1wbG9leGVtcGxvZXhlbXBsb2V4ZW1wbG9leGVtcGxvZXhlbXBsb2V
4ZW=

3.4 CABEÇALHO “RETURN-PATH”

Todos os e-mails de simulação possuem o cabeçalho “return-path” presente sendo
composto do subdomínio “alternativemail” em conjunto com o domínio escolhido no
Remetente. Estará no formato “{conjunto de caracteres}@alternativemail.{domínio
escolhido no remetente}”

Exemplos:

Return-Path:
<01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternativemail.ml
cpo.com>
Return-Path:
<01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternativemail.co
ntatorh.com.br>
Return-Path:
<01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternativemail.co
brancacorp.com.br>
Return-Path:
<01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternativemail.of
ertatodahora.com.br>
Return-Path:
<01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternativemail.pe
squisaoonline.com.br>
Return-Path:
<01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternativemail.hu
manrcorp.store>
Return-Path:
<01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternativemail.hu
manrcorp.online>
Return-Path:
<01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternativemail.hu
manrcorp.com>

3.4 CABEÇALHO “MAILFROM”

Todos os e-mails de simulação possuem o cabeçalho “mailfrom” presente e é composto do

subdomínio “alternativemail” em conjunto com o domínio escolhido no Remetente. Estará no
formato “{conjunto de caracteres}@alternativemail.{domínio escolhido no remetente}”

Exemplos:

mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternati
vemail.mlcpo.com
mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternati
vemail.contatorh.com.br
mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternati
vemail.cobrancacorp.com.br
mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternati
vemail.ofertatodahora.com.br
mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternati
vemail.pesquisaoonline.com.br
mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternati
vemail.humanrcorp.store
mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternati
vemail.humanrcorp.online
mailfrom=01234567890abcde-01234567-890a-bcde-f123-4567890abcde-000000@alternati
vemail.humanrcorp.com

3.5 CABEÇALHO “X-MAILER”

Todos os e-mails de simulação possuem o cabeçalho “X-Mailer” presente, cujo conteúdo

será “hrtranning”.

3.6 IMAGENS

Todas as imagens-padrão da plataforma utilizam o domínio "carpdiembr.com",

"imagens.carpdiembr.com" ou domínio "securityconection.com". A não liberação desses
domínios ou do carregamento das imagens poderá acarretar em desconfiguração do
template, não contabilização da abertura de e-mail e bloqueio do recebimento de e-mails.
Templates criados pelos usuários e inseridos na plataforma podem possuir URLs distintas
das citadas.

Exemplos:

https://imagens.carpdiembr.com/static/lenda_pose1.png
https://carpdiembr.com/track?rid=XXXXXXXXX
https://securityconection.com/track?rid=XXXXXXXXX

3.7 ACESSO A SITES/URLS

O usuário deve liberar o acesso aos sites “https://carpdiembr.com/” e

“https://securityconection.com/”. A não liberação dos sites poderá impedir o acesso às
páginas de destino, a contabilização dos cliques e o bloqueio do recebimento de e-mails. As
URLs sempre estarão no formato "https://{dominio}.com/?rid={conjunto de caracteres}".

Exemplos:

https://carpdiembr.com/?rid=XXXXXXXX
https://securityconection.com/?rid=XXXXXXXX

3.8 PALAVRAS-CHAVE

A depender do template de e-mail utilizado, pode ser necessário liberar a presença de

determinadas palavras contidas no título e/ou corpo do e-mail. Por exemplo, alguns
servidores de e-mail são configurados para bloquear qualquer e-mail que contenha a
palavra “hacker”. Se o título ou o corpo do template escolhido apresentar essa palavra,
existe a possibilidade de o e-mail ser bloqueado ou enviado para spam.
3.9 COMENTÁRIO PRESENTE NO “TEMPLATE DE E-MAIL” E NA “PÁGINA DE
DESTINO”

Todos os nossos templates de e-mail e páginas de destino possuem o seguinte comentário

no corpo do conteúdo. Destaca-se que, por ser um comentário, esse conteúdo somente
será visível se o usuário abrir o código-fonte da página ou do template.

<!--
---------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------
-----------
Equipe de segurança e analistas de código-fonte, este e-mail é uma simulação de phishing,
parte de um programa de conscientização e é enviado somente aos colaboradores da
empresa que contrata tal serviço.
---------------------
Equipe de seguranca e analistas de codigo-fonte, este e-mail eh uma simulacao de
phishing, parte de um programa de conscientizacao e e enviado somente aos colaboradores
da empresa que contrata tal servico.
---------------------
Security team and source code analysts, this e-mail is a phishing simulation, part of an
awareness program and is sent only to employees of the company that hires such service.
---------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------
-----------
-->

4. FALSO POSITIVO E FALSO NEGATIVO

Falsos positivos em simulações de phishing são situações em que a plataforma reconhece

a abertura/clique de um phishing sem que o destinatário tenha de fato aberto/clicado no
e-mail. Podem ocorrer quando:

● Alguma ferramenta realiza a verificação do conteúdo do e-mail;

● Falha na liberação dos itens citados na seção anterior (por exemplo, não liberação
do filtro de spam);
● Compartilhamento do e-mail/link pelo destinatário com outras pessoas;
● Existência de ferramenta de pré-visualização de e-mail ou conteúdo/link;
● Compartilhamento do e-mail pela ferramenta de verificação de conteúdo com outras
ferramentas.

Falsos negativos são situações em que a plataforma não reconhece a abertura/clique de

um phishing, porém o destinatário abriu/clicou no e-mail. Podem ocorrer quando:

● As imagens forem bloqueadas;

 ● O acesso aos sites estiver bloqueado.

Como forma de registro e para auxiliar na identificação do comportamento, a plataforma

salva os IPs e os horários do destinatário nos comportamentos de abertura e clique. Vale
destacar que o IP de clique e o IP de abertura de um destinatário podem ser iguais ou
diferentes, a depender da infraestrutura da empresa e das ferramentas utilizadas (provedor
de e-mail, etc.). Por exemplo, os IPs de abertura e clique podem ser iguais e os horários
extremamente próximos se uma ferramenta automaticamente realizou a verificação do
conteúdo do e-mail. Porém, os IPs também podem ser iguais se o destinatário abriu e clicou
no link a partir da mesma rede. O mesmo pode ser aplicado quando há IPs diferentes:
ferramentas automáticas podem possuir múltiplos IPs e, por isso, apresentar IPs distintos
para as duas ações, bem como o destinatário pode possuir IPs distintos se a empresa
possuir múltiplos endereços de IP.

O sistema realiza múltiplas verificações automáticas semanais visando identificar

comportamentos de falsos positivos/negativos. Quando detectados, a plataforma Hacker
Rangers realiza a devolução automática dos pontos perdidos. Para reduzir/impedir a
existência de injustiças na pontuação do destinatário e, consequentemente, em sua posição
no Ranking, as verificações sempre ocorrerão previamente ao final da semana.

Ao realizar a primeira simulação de phishing, caso haja suspeita de falso positivo ou

negativo, o usuário poderá solicitar a análise manual ao suporte técnico para auxiliar na
configuração. Este processo permitirá que o time faça uma análise especulativa sobre os
eventos registrados na simulação. Após a análise, as observações encontradas são
enviadas ao usuário e é de responsabilidade deste verificar se as informações relatadas
procedem de acordo com as particularidades da infraestrutura da empresa e das
configurações utilizadas. A depender do resultado, caso o usuário aprove, poderá ser criada
(ou atualizada, se já criada) uma lista de comportamentos a serem ignorados pela
plataforma. Esses comportamentos são baseados no IP de origem do clique/abertura.

A lista de comportamentos (mais especificamente, de IPs) pode ser criada/atualizada antes

da realização das simulações caso o usuário tenha conhecimento dos comportamentos
esperados. Por exemplo, o usuário sabe que a ferramenta interna ZScaler realiza uma
verificação de e-mails e causa um “acesso” ao site, o que poderá gerar falsos positivos.
Neste caso, o usuário pode informar uma relação de IPs que o ZScaler utiliza para que o
time da Hacker Rangers realize a configuração para não contabilizar cliques a partir dos IPs
informados.

Caso seja identificada uma ocorrência de falso positivo, o usuário, via plataforma, consegue
devolver os pontos perdidos ao destinatário. Para isso, basta utilizar a funcionalidade
“Devolver pontos”, que pode ser encontrada na visualização de detalhes da campanha de
phishing.

5. TESTES
Antes de realizar o disparo de uma simulação de phishing, recomenda-se a realização de
um ou mais testes para garantir as liberações necessárias e validar a eficácia da simulação,
reduzindo o risco de falhas na entrega e a ocorrência de falsos positivos/negativos.

Para um melhor aproveitamento do teste, é recomendável:

- Utilizar uma lista de, no mínimo, 12 destinatários;

- Organizar os destinatários em três partes: ⅓ da lista deve apenas receber o e-mail, ⅓ da
lista deve abrir o e-mail e ⅓ da lista deve abrir o e-mail e clicar no link. Caso a simulação
conte com uma situação de submissão de dados, aconselha-se dividir a lista em 4 partes;
- Avaliar se os e-mails foram recebidos com sucesso e se a plataforma contabilizou
corretamente as interações dos destinatários;
- Verificar com os times responsáveis pelas ferramentas de segurança corporativa se houve
algum tipo de bloqueio ou detecção do disparo da simulação.

6. VERIFICAÇÃO PREVENTIVA DOS E-MAILS DESTINATÁRIOS

O disparo de simulações de phishing contendo e-mails inválidos ou que são classificados

como spam impacta diretamente no desempenho dos servidores, diminuindo o alcance dos
e-mails e afetando a funcionalidade tanto para quem realizou o disparo, quanto para outros
usuários. Dependendo do impacto causado por uma simulação incorretamente configurada,
o tempo para mitigar o dano pode se estender por várias semanas até que novos e-mails
possam ser disparados.

Com o objetivo de proteger a integridade da funcionalidade, é responsabilidade do usuário

realizar uma verificação preventiva da lista de destinatários, atestando a validade dos
e-mails antes de iniciar a simulação (por exemplo, retirando e-mails desativados de
colaboradores desligados da lista).

Caso a simulação de phishing seja disparada para destinatários inválidos (ou seja, quando
o provedor de e-mail do destinatário envia uma mensagem de falha de entrega definitiva
[bounce]), a plataforma bloqueará o envio de e-mails/simulações para esses destinatários.
Esse processo é automático e não poderá ser desfeito, pois garante a proteção dos
sistemas da plataforma.

Caso seja detectada uma falha de entrega superior a 5% do total de destinatários, causada
pela inobservância da verificação preventiva pelo usuário, o disparo de e-mails e todas as
funcionalidades que dependem deste para serem executadas (por exemplo: e-mail de
primeiro acesso e simulação de phishing, quando aplicável) poderão ser suspensas até que
a causa da entrega acima do permitido seja corrigida e o impacto causado no servidor seja
mitigado. Destaca-se que a suspensão não tem caráter de penalização. Ela é necessária
para que as ações de mitigação possam ser tomadas pelo time da Hacker Rangers para a
regularização da funcionalidade.

7. DETALHES TÉCNICOS DE UMA SIMULAÇÃO DE PHISHING

Uma simulação de phishing é composta por cinco elementos: lista de destinatários, template
de e-mail, remetente, página de destino e listener.

Lista de destinatários: colaboradores cadastrados na plataforma Hacker Rangers que

farão parte da simulação de phishing. Estes colaboradores receberão um e-mail e, caso
cliquem no link, perderão pontos no Ranking (comportamento padrão da plataforma que
pode ser alterado). Atualmente, a plataforma Hacker Rangers suporta uma lista de até 2000
destinatários.

Template de e-mail: composto pelo título (cabeçalho “Subject/Assunto”) e conteúdo do

e-mail que a lista de destinatários receberá. Assim como em uma situação real de phishing,
o objetivo do template geralmente envolve convencer o destinatário a tomar uma ação que
ele normalmente não deveria executar.

Remetente: e-mail do qual será enviada a simulação de phishing. Normalmente, escolhe-se

um remetente que possua relação com o template de e-mail. Essa informação estará
presente no cabeçalho “From/De” de um e-mail.

Página de destino: conteúdo do site a ser carregado após o destinatário clicar no link
presente no template de e-mail. Para contabilizar o clique, o destinatário deve,
obrigatoriamente, carregar a página. Geralmente, a página de destino é um informativo de
que o destinatário participou de uma simulação de phishing e falhou em identificar ou se
proteger desse tipo de golpe.

Listener: URL (link) exibida para o destinatário ao carregar a página de destino. Essa
também será a URL que aparecerá para o destinatário se ele mantiver o cursor (hover) em
cima do hiperlink do template de e-mail.

Em uma simulação de phishing, todos os destinatários da lista receberão o mesmo template

de e-mail, remetente, página de destino e listener. Alguns modelos de template são
estruturados para apresentar o nome/e-mail de acordo com o destinatário.

Destaca-se que os elementos podem ou não estar alinhados com o tema escolhido para a
simulação (a depender da intenção do usuário). Uma simulação mais complexa que visa
treinar os destinatários para golpes mais elaborados deve alinhar o conteúdo de todos os
elementos de forma que o e-mail pareça real. Por outro lado, uma simulação mais óbvia
pode utilizar elementos que não concordam entre si (por exemplo, um template de banco
com remetente de venda de roupa), deixando evidências para que os destinatários
identifiquem sinais comuns de que pode se tratar de um golpe.

Escolhidos os elementos e agendada a simulação, a plataforma Hacker Rangers seguirá

com os procedimentos necessários para a execução.

Primeiro, cada destinatário receberá um identificador único. Esse identificador, presente no

corpo do template de e-mail ("https://{listener}/track?rid={identificador único}") e na URL
da página de destino ("https://{listener}/?rid={identificador único}"), será responsável por
identificar qual destinatário realizou qual ação. Dessa forma, o compartilhamento do
e-mail/URL (e, logo, do identificador único) permite que outra pessoa realize uma ação em
nome daquele destinatário, prejudicando-o e gerando falsos positivos.

Após a distribuição do identificador único, quando aplicável, os templates estruturados para

apresentar o nome/e-mail de acordo com o destinatário são alterados para substituir o
modelo pelas informações do destinatário. As substituições utilizam as informações
cadastradas na plataforma Hacker Rangers. Assim, se o nome do destinatário estiver
errado, o template de e-mail também possuirá o erro. Na mesma fase, a plataforma insere
no template de e-mail uma pequena imagem transparente “invisível” (ou seja, com estilo
“display: none”), cuja URL será no formato "https://{listener}/track?rid={identificador único}",
utilizada para identificar se o destinatário abriu ou não o e-mail. Caso a imagem não seja
carregada (por exemplo, por bloqueio da ferramenta utilizada pelo destinatário para abrir
e-mails), a plataforma não contabilizará a abertura do e-mail.

Na próxima etapa, o disparo dos e-mails é realizado. Esse disparo é sequencial e, portanto,
pode demorar a depender do tamanho da lista de destinatários. Quanto maior a lista, maior
a diferença de tempo entre o primeiro e o último e-mail disparado.

Depois, é feita a contabilização dos cliques e aberturas. Toda vez que um usuário abrir o
e-mail (ou seja, carregar a imagem citada previamente) ou clicar no link do template (que
estará no formato "https://{listener}/?rid={identificador único}") e carregar a página de
destino,1 o sistema registra a ação e, se aplicável, realiza a subtração de pontos. Por ser um
processo que exaure o sistema, as contabilizações das ações podem demorar até 15
minutos, ou seja, a subtração de pontos e o registro da ação na plataforma podem demorar
até 15 minutos para ocorrer após a ação do destinatário.

Por fim, a simulação é encerrada automaticamente após 30 dias ou na data configurada

pelo usuário. Após o encerramento da simulação, os cliques e aberturas não são mais
contabilizados pelo sistema.

1
Lembre-se de que o não carregamento da página acarreta a não contabilização do clique e,
portanto, um falso negativo).