A autenticação pode ser bem-sucedida para a organização errada
Um invasor não precisa se passar pelo domínio exato de uma organização confiável para enviar uma mensagem enganosa. Eles podem operar um domínio diferente, configurar seu e-mail corretamente e usá-lo para fazer afirmações enganosas. Um receptor pode observar sucesso SPF, DKIM e DMARC para esse domínio enquanto a mensagem ainda tenta fraude. O resultado da autenticação descreve o uso do domínio; não estabelece que o domínio pertence à organização que o leitor tem em mente ou que a ação solicitada é legítima.
RFC 9989 limita explicitamente os objetivos do DMARC . A análise de conteúdo e a autenticação de entidades que não sejam domínios estão fora do seu escopo, assim como os ataques de nomes de exibição. Este limite explica autenticado phishing sem sugerir que a autenticação falhou tecnicamente. A resposta apropriada combina identidade de domínio, contexto de mensagem e verificação comercial independente. Este artigo é uma orientação defensiva e não contém nenhum modelo de phishing, instruções de entrega ou teste de domínio ativo.
Distinguir autenticação de afiliação
Anote o domínio no endereço De real e o domínio que o destinatário esperava. Se forem diferentes, não os recolha porque o nome de exibição, o logotipo ou o assunto parecem familiares. O proprietário de um domínio geralmente pode providenciar a autenticação para seu próprio e-mail, mas isso não diz nada sobre seu relacionamento com outra empresa. Mesmo um site real e um endereço de resposta funcional não estabelecem essa relação. A questão é afiliação e autoridade, não apenas consistência técnica.
RFC 5322, seção 3.4, separa o nome de exibição do endereço. Um rótulo familiar pode ficar acima de um domínio não relacionado em um cliente de email. O rótulo pode ser benigno, ambíguo ou enganoso dependendo do contexto; não declare a intenção apenas pelo rótulo. Compare o endereço com um registro organizacional confiável e verifique a ação comercial específica por meio de um canal estabelecido fora da mensagem questionável.
Inspecione o significado de um resultado aprovado
Um passe SPF independente pode dizer respeito ao remetente do envelope domínio, enquanto DKIM identifica um domínio de assinatura. DMARC adiciona um alinhamento relacionamento com o domínio De visível. Identifique qual caminho suporta o resultado relatado. Se todas essas identidades pertencerem ao domínio desconhecido, o resultado poderá ser internamente consistente sem validar a marca familiar ou o indivíduo nomeado na mensagem. Esta é uma descoberta importante e não uma contradição a ser explicada.
Use evidências de destinatário confiável em vez de aceitar uma afirmação fornecida pelo remetente. RFC 8601 descreve por que Authentication-Results os consumidores precisam de um limite de confiança. Uma captura de tela contendo a palavra pass pode não revelar quem avaliou a mensagem ou qual domínio passou. Registre a origem, a hora e os campos de identidade relevantes. Quando as evidências forem insuficientes, preserve a incerteza em vez de afirmar que a mensagem foi aprovada ou falhou definitivamente.
Avalie a ação solicitada separadamente
Identifique o que o remetente deseja que o destinatário faça. O risco pode ser a alteração do destino do pagamento, a divulgação de informações confidenciais, a instalação de software, o login em um local desconhecido ou a alteração de um fluxo de trabalho estabelecido. A autenticação de domínio não aprova nenhuma dessas ações. Uma mensagem tecnicamente válida ainda pode conter uma premissa falsa, uma solicitação não autorizada ou um destino não relacionado ao negócio reivindicado.
Não inspecione um link suspeito fazendo login ou inserindo informações. Utilize o processo de análise e elaboração de relatórios estabelecido pela organização, com pessoal qualificado e ferramentas apropriadas quando for necessária uma inspeção mais profunda. Este rascunho não afirma que a inspeção visual de uma URL possa provar segurança, nem que todo domínio desconhecido seja malicioso. Um novo fornecedor legítimo e um domínio de propriedade do invasor podem não ser familiares; a verificação do negócio é o que resolve o relacionamento.
Use as defesas do receptor sem exagerá-las
Visão geral da autenticação de e-mail da Microsoft descreve a autenticação composta como parte de uma avaliação mais ampla, em vez de uma simples substituição de SPF , DKIM e DMARC . Isto apoia uma abordagem em camadas: os sistemas receptores podem combinar sinais de identidade com outras informações ao decidir como lidar com a correspondência. Ele não garante a detecção de todas as mensagens de phishing autenticadas nem define o comportamento de filtragem atual de outro provedor.
Um destinatário pode aceitar, colocar em quarentena, descartar ou rejeitar mensagens de acordo com seus próprios controles e políticas. Não deduza a segurança do posicionamento na caixa de entrada ou a maldade de um único resultado de filtragem. Da mesma forma, um público lista de bloqueio O resultado não é um veredicto de reputação universal. Use o diagnóstico do provedor como evidência com escopo e tempo conhecidos. Preservar a distinção entre a classificação de uma máquina e a autoridade do proprietário da empresa para aprovar a ação solicitada.
Uma planilha de afiliação e ação
Crie uma planilha com a organização reivindicada, domínio confiável esperado, domínio De real, nome de exibição, domínio ou domínios autenticados, resultado do receptor confiável e ação solicitada. Adicione a fonte de evidências para o domínio esperado, não apenas o domínio observado. Registre se a empresa tem um relacionamento estabelecido com o remetente e se a ação específica se enquadra nesse relacionamento. Mantenha uma opção não resolvida em vez de forçar cada remetente desconhecido a uma categoria de invasor.
A segunda metade da planilha registra o verificador independente, a rota de contato previamente conhecida, a pergunta feita, a resposta e o responsável pela decisão. Evite utilizar número de telefone ou endereço alternativo introduzido apenas pela mensagem suspeita. Edite informações pessoais desnecessárias na cópia compartilhada, preservando a igualdade e a diferença de domínio. Uma planilha que substitui todos os endereços pelo mesmo espaço reservado não pode demonstrar por que a autenticação falhou ao estabelecer a afiliação.
Diagnóstico fictício: um novo domínio autenticado corretamente
Imagine que uma equipe de operações fictícia recebe uma solicitação que afirma vir de um fornecedor de equipamentos conhecido. O remetente usa um domínio diferente que não está no registro de fornecedor aprovado da equipe. A evidência do receptor confiável mostra hipoteticamente DKIM alinhado e uma passagem DMARC para esse domínio diferente. O destinatário vê um nome de exibição familiar e assume que o resultado da autenticação confirma a identidade do fornecedor. Não: a observação diz respeito ao domínio diferente.
A resposta proposta é pausar a alteração solicitada e verificá-la junto ao fornecedor através de contato previamente estabelecido. Se o fornecedor negar a solicitação, a organização poderá encaminhar as evidências por meio do processo de incidente aprovado sem adicionar o domínio desconhecido a uma lista de permissões. Se o fornecedor confirmar uma alteração legítima de domínio, essa confirmação deverá entrar no fluxo de trabalho normal de manutenção do fornecedor, em vez de alterar silenciosamente a confiança com base em um e-mail. Nenhum fornecedor real, registro de domínio, entrega de mensagem ou chamada de verificação foi envolvido neste exemplo fictício.
Preservar controles úteis e exigir evidências originais
O Assessoria IC3 BEC, publicado em 2020, apoia a verificação independente de solicitações comerciais incomuns e proteções de contas. É citado por esses princípios defensivos, não por uma estatística de ataque atual ou por uma afirmação sobre uma organização nomeada. A autenticação, as proteções do receptor e os controles dos processos de negócios devem reforçar-se mutuamente. Não remova a autenticação porque ela não pode determinar a intenção e não conceda confiança apenas porque ela é aprovada.
O catálogo exige um cenário de abuso redigido com evidências de identidade, limite de controle e verificação comercial independente. Essa evidência original permanece aberta; o cenário fictício não é um substituto. Nenhum endpoint suspeito foi visitado, nenhuma credencial foi coletada e nenhum terceiro foi contatado. A revisão por especialistas humanos, a aplicabilidade da fonte atual, as rotas de produção, a acessibilidade visual e a liberação do proprietário também permanecem em aberto. Uma versão publicável precisa de evidências autorizadas que demonstrem a distinção exata entre autenticar um domínio e confiar na organização ou ação que afirma representar.