O e-mail é um dos pontos de entrada mais comuns para ataques cibernéticos e as proteções integradas já não são suficientes para lidar com ameaças direcionadas. Testamos três plataformas de segurança de e-mail na nuvem (Acronis, Sophos e Barracuda) com 100 testes em 11 categorias de ameaças.
Resultados do benchmark de soluções de segurança de e-mail na nuvem
Leia a metodologia do benchmark de soluções de segurança de e-mail para saber como testamos essas ferramentas e medimos os resultados.
Comparação de soluções de segurança de e-mail com base em categorias de veredito
Acronis Advanced Email Security
- Acronis tem a maior pontuação geral de deteção (122/200) e tem o melhor desempenho contra phishing GenAI com 100%. Todos os dez pretextos de negócios elaborados foram bloqueados, incluindo pré-leituras falsas do conselho, fluxos de re-consentimento do Microsoft 365 e NDAs legais fictícios.
- Esta é a categoria mais difícil no benchmark, com uma dificuldade média de 8.2/10. Detetar todos os dez sugere que o Acronis lidou bem com pistas de phishing semânticas e contextuais neste benchmark, em vez de depender de sinais óbvios de gramática ou formatação.
- A Categoria F e a Categoria D também apoiam este cenário: Acronis pontuou 89% em personificação de marca/domínio e 90% em phishing de URL, incluindo um BLOQUEIO no teste de injeção de cabeçalho de resultados de autenticação. Os resultados agregados sugerem um forte tratamento de casos de personificação e análise de URL.
- O registo limpo de falsos positivos é operacionalmente significativo. Nenhuma das oito mensagens de controlo foi bloqueada, o que significa que a taxa de deteção de 67% não tem custo compensatório em perda de correio legítimo.
- Os pontos negativos concentram-se em níveis de dificuldade mais baixos. Spam básico (Categoria A, 44%) é inferior a outras ferramentas, com falhas em spam farmacêutico, esquemas de lotaria e um esquema básico de romance nos níveis de dificuldade 1 a 2. A lacuna sugere que o Acronis prioriza ataques sofisticados em vez de tráfego em massa e de baixo esforço.
Sophos Email Security
- Sophos tem a segunda maior pontuação geral (105.5/200). Alcançou 100% na Categoria B (variantes de malware EICAR), detetando todas as variantes de aninhamento de arquivo, ZIP protegido por palavra-passe e teste de tolerância de deslocamento.
- Os pontos fracos mais visíveis do Sophos são phishing de URL (Categoria D, 58%) e técnicas de evasão (Categoria J, 22%). A lacuna no phishing de URL é notável porque os links estão entre os mecanismos de entrega de phishing mais comuns, e a Categoria D testa várias formas realistas de os atacantes os ocultarem ou encaminharem.
- A pontuação de 58% do Sophos, comparada com os 90% do Acronis, sugere que a sua camada de análise de URL foi menos consistente em redirecionamentos, ofuscação e colocações de URL fora do corpo.
Barracuda Email Protection
- A pontuação de deteção de 60/200 do Barracuda é inferior à dos outros dois produtos. A Categoria I (phishing GenAI) obteve 0% de deteção, e a Categoria A (Spam: 33%) tem a pontuação mais baixa entre os concorrentes. Isto sugere que o Barracuda foi menos eficaz nesta configuração contra os cenários de spam, phishing GenAI e engenharia social do benchmark.
- Categoria B (deteção de malware conhecido através de strings de teste EICAR, 89%) e Categoria C (tipos de ficheiro portadores, como PDFs com JavaScript incorporado, HTML smuggling e atalhos LNK, 70%) são competitivas com outros fornecedores.
- Os resultados da Categoria J do Barracuda (técnicas de evasão, 44%) mostram o melhor dos três fornecedores. Isto sugere que o motor de inspeção de conteúdo subjacente consegue lidar razoavelmente bem com funcionalidades como caracteres de largura zero, assuntos codificados e homoglifos.
- Os pontos fracos são mais proeminentes em categorias que mais importam para a proteção moderna contra ameaças. Phishing por código QR (Categoria E, 13%), personificação de marca (Categoria F, 11%), BEC (Categoria G, 11%) e extorsão (Categoria H, 22%) estão todos bem abaixo da comparação.
- Nos onze testes de nível difícil, o Barracuda bloqueou um e falhou os restantes dez.
Top 3 soluções de segurança de e-mail na nuvem
Análise detalhada do Acronis Advanced Email Security
Quando selecionamos Acronis Email Security no menu do lado esquerdo na interface do Acronis Cyber Protect Cloud, vemos o ecrã seguinte. Em seguida, clicamos para aceder à consola de Email Security.
Como ainda não concluímos nenhuma configuração, o nosso painel exibe os itens de menu:
- Incidents: Incidentes de segurança detetados e atividade de ataque.
- Incident Response: Ferramentas para investigar e responder a incidentes.
- Traffic: Visibilidade dos padrões de tráfego de e-mail ou web analisados.
- Periodic Reports: Relatórios agendados de segurança e proteção.
- Security Operations: Controlos de segurança operacional e ferramentas de monitorização.
- Detection Setup: Configuração para regras de deteção, análise e definições de proteção.
No menu Settings à esquerda, vamos a Protected Email Assets.
Como ainda não há ativos, o sistema redireciona-nos para o fluxo de configuração. Clicamos em Configure email protection. O sistema pede-nos um endereço de e-mail de escalation para reportar problemas e pergunta qual o serviço de e-mail que usamos.
Para este teste, vamos prosseguir com um fornecedor personalizado via MX. Estamos a fazer isto para podermos comparar fornecedores diretamente, sem sermos afetados pelas proteções integradas no Microsoft 365 ou no Google Workspace.
Selecionamos o serviço de e-mail e escolhemos o método de ligação Inline. Isto significa que o Acronis analisa e bloqueia e-mails maliciosos antes de serem entregues.
Adicionamos também um contacto de escalation que o Acronis pode usar para problemas de account takeover, segurança ou ligação. O próximo passo é ativar a app Google Workspace, que suporta onboarding, contagem precisa de utilizadores para faturação e ações de remediação, como remover e-mails maliciosos entregues por engano.
Adicionamos o domínio ligado, aimultiple.com, e o sistema recupera automaticamente os registos MX.
Também definimos o método de cálculo de licenças para "According to Reported seats" e inserimos 100 lugares. Após estas definições, prosseguimos com Next para continuar a configuração MX.
O sistema pede-nos para adicionar um registo TXT para verificar a propriedade do domínio. Adicionamos o registo e aguardamos a verificação.
Também podemos gerir os servidores de destino SMTP configurados, confirmar que o TLS está ativado e usar a ação Verify para verificar se o registo TXT foi publicado corretamente. Esta página também nos permite editar as definições do servidor e TLS ou eliminar o domínio, se necessário.
Enviamos um total de 100 e-mails que poderiam ser considerados maliciosos ou spam. O painel mostra agora estatísticas como quantos e-mails foram analisados, quantos foram classificados como spam, quantos foram classificados como maliciosos e quantos e-mails foram recebidos por tipo de ataque. Há também uma estatística que mostra quais os endereços de e-mail que foram atacados com mais frequência.
No menu Scans, podemos ver as estatísticas de análise de todos os e-mails recebidos. A divisão por tipo de ficheiro também é um detalhe útil. Além disso, em toda a aplicação, podemos ajustar o intervalo de datas clicando em Last Day no topo da página.
A filtragem na secção Scans é altamente detalhada. Aqui estão algumas das opções:
- Sender address/domain/IP: Os indicadores primários para identificar remetentes maliciosos ou falsificados.
- Impersonated display name: Visa diretamente uma das técnicas de phishing mais comuns, onde o nome visível parece legítimo, mas o endereço real não.
- Reply-to address: Outro sinal de alerta importante de phishing. Quando o reply-to difere do endereço do remetente, muitas vezes sinaliza uma tentativa de redirecionar respostas para uma caixa de entrada controlada pelo atacante.
- Action (quarantined/delivered): Essencial para entender se uma ameaça foi detetada ou chegou ao destinatário.
- Subject: Para identificar campanhas de phishing que usam linhas de assunto idênticas ou quase idênticas em vários alvos.
- Receiver address: Crítico para determinar o alcance de um ataque. Mostra quantos utilizadores foram alvo e se indivíduos de alto valor (executivos, finanças) estavam entre eles.
- Payload (attachments/URLs): Restringe a pesquisa a e-mails que transportam os mecanismos de entrega de malware mais comuns.
Quando vamos a Security Operations no menu do lado esquerdo, chegamos à secção Scans. A partir deste ecrã, podemos aceder aos detalhes relacionados com as análises. Todas as análises estão listadas aqui, e também podemos ver as categorizações resultantes, como limpo, spam e malicioso.
Quando abrimos os detalhes de um e-mail, podemos ver como o sistema o avaliou e o seu estado atual. Também podemos alterar o seu estado para:
- Approve Verdict (Handle): Aceitar o veredito atual e processar o e-mail em conformidade.
- Mark email as restricted: Classificar o e-mail como restrito ou com violação de política.
- Mark email as Spam: Classificar o e-mail como indesejado ou não solicitado.
- Mark email as Suspicious: Sinalizar o e-mail como potencialmente arriscado e necessitando de cuidado.
- Mark email as Clean (FP): Marcar o e-mail como seguro e indicar que foi um falso positivo.
A vista abaixo é a vista compacta. Quando clicamos no separador Detailed no canto superior direito, podemos ver muitos detalhes adicionais.
Na vista compacta, podemos ver os detalhes da análise de um e-mail de phishing malicioso que foi colocado em quarentena pelo Acronis. Inclui uma visão geral gerada por IA explicando porque é que o e-mail é considerado malicioso e mostrando indicadores como um domínio de remetente suspeito, comportamento de email-bombing e um URL arriscado. Na secção Details, podemos verificar o canal, a ação tomada, o tempo de análise, o tempo de processamento, a organização e o estado de IR.
No Email Inspector, podemos rever os metadados da mensagem, incluindo assunto, remetente, destinatário, hora, caminho de retorno e IP de origem. O corpo do e-mail também é exibido, para que possamos avaliar a tentativa de engenharia social diretamente.
Os critérios de avaliação de incidentes são claros e transparentes. Para um incidente, também podemos clicar no botão Request investigation, selecionar "I think this email is clean" e enviá-lo para a equipa Acronis para revisão. Podemos ver análises anteriores relacionadas com o mesmo e-mail.
Com o botão Screenshots, podemos ver a versão renderizada do e-mail, o que é uma funcionalidade útil. Notavelmente, o sistema não renderiza o e-mail como HTML no navegador, pelo que qualquer vulnerabilidade não detetada no e-mail não pode desencadear uma violação durante a revisão.
Todas as ações do utilizador podem ser registadas, e podemos ver estes registos no Audit log no menu do lado esquerdo. Alguns destes registos são:
- Ver capturas de ecrã de análise
- Processar análise
- Ação de IU
Cada registo regista a data/hora, ação, descrição, administrador ou equipa, organização alvo e o e-mail ou objeto alvo relacionado.
Em Detection Setup no menu do lado esquerdo, podemos gerir listas de permissões e listas de bloqueio em detalhe, o que é uma funcionalidade altamente útil:
- Sender email address/domain allowlist: E-mails de endereços ou domínios nesta lista são sempre confiáveis e ignorarão os filtros de spam/ameaças. Isto pode ser útil para incluir na lista de permissões parceiros conhecidos ou sistemas internos que, de outra forma, poderiam desencadear falsos positivos.
- Recipient email address allowlist: Especifica endereços de destinatários internos que devem receber todo o correio de entrada sem filtragem. Isto garante que certos utilizadores (por exemplo, uma caixa de entrada catch-all) recebem sempre e-mails, mesmo de remetentes desconhecidos.
- Sender email address/domain blocklist: E-mails de endereços ou domínios nesta lista são automaticamente rejeitados ou colocados em quarentena. Pode ser usado para bloquear permanentemente fontes de spam conhecidas, domínios maliciosos ou remetentes de envios em massa indesejados.
- Sender IP allowlist: Servidores de correio com IPs nesta lista são considerados confiáveis e os seus e-mails ignoram as verificações de reputação baseadas em IP. Pode ser usado para serviços de correio de terceiros confiáveis ou relays de correio no local.
- Sender IP blocklist: As ligações destes IPs são bloqueadas, independentemente do endereço do remetente. Isto pode ser eficaz contra servidores de correio maliciosos conhecidos ou infraestrutura comprometida.
- URL allowlist: Links que correspondem a estes URLs ou domínios nos corpos dos e-mails são considerados seguros e não serão sinalizados.
- URL blocklist: E-mails que contenham estes URLs são sinalizados, bloqueados ou colocados em quarentena.
- Hash allowlist: Anexos de ficheiros que correspondam a estes hashes criptográficos são tratados como seguros e passam sem alertas de análise.
- Hash blocklist: Anexos cujo hash corresponda a uma entrada nesta lista são bloqueados imediatamente. Isto fornece um bloqueio preciso, baseado em assinaturas, de ficheiros maliciosos conhecidos, mesmo que sejam renomeados ou disfarçados.
Algumas das funcionalidades que vale a pena mencionar, mas que não testamos especificamente, são:
Em detection setup:
- Threat intelligence: Obtém indicadores de fontes externas de threat intelligence. Esta funcionalidade ajuda a detetar malware comum generalizado, URLs maliciosos e campanhas de ataque ativas.
- Banners: Adiciona banners personalizáveis a e-mails recebidos com base em políticas e regras.
- VIP Users: Permite que os administradores mantenham uma lista de utilizadores de alto valor (executivos, pessoal financeiro, etc.).
Em security operations:
Account Takeover (ATO): Deteta caixas de correio Microsoft 365 comprometidas. A funcionalidade foi projetada para apanhar atacantes que usam contas sequestradas para fraude, phishing interno e exfiltração de dados.
O motor sinaliza regras de caixa de correio suspeitas (encaminhamento, redirecionamento, movimentação ou eliminação de e-mails), logins de viagem impossível e inícios de sessão de locais ou dispositivos não familiares. Quando deteta um destes sinais, abre um caso na consola e a equipa de resposta a incidentes contacta o administrador para investigar em conjunto.
Análise detalhada do Sophos Email Security
Para começar com o Sophos, criamos um link de avaliação e somos direcionados para o ecrã seguinte. À semelhança do Barracuda, o Sophos pede-nos para selecionar uma região.
O sistema pergunta-nos então qual o produto que queremos instalar. Selecionamos Email Security. Outros produtos que podem ser configurados incluem Endpoint Protection, Server Protection, Phish Threat, DNS Protection, Zero Trust Network Access, Protected Browser, Mobile, Wireless, Device Encryption, Firewall Management, Cloud Optix e Switches.
Enviaremos 100 e-mails, e a imagem abaixo mostra o painel. Inclui estatísticas como o número total de e-mails de entrada analisados, ameaças potenciais e tipos de ameaças detetados. Também existem estatísticas para e-mails de saída, mas não estamos a testar a segurança de e-mail de saída neste benchmark.
Também podemos ver outros elementos do painel, como tendências de atividade de e-mail, resumos de ameaças e indicadores de estado de segurança.
Clicamos em Set up email gateway settings. O sistema pede-nos para verificar o nosso domínio. Depois observamos uma definição útil na qual podemos escolher apenas entrada ou entrada e saída. Também verifica e-mails de saída para evitar problemas de segurança.
O sistema mostra o registo DNS que precisamos de inserir. Em seguida, adicionamo-lo e prosseguimos.
Adicionamos o registo TXT ao DNS público do domínio. O valor TXT é um token de verificação de domínio Sophos, e o TTL está definido para 600. Depois de adicionar o registo DNS, aguardamos a propagação e clicamos em Verify para que o Sophos possa confirmar que somos os proprietários do domínio.
Adicionamos o registo e verificamos o nosso domínio. Para o destino de entrada, selecionamos MX e inserimos o registo MX do Google Workspace: aspmx.l.google.com.
Tal como o Barracuda, o Sophos requer encaminhamento MX. Ao contrário do Sophos e do Barracuda, o Acronis tratou este processo de forma limpa através de uma API, e não precisamos de alterar nenhuma definição. Estes tipos de alterações de configuração MX ou semelhantes podem causar problemas aos administradores de sistema. No entanto, para fins de teste, prosseguimos para o passo seguinte.
Concluímos as definições MX e enviamos um e-mail de teste, mas ele não passou. Após alguma investigação, vimos que o erro era: "This email address was not found", o que foi inesperado.
Precisamos de ir ao painel, abrir a secção Mailboxes no menu esquerdo e adicionar manualmente os utilizadores um a um. Este é um problema de usabilidade que prejudica a experiência geral, pois tanto o Acronis como o Barracuda funcionaram imediatamente. Para o teste, adicionamos o nosso próprio endereço de e-mail e continuamos os testes através dessa conta.
A secção de relatórios está no menu do lado esquerdo. Aqui estão alguns dos relatórios que podemos criar:
- Message summary: Volume geral e estado do e-mail.
- SophosLabs analysis report: Vereditos de mensagens reportados por utilizador/admin.
- Intelix threat summary: Análise de ameaças para e-mails de entrada.
- Time of click summary: Relatório de atividade de clique em link.
- At-risk users: Funcionários mais vulneráveis.
- Data control summary: Correspondências de política de perda de dados.
- Post delivery summary: E-mails removidos após a entrega.
- License usage summary: Uso de licença de segurança de e-mail.
Quando vamos a Email Security > Message History, podemos ver todos os e-mails recebidos e como cada um foi classificado. Este relatório de Message History lista e-mails individuais processados pelo Sophos Email Security. Alguns campos-chave são:
- Sender: De quem o e-mail parecia ser.
- Recipients: Quem recebeu a mensagem.
- Type: Como o e-mail entrou no sistema, geralmente Gateway.
- Subject: A linha de assunto do e-mail.
- Last Status: O que o Sophos fez com ele, como Delivered, Deleted ou Quarantined.
- Date: Quando o e-mail foi processado.
- Category: Classificação do Sophos, como Legitimate, Spam, Malware, Intelix threat ou Authentication.
Alguns exemplos das categorias são:
- Legitimate: E-mails normais que foram permitidos.
- Spam: E-mails suspeitos ou indesejados; muitos são colocados em quarentena.
- Malware: E-mails perigosos contendo conteúdo malicioso; estes são eliminados.
- Intelix threat: E-mails analisados pelo Sophos Intelix que foram considerados suspeitos ou ameaçadores.
- Quarantined: O e-mail foi bloqueado e colocado em quarentena para revisão.
- Deleted: O e-mail foi removido em vez de entregue.
Os filtros abaixo permitem aos utilizadores restringir o registo de e-mail por categoria de mensagem:
- Legitimate: E-mails normais permitidos.
- Secure message: E-mails encriptados ou protegidos.
- Data control: E-mails que correspondem a regras de perda de dados/segurança.
- Authentication failure: Verificações SPF, DKIM ou DMARC falhadas.
- Impersonation: Possível falsificação de remetente ou fraude de identidade.
- Bulk: Marketing em massa ou e-mails automatizados.
- Spam: E-mails indesejados ou suspeitos.
- URL/QR Code: E-mails com links arriscados ou códigos QR.
- Intelix threat: E-mails sinalizados pela análise de ameaças do Sophos.
- Unscannable: E-mails que o Sophos não conseguiu inspecionar totalmente.
- Malware: E-mails contendo ficheiros ou conteúdo malicioso.
- Enterprise blocked: E-mails bloqueados por política da empresa.
O menu Mailboxes mostra as caixas de correio a serem monitorizadas. Ao abrir uma caixa de correio, podemos selecionar quais as políticas a aplicar. Em Base Policy – Email Security, as seguintes definições estão disponíveis:
Authentication inclui verificações de autenticação de e-mail para mensagens de entrada. Podemos configurar como o Sophos lida com falhas de DMARC, SPF e DKIM, incluindo ações como conformidade com a política do remetente ou marcação da linha de assunto com um aviso.
Também inclui verificações de remetente para anomalias de cabeçalho e anomalias de domínio, que ajudam a detetar e-mails que parecem vir do seu próprio domínio ou de domínios suspeitos sem registos DNS adequados. Também podemos ativar banners de utilizador final para mostrar aos destinatários o nível de confiança das mensagens de entrada e ajudar-nos a decidir se devemos permitir ou bloquear remetentes.
Anti-malware gere a análise anti-malware de entrada para mensagens de e-mail. Podemos escolher a ação padrão para deteções de malware, como Delete, e ativar a análise aprimorada de malware para uma análise mais profunda de conteúdo e ficheiros.
Também permite o controlo sobre e-mails não analisados e Intelix Threat Analysis, onde o Sophos pode usar análise estática e dinâmica para classificar mensagens suspeitas. Com base no veredito, podemos definir ações como eliminar, entregar ou lidar com e-mails maliciosos e suspeitos de forma diferente.
Anti-spam gere como o Sophos lida com spam e e-mail em massa. Podemos definir ações para categorias como Confirmed Spam e Bulk, incluindo colocar mensagens em quarentena e decidir se aparecem na quarentena do utilizador final.
Também inclui um controlo deslizante personalizável de taxa de captura de spam, onde níveis mais altos aumentam a agressividade da deteção de spam.
New domain/sender inclui proteções para domínios recentemente registados e novos remetentes. Podemos ativar verificações para e-mails enviados de domínios criados recentemente, que são frequentemente usados em campanhas de phishing.
Também permite que um banner New Sender seja mostrado quando um destinatário não recebeu e-mails desse remetente antes.
O país de origem permite controlar e-mails com base no país do remetente. Países específicos podem ser selecionados de uma lista, e os e-mails correspondentes podem ser colocados em quarentena ou tratados de outra forma de acordo com a política.
Também existe uma opção para verificar cada salto de mensagem, o que ajuda a inspecionar a rota que um e-mail percorreu antes de chegar ao destinatário.
Language gere a filtragem por idioma da mensagem. Podemos selecionar idiomas específicos que queremos não permitir e escolher a ação que o Sophos deve tomar, como colocar em quarentena as mensagens correspondentes.
A funcionalidade de proteção contra personificação permite verificações de tentativas de personificação de VIP, marca e geral.
Para proteção de URL e código QR, podemos verificar e-mails em busca de URLs maliciosos e códigos QR. O Sophos pode analisar links e extrair URLs de códigos QR para detetar ameaças antes que os utilizadores interajam com eles.
Também gere o Time of Click URL Protection, onde os links são reescritos e verificados quando o utilizador clica neles.
No menu do lado esquerdo, a secção Quarantined Messages mostra todos os e-mails nos quais uma ameaça foi detetada. Podemos filtrar por:
- Anti-malware: E-mails sinalizados durante a análise de malware. Isto inclui mensagens com anexos perigosos, conteúdo malicioso ou itens que o Sophos não conseguiu inspecionar totalmente:
- Malware: E-mails confirmados como contendo ficheiros, links ou conteúdo malicioso. Estes são geralmente eliminados ou colocados em quarentena.
- Unscannable: E-mails que o Sophos não conseguiu inspecionar adequadamente, por exemplo, devido a encriptação, corrupção, anexos protegidos por palavra-passe ou tipos de ficheiro não suportados.
- Anti-spam: E-mails classificados através de regras de deteção de spam:
- Bulk: E-mails enviados em massa, como boletins informativos, campanhas de marketing ou notificações automatizadas.
- Confirmed Spam: E-mails identificados com confiança como spam. Estes são normalmente colocados em quarentena ou bloqueados.
- Suspected Spam: E-mails que parecem suspeitos, mas não são spam confirmado. Podem ser colocados em quarentena, marcados ou entregues dependendo da política.
- Impersonation: E-mails que podem estar a fingir ser de uma pessoa, marca, domínio ou remetente interno confiável.
- Disallowed Country: E-mails bloqueados ou em quarentena porque são originários de um país restrito por política.
- Disallowed Language: E-mails bloqueados ou em quarentena porque o seu idioma detetado não é permitido por política.
- BATV: E-mails relacionados com Bounce Address Tag Validation, usado para ajudar a detetar mensagens de bounce falsificadas ou spam de backscatter.
- New domain/NRD: E-mails de domínios recentemente registados, que são frequentemente usados em phishing ou campanhas de ataque de curta duração.
- Authentication: E-mails filtrados com base em verificações de autenticação do remetente, como falhas de SPF, DKIM ou DMARC.
Quando clicamos num e-mail, podemos ver as mensagens que explicam porque foi colocado em quarentena. Podemos eliminá-lo e bloquear o remetente, libertar a mensagem da quarentena ou libertá-la e permitir mensagens semelhantes no futuro.
Na secção Raw Header, podemos ver todas as informações de cabeçalho do e-mail. Também podemos ver os seus anexos e os URLs contidos na mensagem. Isto não nos pareceu suficientemente detalhado na nossa avaliação. O Acronis e o Barracuda proporcionaram uma experiência mais abrangente e informativa a este respeito.
No separador Message, podemos ver o conteúdo e-mail como está, o que pode ser inseguro. Seria melhor se pudéssemos ver o conteúdo e-mail como uma captura de ecrã, como observamos no Acronis.
Há 23 e-mails aqui porque estes foram marcados como spam, enquanto alguns outros foram diretamente rejeitados. Em resumo, o sistema coloca em quarentena os e-mails marcados como spam.
Quando queremos exportar todos os e-mails recebidos, não o podemos fazer diretamente a partir dos ecrãs de relatório. Precisamos de criar um relatório personalizado a partir de Email Logs, depois abri-lo, selecionar Generate Report, escolher CSV e, finalmente, exportar tudo como um CSV. Este fluxo de trabalho parece desnecessariamente indireto e pouco amigável.
Análise detalhada do Barracuda Email Protection
Depois de obter uma avaliação do Barracuda, navegamos para o painel, clicamos em Open para Email Protection e prosseguimos.
Em Available in your trial, podemos ver os principais produtos incluídos:
- Email protection: Previne ameaças de e-mail, protege o e-mail antes e depois da entrega e automatiza a resposta a incidentes de e-mail.
- Cloud-to-cloud backup: Faz backup dos dados do Microsoft 365.
- Data inspector: Encontra dados confidenciais e malware não detetado no OneDrive e SharePoint.
- Security awareness training: Treina os funcionários sobre ameaças à segurança de e-mail.
- Cloud archiving service: Impõe a retenção de e-mail para conformidade e e-discovery.
Como ainda não tínhamos configurado nenhum domínio ou definições relacionadas, o sistema levou-nos diretamente para o assistente de configuração, o que é uma funcionalidade útil para configurar definições de e-mail.
Quando clicamos em Next, o sistema obrigou-nos a ligar uma conta Microsoft 365. No entanto, usamos o Google Workspace e estamos a avaliar o serviço para esse ambiente.
Mais tarde, descobrimos que o Barracuda suporta o Google Workspace. Continuamos com a configuração padrão.
O sistema pediu-nos para selecionar uma região de dados. Esta é uma funcionalidade importante para a conformidade com o RGPD, por isso selecionamos a Alemanha e continuamos.
O Barracuda pediu-nos depois para inserir um endereço de e-mail pertencente ao nosso domínio e verificar os nossos registos MX. Clicamos no botão de verificação e não realizamos nenhuma ação adicional. O sistema verificou os registos com sucesso.
Durante as fases posteriores da nossa configuração, descobrimos que o Barracuda não tinha uma integração nativa com o Google Workspace. Em vez disso, deu-nos novos registos MX para substituir os existentes. Quando atualizamos estes registos MX, os e-mails recebidos parecem chegar primeiro ao Barracuda.
O Barracuda filtra então os e-mails inadequados e encaminha os aceitáveis. Exigir alterações de registo MX para integração com o Google Workspace é uma abordagem fraca.
Depois disso, atualizamos os registos MX e verificamo-los. Concluímos a configuração e começamos a enviar e-mails.
Ao enviar os e-mails, observamos que o Barracuda rejeitou alguns pedidos SMTP e recusou alguns anexos. Quando realizamos o mesmo teste com o Acronis, todos os e-mails foram entregues e visíveis no sistema. Aqui, o Barracuda rejeita alguns e-mails antes de aparecerem no painel.
Embora os rejeite porque são genuinamente maliciosos, perdemos visibilidade como resultado deste processo automatizado. Por outras palavras, podemos nem saber se um ataque chegou e foi rejeitado. Isto é um desafio para usar o Barracuda para segurança de e-mail, pois a visibilidade é tudo em contextos de segurança. Se um produto rejeita arbitrariamente incidentes e os torna invisíveis, isso prejudica a equipa de segurança.
Apesar destes desafios, todos os e-mails de teste foram enviados. No painel do Barracuda, somos direcionados para o ecrã Message Log, onde todos os e-mails analisados estão listados.
A secção Message Log inclui uma área de filtragem no topo. Aqui estão as opções de filtragem:
- Search: Pesquisa de texto em mensagens, destinatários, remetentes e outros campos.
- Domains: Filtra os resultados pelo domínio selecionado.
- Direction: Filtra por direção do e-mail; Inbound ou Outbound.
- Date/time range: Limita os resultados a uma janela de tempo específica.
- Action taken: Filtra pela ação tomada, por exemplo, Allowed, Blocked, Deferred.
- Delivery status: Filtra se o e-mail foi entregue, falhou, colocado em quarentena, etc.
- Reason: Filtra pelo motivo de deteção que desencadeou uma ação (por exemplo, Score, DMARC, Antivirus, Content Protected).
- Results: Controla quantos registos são exibidos por página.
Podemos reportá-lo como classificado incorretamente. Por exemplo, o e-mail abaixo é seguro, mas classificado incorretamente como prejudicial. Reportamos o e-mail como seguro.
O e-mail abaixo está bloqueado, mas o painel não fornece detalhes adicionais. Portanto, o Barracuda fica aquém nesta área. Seria mais útil se pudéssemos ver mais informações sobre o motivo pelo qual a mensagem está bloqueada, além da pontuação de bloqueio.
Na secção Domains à esquerda, podemos ver, adicionar e eliminar os domínios que queremos incluir na proteção de correio, que são funções padrão.
Dentro do menu Inbound à esquerda, o Barracuda fornece os filtros usados para estes controlos. Podemos configurar estes filtros.
Por exemplo, em Anti-Spam/antivirus settings, podemos configurar:
- Use Barracuda reputation block list: Verifica o correio de entrada em relação à base de dados do Barracuda de remetentes maliciosos conhecidos. Pode ser definido como Block, Quarantine ou Off.
- Scan email for viruses: Ativa ou desativa a verificação de vírus em todos os e-mails recebidos.
- Use Barracuda real-time system: Cruza e-mails com o feed de inteligência de ameaças ao vivo do Barracuda. Pode ser bloqueado, colocado em quarentena ou desligado. Opcionalmente, envia conteúdo suspeito para o Barracuda Central para análise posterior.
- Enable cloudscan: Descarrega a pontuação de spam para o motor de nuvem do Barracuda. As pontuações variam de 1 a 10; e-mails que excedam o limite desencadeiam a ação configurada.
- Email categorization: Classifica os e-mails recebidos por tipo e aplica uma ação por categoria. As categorias incluem Corporate Email, Transactional Email, Marketing Materials and Newsletters, Mailing Lists e Social Media, cada uma definida independentemente para Allow, Quarantine, Block ou Off.
- Bulk email detection: Deteta e atua sobre e-mails em massa/enviados em massa. Quando está definido como Off, os e-mails em massa não são filtrados separadamente.
- Bulk email exemptions: Permite que endereços de e-mail ou domínios específicos ignorem a deteção de e-mail em massa, definidos por remetente ou destinatário.
As páginas Rate Limit definem quantos e-mails um endereço IP de remetente pode enviar em cada período de 30 minutos, o que é uma definição útil. Pode prevenir abuso de e-mail e ataques súbitos de alto volume de um único IP de remetente.
Ao limitar quantos e-mails um endereço IP pode enviar num período de 30 minutos, o sistema pode reduzir o impacto de:
- Campanhas de spam
- Rajadas de phishing
- Distribuição de malware
- Contas ou servidores de remetente comprometidos
- Inundação de e-mail ao estilo de negação de serviço
Na página IP Whitelist/Blacklist, podemos ignorar a análise para e-mails vindos de endereços IP específicos ou bloqueá-los diretamente.
Em Regional Policies, podemos aplicar bloqueio geográfico ou lista de permissões. Também podemos bloquear ou permitir e-mails com base no idioma do conteúdo.
Em Recipient Policies, podemos configurar regras de análise ou bypass com base no endereço de e-mail do destinatário.
O Barracuda também fornece políticas semelhantes para remetentes. Podemos aplicar exceções com base no remetente.
Também existe um painel onde podemos definir exceções com base em controlos de segurança de e-mail padrão, como DMARC, DKIM e SPF.
Em Content Policies, podemos configurar se devemos analisar ou ignorar e-mails com base no nome ou tipo de ficheiro. Também podemos definir regras de análise ou bypass com base no conteúdo corpo da mensagem usando expressões regulares.
O Barracuda fornece Advanced Threat Protection como uma subscrição adicional ao scanner de vírus regular. O Advanced Threat Protection (ATP) é um serviço de análise baseado na nuvem que analisa anexos de e-mail num ambiente de nuvem seguro para detetar ameaças que os scanners de vírus padrão podem não detetar. Aplica-se a mensagens de entrada e suporta a maioria dos tipos de ficheiro MIME.
Existem três modos no ATP:
- Deliver First, Then Scan tenta analisar o anexo em tempo real à medida que o e-mail chega. Se a análise for concluída a tempo e uma ameaça for detetada, o e-mail é bloqueado. Se a análise não terminar a tempo, o e-mail é entregue imediatamente sem esperar pelo resultado. A análise continua a ser executada em segundo plano e, se uma ameaça for encontrada posteriormente, o destinatário é notificado, mas o e-mail já chegou à sua caixa de entrada. Isto significa que o destinatário pode abrir um anexo infetado antes de a ameaça ser identificada.
- Scan First, Then Deliver analisa o anexo antes da entrega. Se uma ameaça for detetada, o e-mail é bloqueado. Se estiver limpo, é entregue. E-mails pendentes de análise aparecem no Message Log com "Pending Scan" como motivo. Se uma mensagem permanecer diferida por mais de quatro horas, é colocada em quarentena. Este modo é mais seguro, mas pode atrasar a entrega.
- Disabled: O ATP é totalmente desligado.
O principal compromisso aqui é entre velocidade e segurança. "Deliver First" prioriza a velocidade de entrega, mas introduz uma janela de risco. "Scan First" elimina esse risco, mas pode atrasar ou diferir mensagens com anexos.
Na secção Reports, o Barracuda cria relatórios detalhados sobre segurança de e-mail:
- Inbound/outbound traffic summary: Visão geral de toda a atividade de e-mail de entrada e saída, dividida por diferido, bloqueado, em quarentena e permitido.
- Inbound blocked emails breakdown: Detalhe detalhado do motivo pelo qual os e-mails de entrada foram bloqueados.
- Top inbound email senders/recipients: Mostra os remetentes/destinatários mais frequentes de e-mail de entrada.
- Top inbound blocked senders breakdown: Lista os remetentes cujos e-mails são bloqueados com mais frequência, com o raciocínio.
- Top inbound blocked recipients breakdown: Mostra os destinatários internos que são alvo mais frequente de e-mails bloqueados.
- Top outbound email senders: Visão geral dos utilizadores internos que enviam o maior volume de e-mail de saída.
- Top outbound blocked senders: Mostra os utilizadores internos cujos e-mails de saída são bloqueados com mais frequência.
Além disso, podemos agendar relatórios automatizados, o que é uma funcionalidade útil. Em vez de iniciar sessão repetidamente para verificar os painéis, podemos receber resumos regulares de ameaças, mensagens em quarentena, tendências de spam, deteções de malware, tentativas de personificação, ações de política e risco do utilizador. Os relatórios agendados também podem ajudar os utilizadores a identificar padrões precocemente, como um aumento de e-mails de phishing, ataques repetidos contra utilizadores específicos ou um aumento de anexos maliciosos bloqueados.
O menu Syslog à esquerda permite-nos encaminhar todos estes registos para um servidor de log à nossa escolha. Esta é uma funcionalidade útil para integrações SIEM.
No geral, o produto oferece uma vasta gama de funcionalidades, mas tem um desempenho inferior na deteção de ameaças. Uma parte significativa da configuração é deixada ao utilizador, levantando a questão de saber se o valor acrescentado justifica a sobrecarga, particularmente para organizações que usam o Google Workspace ou o Microsoft 365 Compliance Center.
Principais funcionalidades das soluções de segurança de e-mail na nuvem
As soluções de segurança de e-mail na nuvem analisam o comportamento do utilizador, detetam anomalias contextuais, automatizam a resposta e remediação de ameaças e integram-se com o ecossistema de segurança mais amplo. As principais funcionalidades incluem:
Deteção de ameaças com IA
Os sistemas de segurança de e-mail na nuvem analisam o contexto da mensagem, o histórico do remetente e a intenção para sinalizar ataques de phishing e tentativas de personificação que parecem legítimos superficialmente. Isto inclui identificar sinais subtis como domínios semelhantes ou padrões de tempo incomuns.
Ao rastrear hábitos de comunicação normais, estes sistemas podem detetar anomalias, como um funcionário financeiro receber subitamente pedidos de pagamento urgentes de um novo remetente externo. Esta abordagem é especialmente importante para detetar business email compromise (BEC), onde não há malware para analisar e nem sinais de alerta óbvios.
Arquitetura de proteção em várias camadas
As plataformas de segurança de e-mail na nuvem combinam várias camadas de inspeção para apanhar ameaças que escapam a um controlo.
- A análise estática verifica indicadores conhecidos, enquanto o sandboxing dinâmico observa como os anexos se comportam num ambiente controlado.
- A inspeção de URL também desempenha um papel fundamental, especialmente para identificar links maliciosos que são ativados após a entrega.
- Protocolos de autenticação como SPF, DKIM e DMARC ajudam a validar a identidade do remetente, reduzindo o risco de falsificação.
Together, estas camadas criam um sistema onde cada componente compensa as limitações dos outros.
Proteção contra ameaças emergentes
Os atacantes dependem cada vez mais do engano em vez de explorações técnicas. As táticas de engenharia social são projetadas para pressionar os utilizadores a tomar decisões rápidas, muitas vezes imitando executivos ou fornecedores confiáveis.
Isto inclui campanhas direcionadas, como spear phishing, nas quais as mensagens são adaptadas a um indivíduo ou função específica. Cenários mais avançados envolvem mensagens de voz deepfake ou tentativas de fraude de faturas.
Estas ameaças avançadas não dependem de ficheiros maliciosos. Em vez disso, exploram a confiança, tornando a deteção dependente do contexto e da intenção, em vez de assinaturas.
Deteção em tempo real e resposta automatizada
Uma vez que uma mensagem maliciosa chega a uma caixa de entrada, a janela para danos é limitada. Os sistemas de segurança analisam os e-mails à medida que chegam e agem imediatamente quando uma ameaça é confirmada.
A automação reduz a carga sobre as equipas de segurança, removendo mensagens prejudiciais em todas as caixas de correio afetadas, mesmo após a entrega. Isto limita a propagação de ataques que dependem de encaminhamento interno ou cadeias de resposta.
Os fluxos de trabalho de resposta também podem desencadear ações mais amplas, como isolar contas ou atualizar regras de deteção com base em novas informações.
Monitorização contínua e proteção pós-entrega
A filtragem inicial não apanha tudo. As técnicas de ataque evoluem e algumas ameaças são reconhecidas depois de surgirem novos indicadores.
- A monitorização contínua permite que os sistemas revisitem mensagens entregues e removam ameaças recentemente identificadas. Isto é crítico para ataques que usam payloads atrasados ou entrega faseada.
- A remediação pós-entrega garante que e-mails anteriormente não detetados não permaneçam nas caixas de entrada depois de serem classificados como maliciosos.
Continuidade e resiliência de e-mail
A segurança não se trata apenas de bloquear ameaças. A disponibilidade também importa. Se o acesso ao e-mail for interrompido, as operações de negócio podem parar.
As funcionalidades de continuidade baseadas na nuvem fornecem acesso de backup durante interrupções e suportam a recuperação rápida de mensagens e contas. Isto garante que o e-mail empresarial permaneça disponível mesmo durante interrupções de serviço ou ataques.
Capacidades diferenciadoras das plataformas de segurança de e-mail na nuvem
Segurança focada no utilizador (camada humana)
Muitos incidentes começam com uma ação do utilizador. É por isso que as plataformas modernas de segurança de e-mail incluem ferramentas que orientam o comportamento em vez de dependerem da filtragem.
- Banners de aviso contextuais podem alertar os utilizadores quando uma mensagem parece suspeita.
- O treino também está a tornar-se mais adaptativo. Em vez de simulações genéricas, os utilizadores recebem orientação adaptada aos seus padrões de interação.
Segurança unificada e integração de plataforma
O e-mail não existe isoladamente. Faz parte de um ambiente mais amplo que inclui endpoints, identidades e aplicações. A integração com sistemas de endpoint e identidade permite respostas coordenadas. Por exemplo, se um e-mail levar ao roubo de credenciais, o sistema pode desencadear ações além da caixa de entrada.
Painéis centralizados dão às equipas uma visão mais clara da sua postura geral de segurança, reduzindo a falta de comunicação entre ferramentas.
Proteção de dados, encriptação e conformidade
O e-mail transporta frequentemente contratos, detalhes financeiros e outros dados confidenciais. Proteger estas informações requer mais do que deteção de ameaças.
- A encriptação garante que as mensagens permaneçam privadas em trânsito e em repouso. As políticas de prevenção de perda de dados ajudam a prevenir a partilha não autorizada, seja acidental ou intencional.
- As funcionalidades de conformidade suportam requisitos regulamentares, incluindo trilhos de auditoria e políticas de retenção. Isto é especialmente relevante para organizações que operam além-fronteiras e lidam com dados sujeitos a regras legais ou específicas do setor rigorosas.
Metodologia do benchmark de segurança de e-mail na nuvem
Comparamos três produtos de segurança de e-mail: Acronis Advanced Email Security (com tecnologia Perception Point), Sophos Email Security e Barracuda Email Protection.
O benchmark incluiu 100 testes de ponta a ponta e seguiu quatro princípios.
- Orientado à cobertura: Cada teste mapeia uma capacidade que o fornecedor afirma publicamente fornecer.
- Ponderado pela dificuldade: Falhar um teste simples de 1/10 sinaliza uma lacuna grave no produto. Falhar um teste de 9/10 é mais compreensível porque esses casos refletem problemas de deteção de nível especializado. O método de pontuação separa estes casos em vez de tratar todas as falhas igualmente.
- Reproduzível: O benchmark é executado com um harness de teste PHP autocontido e verificado por um conjunto de verificação separado. Antes de qualquer e-mail de teste ser enviado, o verificador realiza mais de 1.800 verificações para confirmar que os payloads de teste estão completos, válidos e configurados corretamente.
- Ético: Os testes de malware usam a string de teste de antivírus EICAR. Os URLs de phishing apontam para infraestrutura canário inerte ou inexistente. Todas as caixas de correio de teste são propriedade da equipa de teste.
Selecionamos os testes para que as alegações públicas de cada fornecedor fossem exercitadas pelo menos uma vez. A prioridade foi testar ameaças que todos os três fornecedores afirmam detetar, o que mantém a comparação direta justa. Também incluímos um número menor de casos específicos do fornecedor quando eram relevantes. Por exemplo, o sequestro de conversas é uma alegação central do Barracuda, a deteção de phishing por código QR é explicitamente reivindicada pelo Acronis Advanced Email Security, e as iscas GenAI ao estilo deepfake são mais frequentemente promovidas por fornecedores que priorizam a IA.
O benchmark está organizado em onze categorias. Cada categoria testa um mecanismo de deteção diferente. As contagens de testes são mostradas entre parênteses, com 100 testes no total.
Categoria A: Spam (9 testes)
Esta categoria cobre anúncios farmacêuticos em massa, e-mails de pump-and-dump de criptomoedas, esquemas de lotaria, empréstimos de dia de pagamento, aberturas de plataformas de namoro e divulgação fria de B2B SEO.
A maioria dos testes nesta categoria é intencionalmente fácil. Dois testes, marketing de graymail e divulgação fria B2B, situam-se mais próximos do limite de falsos positivos porque a filtragem agressiva pode bloquear e-mails comerciais legítimos.
Categoria B: Malware conhecido usando a string de teste EICAR (9 testes)
Esta categoria testa a entrega de EICAR em formatos de anexo comuns e aninhados:
- Anexo .txt simples,
- ZIP normal,
- ZIP protegido por palavra-passe com a palavra-passe incluída no corpo do e-mail,
- ZIP aninhado dentro de outro ZIP,
- EICAR com uma extensão .exe para testar o tratamento de incompatibilidade de extensão e conteúdo,
- .tar.gz, arquivo recursivo de três níveis,
- .gz de ficheiro único sem um wrapper tar,
- EICAR com quatro kilobytes de lixo prependido para testar a tolerância de deslocamento.
Estes testes exercitam o desempacotamento de arquivos, suporte de formato e extração de palavra-passe do corpo do e-mail. Estas são capacidades de base para gateways de e-mail modernos.
Categoria C: Tipos de ficheiro portador (10 testes)
Esta categoria testa formatos de ficheiro comumente usados para transportar ou desencadear comportamento malicioso. O conjunto inclui:
- PDF com JavaScript incorporado e um gatilho OpenAction,
- HTML smuggling usando URL.createObjectURL num blob codificado em Base64,
- SVG com um script onload e XHR remoto,
- Atalho .lnk do Windows com um payload PowerShell no bloco de argumentos,
- Ficheiro poliglota PDF/ZIP,
- HTML Application .hta com VBScript,
- Dropper JavaScript do Windows Script Host usando XMLHTTP e ADODB.Stream,
- Imagem ISO 9660 contendo EICAR,
- Ficheiro .url de Atalho de Internet,
- Ficheiro .iqy de Consulta de Internet do Excel.
Esta é uma das categorias mais discriminantes porque os resultados do produto variam amplamente nestes tipos de portador.
Categoria D: Phishing de URL (10 testes)
Esta categoria mede a análise de URL em links diretos, redirecionamentos, ofuscação e localizações fora do corpo. Inclui:
- URL de phishing direto num TLD suspeito,
- Destino encurtado pelo Bitly,
- Cadeia de redirecionamento multi-hop através do redirecionador aberto do Google e t.co,
- Homoglifo IDN Punycode usando "а" cirílico em раypal.com,
- URL oculto em HTML usando caracteres de largura zero e texto branco de um pixel,
- URL presente dentro de uma anotação PDF,
- URI transportando HTML codificado em Base64 com um link de phishing,
- URL extremamente longo com o host real enterrado na string de consulta,
- Parâmetro de redirecionamento aberto num host de aparência legítima,
- URL de cache AMP do Google que oculta o destino de phishing atrás de google.com/amp/s/.
Categoria E: Phishing por código QR (8 testes)
Esta categoria testa se os produtos podem extrair e inspecionar URLs de phishing ocultos dentro de códigos QR. O conjunto inclui:
- Códigos QR PNG inline para re-registo de MFA,
- Assinatura DocuSign,
- Acesso a recibo de vencimento,
- Aviso de reenvio de encomenda
- Acesso a correio de voz
- Reposição de 2FA bancário.
Também inclui variantes de evasão: um código QR incorporado num PDF sem conteúdo QR no corpo do e-mail, um código QR entregue como uma imagem SVG-wrapped e um código QR definido como um data URI de background-image CSS em vez de uma tag <img>.
Estes casos testam se o scanner examina imagens fora dos contentores HTML mais óbvios.
Categoria F: Personificação de marca e domínio (9 testes)
Esta categoria testa a personificação de remetente, domínio, marca e cabeçalho e inclui:
- Falsificação de nome de exibição de uma conta Gmail genérica,
- Domínio typosquat usando m1crosoft-account.com,
- Homoglifo IDN punycode para Apple
- Abuso de subdomínio através de microsoft.support-team-portal.tk
- Imitação do kit de marca Microsoft usando o logótipo real e o estilo Segoe UI
- Incompatibilidade de cabeçalho Sender e From
- Personificação de banco local
- Typosquatting de uma empresa de comércio eletrónico
- Injeção de cabeçalho Authentication-Results onde o atacante adiciona valores forjados spf=pass, dkim=pass e dmarc=pass à mensagem.
O último caso testa se os parsers downstream confiam em cabeçalhos de autenticação fornecidos pelo atacante em vez de validar os resultados upstream reais.
Categoria G: BEC e spear phishing sem payloads (9 testes)
Esta categoria foca-se em engenharia social sem anexos ou links maliciosos e inclui:
- Pedido de transferência bancária do CEO enviado de uma conta Gmail,
- Pretexto de alteração bancária de Vendor Email Compromise,
- Redirecionamento de salário de autoatendimento do funcionário,
- Esquema de cartão-presente online de um imitador de CFO
- Sequestro de conversa usando um assunto Re:Re: e cabeçalhos In-Reply-To forjados,
- Pedido de provas confidenciais de um escritório de advocacia falso,
- Divulgação de head-hunter externo com um currículo em anexo,
- Pretexto de account takeover de autenticação de dois fatores do WhatsApp,
- Pretexto de informação privilegiada de M&A que combina linguagem de confidencialidade com urgência.
Categoria H: Extorsão e esquemas (9 testes)
Esta categoria cobre padrões comuns de esquemas e extorsão. Os testes incluem:
- E-mail usando uma palavra-passe antiga vazada,
- Fatura falsa com um link de pagamento malicioso num PDF,
- Carta de taxa antecipada,
- Ameaça de confisco da autoridade tributária,
- Extorsão de DDoS contra um website,
- Aviso falso de bloqueio de iCloud da Apple com um link de desbloqueio,
- Esquema de taxa alfandegária de correio
- Extorsão de doxing,
- Esquema de familiar preso na alfândega.
Categoria I: Phishing de qualidade GenAI (10 testes)
Esta categoria testa e-mails de phishing refinados que removem as pistas óbvias em que os sistemas mais antigos muitas vezes se baseiam. O conjunto inclui:
- E-mail de reverificação do helpdesk de TI com passos estruturados e um botão de marca,
- Pré-leitura falsa do conselho com linguagem de confidencialidade e um link de espaço de trabalho,
- Atualização de política de inquilino do Microsoft 365 exigindo re-consentimento no prazo de sete dias,
- Pedido de assinatura eletrónica do Código de Conduta de RH,
- Acompanhamento de sucesso do cliente após uma reunião fictícia,
- Personificação de recapitulação de reunião,
- NDA legal de uma contraparte fictícia,
- Aviso crítico de CVE ao estilo CISO,
- Pré-visualização de resultados de relações com investidores com linguagem de embargo,
- Resolvedor de conflitos de calendário exigindo início de sessão SSO único.
Cada e-mail nesta categoria foi escrito para parecer uma mensagem de negócios competente de um falante nativo de inglês. Os testes evitam deliberadamente os sinais de alerta de phishing mais antigos, como gramática quebrada, frases estranhas e incompatibilidades óbvias de marca.
Categoria J: Técnicas de evasão (9 testes)
Esta categoria testa a ofuscação que pode quebrar a inspeção superficial de conteúdo e inclui:
- Caracteres Unicode de largura zero dentro de palavras-gatilho,
- Bypass de OCR onde toda a mensagem de phishing é renderizada como um PNG sem texto corporal analisável,
- Caractere de substituição direita-para-esquerda num nome de ficheiro de anexo,
- Nome de ficheiro de extensão dupla,
- Isca oculta por CSS onde o texto renderizado parece benigno enquanto o DOM contém o conteúdo de phishing,
- Assunto de palavra codificada RFC 2047,
- URL com caracteres codificados em hexadecimal no host,
- Homoglifo de assunto usando "е" cirílico para "e" latino,
- URL oculto num atributo HTML data-* e recuperado no momento do clique por JavaScript inline.
Categoria K: Conjunto de controlo e teste de falsos positivos (8 testes)
O conjunto de controlo contém e-mails comerciais legítimos que devem passar sem aviso e incluem:
- Notificações internas da equipa,
- Relatórios mensais de despesas,
- Acompanhamentos de reuniões,
- Resumos semanais,
- Ficheiros ZIP protegidos por palavra-passe usados para partilha interna legítima,
- Lembretes de treino,
- Avisos de manutenção de TI,
- E-mails de agendamento individual.
Qualquer produto que sinalize uma destas mensagens recebe uma penalização de falso positivo.
Arquitetura de dois remetentes
Muitos testes de segurança de e-mail ignoram uma distinção importante entre ataques orientados ao conteúdo e ataques orientados à identidade do remetente. Algumas ameaças são perigosas por causa dos seus corpos de mensagem ou anexos, independentemente de quem as envia. Outras são perigosas porque o e-mail afirma vir de alguém que não representa. Estas duas classes requerem configurações de envio diferentes.
Dividimos o benchmark em dois grupos de remetentes.
- Grupo L, Legit, 38 testes: Estes e-mails são enviados de um serviço SMTP autenticado. SPF, DKIM e DMARC alinham-se corretamente para o domínio de envio. O nome de exibição muda por teste, como Finanças, Helpdesk de TI ou o nome real do testador, mas o endereço From permanece o endereço de remetente autenticado.
- O Grupo L é usado para categorias orientadas ao conteúdo: K, B, C, J e os dois testes de phishing de URL, onde o URL é a ameaça independentemente do remetente.
- Grupo S, Spoof, 62 testes: Estes e-mails são enviados através de um relay SMTP permissivo que não impõe o alinhamento do domínio From. O endereço From é o que o caso de teste especifica, pelo que o alinhamento SPF e DMARC falha por design.
- O Grupo S é usado para categorias orientadas à identidade do remetente: A, a maioria de D, E, F, G, H e I.
Esta divisão reflete o comportamento real do atacante. Os operadores de phishing usam frequentemente servidores virtuais baratos e domínios descartáveis porque os serviços SMTP de nuvem tradicionais, como Gmail, Office 365 e AWS SES, com domínios verificados, impedem o envio de correio com um cabeçalho From desalinhado.
Figura 1: Figura mostrando como funciona um servidor de relay SMTP. Um servidor de relay SMTP é um servidor de correio de terceiros que recebe e-mails de um remetente e os encaminha para servidores de destinatários fora do domínio do provedor de correio do próprio remetente.
Ponderação de dificuldade
Cada teste tem uma classificação de dificuldade de 1 a 10. A classificação indica quão difícil um produto de segurança de e-mail competente deve achar o teste.
- 1 a 2, trivial: Estas são assinaturas de manual sem ofuscação significativa. Falhá-las indica uma lacuna de deteção fundamental. Exemplos são spam farmacêutico, EICAR simples num ZIP e uma carta nigeriana 419.
- 3 a 4, bem conhecido: Estes são padrões familiares que os produtos modernos devem detetar. Exemplos incluem JavaScript em PDF, sextorsão com palavra-passe vazada e falsificação de nome de exibição de CEO.
- 5 a 6, intermédio: Estes casos requerem uma análise mais forte, como IA moderna, sandboxing ou visão computacional, incluindo HTML smuggling, URLs de homoglifo IDN e phishing por código QR inline.
- 7 a 8, avançado: Estes são casos limite que produtos mais fortes tratam de forma consistente, como poliglotas PDF/ZIP, cadeias de redirecionamento multi-hop, personificação visual de kit de marca e iscas de bypass de OCR apenas de imagem.
- 9 a 10, especialista: Estes são casos genuinamente difíceis onde detetar é um resultado forte e falhar é comum em todo o setor. Exemplos incluem sequestro de conversa de thread forjado, um acompanhamento de sucesso do cliente de qualidade GenAI e um NDA legal falso de uma contraparte previamente desconhecida.
- Testes de controlo: As mensagens da categoria K devem passar. Qualquer deteção nesta categoria conta como um falso positivo.
As médias das categorias seguem a curva de dificuldade pretendida: A spam tem média de 2.2/10, B EICAR tem média de 2.8/10, H extorsão tem média de 3.8/10, C ficheiros portadores tem média de 5.0/10, F personificação de marca e J evasão têm média de 5.6/10, D phishing de URL tem média de 5.8/10, E phishing por código QR tem média de 6.8/10, G BEC tem média de 6.8/10, e I phishing GenAI tem média de 8.2/10.
Pontuação do benchmark
Cada produto recebe um de cinco vereditos por teste:
- BLOCK: A mensagem é colocada em quarentena ou rejeitada (2 pontos).
- WARN: O produto injeta um banner, envia o e-mail para spam ou remove o anexo (0.5 pontos).
- LATE: A mensagem é entregue primeiro e depois removida pós-entrega (1 ponto).
- MISS: A mensagem chega à caixa de entrada sem aviso (0 pontos).
- FP: Uma mensagem do conjunto de controlo é sinalizada incorretamente (penalização de -2 pontos).
A taxa de deteção é calculada como o total de pontos dividido pela pontuação máxima possível para testes de ataque, depois expressa como uma percentagem. A pontuação máxima possível é igual ao número de testes de ataque multiplicado por dois.
A taxa de falsos positivos é reportada separadamente. Um produto que atinge 90% de deteção bloqueando correio legítimo representa mais risco operacional do que um que atinge 80% de deteção sem falsos positivos.
Reprodutibilidade e ferramentas
O benchmark é executado a partir de um único script PHP autocontido. O script constrói 100 mensagens MIME em memória com um construtor multipartes personalizado. Gera os payloads localmente, incluindo ZIPs, ZIPs encriptados com AES-256, ficheiros tar.gz, ficheiros .gz de ficheiro único, PDFs com ações JavaScript, amostras de HTML smuggling, ficheiros SVG com JavaScript onload, ficheiros .lnk do Windows com o CLSID Shell Link correto e bloco de argumentos UTF-16LE, e uma imagem de disco ISO 9660 mínima.
O script envia cada teste através do caminho SMTP correto com base no seu grupo de remetente.
Cada mensagem inclui cabeçalhos de rastreio: X-Bench-Id, X-Bench-Run, X-Bench-Product, X-Bench-Category, X-Bench-Case e X-Bench-Group. Estes cabeçalhos tornam cada teste rastreável em caixas de entrada, consoles de quarentena e registos de produto.
Um harness de verificação separado executa mais de 1.800 verificações de sanidade antes da transmissão. Valida que cada teste tem os campos necessários, cada classificação de dificuldade está dentro de [1, 10] ou zero para controlos, e EICAR está presente e recuperável de cada anexo da categoria B, incluindo arquivos protegidos por palavra-passe e triplamente aninhados.
O verificador também verifica se os PDFs contêm cabeçalhos %PDF- válidos e marcadores %%EOF, PNGs contêm assinaturas válidas e chunks IEND, SVGs são analisados como XML bem formado, o ficheiro LNK tem o CLSID Shell Link correto e a string de argumento PowerShell esperada, o Descritor de Volume Primário ISO 9660 aparece no setor 16 com a assinatura \x01CD001 correta, e a inferência de grupo corresponde à divisão documentada do Grupo L e Grupo S.
Um terceiro script processa os CSVs por produto após a entrada manual do veredito. Produz um relatório comparativo com uma tabela de veredito lado a lado por teste, taxas de deteção por categoria, pontuações totais, percentagens de taxa de deteção, contagens de falsos positivos e três sub-tabelas forenses:
- casos triviais mas falhados, definidos como dificuldade ≤ 2 com pelo menos um MISS
- casos de alta dificuldade mas detetados, definidos como dificuldade ≥ 8 com pelo menos um BLOCK
- todos os incidentes de falsos positivos
Restrições éticas e operacionais
Nenhum malware real foi criado ou transmitido. Os anexos maliciosos usam a string de teste de antivírus EICAR, um documento de teste de 68 caracteres definido pelo European Institute for Computer Antivirus Research, ou demonstradores benignos. Exemplos incluem um PDF cujo JavaScript chama app.alert, uma página HTML que usa URL.createObjectURL na string EICAR e um SVG cujo onload chama um endpoint inexistente.
Nenhuma infraestrutura de phishing ao vivo foi usada. Os URLs de teste resolvem para um de três destinos seguros: o TLD reservado .invalid definido na RFC 2606, domínios .tk de placeholder sob o nosso controlo que servem um 404, ou hosts de paródia como m1crosoft-account.com e xn--pple-43d.com registados para o benchmark e que não servem conteúdo.
Nenhuma página de captura de credenciais foi implementada. Todas as caixas de correio de teste são propriedade e monitorizadas pela equipa de teste. As credenciais SMTP são limitadas ao benchmark e rotacionadas após cada envolvimento.
Limitações do benchmark de segurança de e-mail
Excluímos várias categorias porque requerem infraestrutura ou condições além de um benchmark único:
- Troca de URL no momento do clique: Este ataque entrega um URL que parece benigno no momento da entrega e mais tarde redireciona para um destino de phishing. Testá-lo exigiria um servidor HTTP com estado que mute o seu conteúdo, além de uma ação de clique do lado do utilizador.
- Account takeover e phishing lateral: Isto exigiria o controlo de uma caixa de correio interna, o que estava fora da configuração do benchmark.
- Malware dinâmico com reconhecimento de sandbox: Amostras polimórficas reais que detetam virtualização e evitam a detonação foram excluídas por razões éticas.
- Páginas de destino de kits de phishing ao vivo: Todos os URLs resolvem para hosts inertes. O benchmark não testa a experiência pós-clique.
O remetente do Grupo S requer um relay SMTP que permita cabeçalhos From desalinhados. Os serviços SMTP de nuvem geralmente rejeitam estes testes ao nível da rede. Quando um relay permissivo não está disponível, o benchmark degrada para o Grupo L, o que deixa 38 testes orientados ao conteúdo.
Perguntas frequentes
As tecnologias de segurança de e-mail na nuvem protegem os sistemas e comunicações de e-mail contra ameaças cibernéticas, como phishing, malware, spam e violações de dados. Em vez de dependerem de infraestrutura no local, estas soluções operam na nuvem para monitorizar e filtrar o tráfego de e-mail, detetar conteúdo ou comportamento suspeito e aplicar políticas de segurança.
Ao alavancar técnicas como inteligência de ameaças, aprendizagem de máquina, filtragem de spam e análise automatizada, a segurança de e-mail na nuvem ajuda as organizações a proteger informações confidenciais e a manter comunicações seguras em plataformas como Microsoft 365, Google Workspace e Gmail.
Qualquer organização que dependa de e-mail está exposta a riscos, mas a forma como esse risco se manifesta depende muito da dimensão e do setor.
Empresas mais pequenas tendem a ser alvos mais fáceis. Muitas vezes carecem de equipas de segurança dedicadas, tornando-as mais vulneráveis a ataques comuns. As grandes empresas, por outro lado, enfrentam ameaças mais sofisticadas, como spear phishing e business email compromise (BEC), em que um único e-mail bem elaborado pode levar a perdas financeiras graves.
Alguns setores estão sob ainda mais pressão. Setores como saúde, finanças, governo e serviços jurídicos lidam com dados confidenciais e operam sob regulamentações rigorosas, o que os torna especialmente atrativos para os atacantes.
Muitas organizações também precisam de segurança de e-mail na nuvem porque os controlos nativos da plataforma podem não ser suficientes por si só. Empresas de segurança de e-mail como Abnormal Security, Sublime Security, Check Point e outros fornecedores de segurança de e-mail fornecem proteção adicional, add-ons e capacidades baseadas em API para ajudar as organizações a manterem-se à frente dos ataques em evolução.
Cite esta pesquisa
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{dogan2026,
author = {Dogan, Sedat},
title = {{Soluções de Segurança de E-mail: Acronis, Sophos & Barracuda}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/email-security-solutions}},
note = {AIMultiple. Acessado em 22 Junho 2026}
}



























































Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.