O que os achados significam
Cada verificação que esta ferramenta faz, o que ela realmente examina e o que um achado diz e não diz a você.
Cada verificação que esta ferramenta faz, o que ela realmente examina e o que um achado diz e não diz a você.
Cada achado na tela de resultado traz uma explicação de uma linha e a evidência de onde ele foi tirado. Esta página é a versão longa: qual é o mecanismo por trás, por que os atacantes interagem com ele do jeito que interagem e quanto peso um achado merece.
Uma ideia para levar do começo ao fim: estas verificações se confirmam umas às outras. Nenhuma delas é um veredito sozinha. Várias são comuns em e-mails legítimos e só ficam interessantes em conjunto.
Como uma mensagem é montada
Um e-mail tem duas partes: um bloco de cabeçalhos no topo e, depois, o corpo. Os cabeçalhos são onde o remetente é informado, onde cada servidor que processou a mensagem deixou o próprio registro e onde os resultados de autenticação são anotados. O seu programa de e-mail esconde quase tudo isso e mostra um nome, um assunto e o corpo.
Quase tudo o que esta ferramenta faz é ler os cabeçalhos. É por isso que ela pede o código-fonte, e não uma captura de tela ou um encaminhamento: um encaminhamento perde os cabeçalhos originais e os substitui pelos seus.
Autenticação, e por que passar não é garantia
O que os três mecanismos realmente verificam
O SPF responde: o servidor que entregou esta mensagem está na lista de servidores autorizados a enviar em nome deste domínio? Quem publica essa lista é o dono do domínio.
O DKIM responde: esta mensagem foi assinada criptograficamente por alguém que tem uma chave publicada pelo domínio, e ela foi alterada desde então? A assinatura cita o domínio que assinou — é o valor d= que você vai ver na evidência.
O DMARC liga tudo isso ao endereço que você realmente vê. Sozinho, um resultado aprovado de SPF ou DKIM pode pertencer a um domínio completamente diferente do que está na linha From — o que não diria nada a quem lê. O DMARC exige alinhamento: o domínio que passou tem que corresponder ao domínio que é mostrado a você.
O que o alinhamento significa, na prática
Suponha que uma mensagem mostre notice@bank.example.jp na linha From e traga uma assinatura DKIM de mailer.example.net. A assinatura é válida. Mas o domínio que respondeu pela mensagem não é o domínio que o leitor vê, então ela não está alinhada, e o DMARC não considera a mensagem autenticada para bank.example.jp.
O alinhamento pode ser estrito (o domínio tem que corresponder exatamente) ou flexível (o domínio registrado tem que corresponder, então mail.bank.example.jp se alinha com bank.example.jp). Descobrir qual é o domínio registrado é a parte que tem uma ressalva — veja o aviso no fim desta página.
Por que passar na autenticação é o que há de menos interessante na página
Esta é a ideia mais importante desta ferramenta, e é o contrário do que a maioria das pessoas supõe.
A autenticação prova quem é o dono de um domínio. Ela não prova que uma mensagem é o que diz ser. Um atacante que registra bank-example-support.com é dono desse domínio por completo. Ele pode publicar registros SPF para ele, assinar com DKIM em nome dele e publicar uma política DMARC nele — em minutos, pelo preço do domínio. Cada mensagem que ele envia passa então perfeitamente na autenticação, porque tudo o que ela afirma sobre si mesma é verdade. Ela só não é o banco.
No phishing observado, este é o caso majoritário, e não um caso extremo. Cerca de metade dele vem de domínios registrados por atacantes, e a esmagadora maioria desses passa no DMARC. É por isso que esta ferramenta apresenta uma aprovação como “este domínio é quem diz ser” e nada mais caloroso, e é por isso que a análise de domínios parecidos e de links pesa mais aqui do que a autenticação.
Uma falha ainda vale a pena conhecer — é a forma que um remetente falsificado produz. Mas listas de discussão e serviços de encaminhamento quebram a autenticação de forma rotineira e inocente, então uma falha sozinha também não é um veredito.
ARC, para mensagens que foram encaminhadas
Quando uma lista de discussão reescreve uma mensagem, ela quebra a assinatura original. O ARC permite que cada salto registre o que viu antes de repassar a mensagem, para que um servidor posterior possa ver que a autenticação passou antes, mesmo que falhe agora. Quando esta ferramenta informa que uma cadeia ARC falhou na verificação, isso significa que não foi possível confiar nesse registro — então o que aconteceu com a mensagem antes de ela chegar até você não pode ser confirmado.
A rota de entrega
O que é uma cadeia Received
Cada servidor que processa uma mensagem acrescenta uma linha Received no topo dos cabeçalhos: quem se conectou, quem recebeu e quando. Lidas de baixo para cima, elas são o percurso da mensagem. A ferramenta as mostra da mais recente para a mais antiga, com o intervalo entre cada par na linha que os liga.
Só os saltos mais recentes são confiáveis. Cada servidor só pode responder pela conexão que ele mesmo aceitou. Tudo o que está abaixo do primeiro servidor controlado pelo seu próprio provedor foi escrito por máquinas nas quais você não tem motivo para confiar, e um atacante pode inventar quantas linhas quiser. É por isso que um salto inicial com aparência estranha é um sinal, e não uma prova.
Carimbos de data/hora que andam para trás
Cada salto registra o horário do próprio relógio, então pequenas divergências são normais — relógios se desajustam. Quando um servidor posterior registra um horário anterior ao do servidor antes dele, por mais do que esse desajuste explica, ou um relógio está muito errado ou parte da rota foi escrita à mão. Cabeçalhos fabricados costumam ser escritos de uma vez, por alguém que não presta atenção às contas.
Um intervalo longo e sem explicação
Mais de um dia entre dois saltos. Filas de e-mail e novas tentativas causam isso de verdade, então isso é informado como algo a notar, e não como algo para agir. Vale uma olhada porque também pode significar que uma mensagem foi escrita antes e injetada depois, ou que um bloco de cabeçalhos foi copiado de uma mensagem real.
Um endereço privado em um percurso público
Algumas faixas de endereços só funcionam dentro de uma rede privada e não podem ser alcançadas pela internet. Um desses endereços aparecendo no meio de um percurso público geralmente significa que a linha foi copiada ou inventada, porque a conexão que ela descreve não poderia ter acontecido.
Enviada de um servidor em nuvem sem nome
Organizações que enviam o próprio e-mail normalmente dão aos seus servidores de e-mail nomes escolhidos por elas. Um primeiro salto cujo nome foi gerado automaticamente por um provedor de hospedagem significa que o remetente usa capacidade alugada sem configurá-la — o que é comum para alguns remetentes pequenos e também é o jeito mais barato de enviar a partir de um endereço que ninguém reconhece. Isso é informado como um detalhe, nunca como um veredito, e nunca só por causa de quem é o provedor.
Uma anotação deixada por um servidor de recebimento
Às vezes um servidor que processou a mensagem registrou a própria dúvida sobre quem estava se conectando a ele — muitas vezes, que o endereço que se conectava não tem nome reverso, o que acontece de forma desproporcional com remetentes em massa. Quando você vir isso, é a anotação desse servidor, citada como foi escrita. Esta ferramenta não faz consultas por conta própria; ela está relatando o que já está na mensagem.
De quem a mensagem diz ser
O nome e o endereço são definidos separadamente
Um remetente é um nome de exibição mais um endereço, e esses são campos independentes — quem envia escreve os dois. A maioria dos programas de e-mail, principalmente no celular, mostra só o nome. Então uma mensagem pode mostrar Equipe de Segurança da Conta enquanto o endereço por trás é outra coisa completamente diferente, sem nada falsificado. É por isso que a ferramenta mostra o par em toda mensagem, e não só nas suspeitas.
Um segundo endereço escondido no nome
Uma versão específica do mesmo truque: um endereço de e-mail escrito dentro do nome de exibição. O seu programa de e-mail mostra o nome, então você lê um endereço enquanto a mensagem veio de outro.
Caracteres que invertem o sentido da leitura
O Unicode inclui caracteres de controle que existem para que o árabe e o hebraico sejam exibidos corretamente em textos mistos. Colocados em um nome ou em um nome de arquivo, eles fazem o texto ser lido ao contrário na tela enquanto os caracteres por baixo continuam iguais — é assim que um arquivo chamado .exe pode parecer terminar em .jpg. Esta ferramenta nunca os aplica: ela os mostra como rótulos visíveis, como <U+202E>, para você ver onde eles estão.
Caracteres invisíveis
Caracteres que não ocupam espaço nenhum, colocados dentro de um nome ou de um endereço. Eles fazem um nome visualmente idêntico a um conhecido deixar de corresponder a ele, o que burla filtros e regras de e-mail que procuram o texto simples.
Domínios parecidos
Esta verificação e a estrutura dos links são as que têm mais peso aqui, porque, ao contrário da autenticação, são difíceis de um atacante satisfazer honestamente.
Misturar alfabetos dentro de um mesmo nome
Nomes de domínio podem conter caracteres da maioria dos sistemas de escrita do mundo, e várias letras são desenhadas de forma idêntica entre eles — o a latino e o а cirílico, o o latino e o ômicron grego. Trocar uma pela outra em um nome que, fora isso, é comum produz um domínio visualmente idêntico e tecnicamente diferente, disponível para registro porque ninguém mais o tem.
Misturar sistemas de escrita não é suspeito por si só, e esta ferramenta não trata isso assim. O japonês mistura três sistemas de escrita em palavras comuns; domínios japoneses, coreanos e chineses são normais. A verificação usa as regras do Unicode sobre quais combinações de fato ocorrem juntas e sinaliza as que não ocorrem — latino com cirílico ou grego dentro de um mesmo rótulo.
Punycode não é sinal de alerta
Domínios não ASCII são transmitidos em uma forma codificada que começa com xn--. É assim que todo domínio legítimo japonês, coreano, chinês e russo é escrito na rede. Ver isso não significa nada sozinho, e esta ferramenta nunca sinaliza isso como suspeito. O que ela faz é mostrar a forma decodificada e a codificada lado a lado, para que, se caracteres tiverem sido trocados, a diferença fique visível, e não apenas presente.
A um ou dois caracteres de um domínio real
Uma letra trocada, acrescentada ou removida. rn no lugar de m; um zero no lugar da letra o. São difíceis de distinguir no tamanho de leitura e fáceis de registrar. Esta comparação precisa de uma lista de domínios reais de marcas para comparar, então ela só cobre as marcas dessa lista — veja a página de limitações.
Extensões de domínio que aparecem de forma desproporcional em abusos
Algumas extensões são baratas e pouco controladas, e aparecem no phishing com muito mais frequência do que no e-mail comum. Muitos sites legítimos também as usam, então isso compõe um quadro e não decide nada sozinho.
A lista é curta de propósito, e a ausência de uma extensão nela não significa nada. Ela só inclui extensões para as quais podemos apontar uma fonte publicada, medidas em mais de uma fonte e em mais de um período. São poucas: 3 na versão atual. Muito mais extensões são usadas em phishing do que as que aparecem nela, e a maior parte do phishing usa, de qualquer forma, extensões comuns como .com. Leia um resultado que não diz nada sobre a extensão do domínio como a ferramenta não tendo comentário a fazer, e não como uma aprovação.
Links
O texto diz uma coisa e o link leva a outra
Em uma mensagem HTML, o texto que você vê e o endereço para onde você iria são separados. Fazer os dois discordarem é o sinal de phishing mais confiável que existe, e ele fica invisível a menos que você passe o mouse sobre o link ou leia o código-fonte. A ferramenta mostra os dois, um sobre o outro, para que a comparação seja uma olhada para baixo.
Nenhum link nesta ferramenta é clicável. Os endereços são mostrados como texto inerte que você pode copiar. Colocar um link de phishing ativo dentro de um analisador de phishing seria indefensável.
Um @ antes do destino real
Tudo o que vem antes de um @ em um endereço web é ignorado pelo navegador. https://www.bank.example.jp@evil.example/ leva a evil.example. A parte conhecida está ali para fazer o link começar de forma convincente.
Links que carregam instruções em vez de um endereço
Alguns esquemas de link não levam a página nenhuma: eles carregam código para o navegador executar, ou um documento inteiro codificado dentro do link. E-mails comuns não contêm isso.
Um endereço numérico em vez de um nome
Um destino sem nome de domínio por trás. Organizações colocam o próprio nome nos seus sites, e um endereço puro não pode ser comparado com nada.
Redirecionamentos e parâmetros codificados
Um link que carrega um segundo endereço dentro dele e manda você adiante: a parte que você leria pertence a um site, e o lugar aonde você chega é escolhido por quem escreveu o link. Trechos codificados na string de consulta são comuns em links de rastreamento normais e também são o jeito de esconder um endereço ou uma instrução de uma olhada rápida — isso é informado, não acusado.
Links reescritos por um produto de segurança
Provedores de e-mail e serviços de filtragem substituem os links por links próprios para que os cliques passem por eles. Quando o endereço original está codificado dentro do novo, esta ferramenta o decodifica e mostra o destino real — julgue esse destino, não o invólucro. Quando o serviço guarda o original nos próprios servidores e deixa só uma referência, não há nada para decodificar, e a ferramenta diz isso em vez de adivinhar.
Uma carga hospedada em um serviço em que todos confiam
Qualquer pessoa pode colocar uma página em um serviço conhecido de documentos ou de armazenamento e pegar emprestada a reputação dele. O provedor de hospedagem nunca é um sinal por si só — um link para um serviço legítimo em uma mensagem legítima é um link para um serviço legítimo. Isso só é sinalizado quando a mensagem também parece estar se passando por alguém, e mesmo assim é um sinal moderado.
Isso se limita às marcas da lista. Decidir que uma mensagem se passa por uma marca exige essa lista, então esta verificação só pode ser sinalizada para uma marca que a lista traz — são 52. Uma mensagem que se passa por uma marca que não está na lista, hospedada nesse mesmo serviço, não é sinalizada aqui de forma alguma. Veja o que esta ferramenta não consegue detectar.
Codificação do texto
A codificação declarada não corresponde ao conteúdo
Uma mensagem diz como o texto dela deve ser lido. Quando esse rótulo discorda dos bytes reais, tudo continua sendo exibido — e é essa a questão. Um filtro que lê a mensagem como o rótulo diz vê um texto diferente do que você vê, e uma mensagem pode ser construída para que a versão que o filtro lê seja inofensiva.
Uma codificação obsoleta
Uma codificação em particular foi retirada dos padrões da web e não é mais decodificada pelos navegadores. Ela sobrevive quase só como uma forma de escrever texto que os filtros de segurança não decodificam.
Caracteres que imitam letras comuns
Formas de caracteres matemáticas, circuladas e decoradas se leem como palavras normais para uma pessoa e por baixo são outros caracteres — é assim que uma palavra passa por um filtro que procura a grafia simples.
A gravidade, e por que não há pontuação
Os achados têm uma de quatro gravidades — Malicioso, Suspeito, Informativo ou Sem ocorrências — e cada uma é atribuída pela regra que a produziu, e não calculada. A manchete é o achado mais grave presente.
Não existe pontuação numérica, e ela não está sendo escondida. Ela não existe. Um número sugeriria uma precisão que esta análise não tem e convidaria a um limite — “abaixo de 30 está tudo bem” —, que é exatamente o raciocínio que faz as pessoas caírem no phishing com a mensagem que tirou 28. Quatro gravidades com nome e uma frase que você pode repetir para um colega são mais honestas sobre o que realmente se sabe.
Nada nunca fica verde, e nenhum resultado diz que uma mensagem é segura. Um resultado limpo significa que as verificações que foram executadas não encontraram nada de alto risco; a nota de cobertura em cada resultado diz quais foram executadas.
Uma aproximação declarada: o domínio registrado
O alinhamento depende de saber onde termina um domínio registrado — example.co.jp é um, co.jp não é. O padrão DMARC atual determina isso com uma sequência de consultas DNS em tempo real.
Esta ferramenta não faz solicitações de rede de nenhum tipo, então não consegue fazer essas consultas. Ela usa a Public Suffix List no lugar — uma lista mantida de extensões de domínio sob as quais as pessoas registram nomes — e deduz o domínio registrado a partir dela.
As duas abordagens costumam concordar. Quando divergem, o resultado de alinhamento mostrado aqui pode ser mais rigoroso ou mais permissivo do que o que um servidor de e-mail destinatário calcularia. Isso é uma aproximação, e é informado em todo resultado que depende dela, em vez de ficar para você descobrir. É uma troca deliberada: a alternativa é uma ferramenta que envia os domínios da sua mensagem para um resolvedor DNS, e aí “a sua mensagem nunca sai do seu computador” deixaria de ser verdade.