Identificamos uma nova campanha de phishing direcionada em que cibercriminosos tentaram atacar empresas de manufatura. O ataque envolveu uma abordagem em múltiplas etapas: antes de enviar o link de phishing diretamente, eles iniciaram uma conversa com a vítima por meio de e-mails a fim ganhar sua confiança. É provável que as conversas tenham sido geradas usando grandes modelos de linguagem. No momento desta postagem, o ataque ainda estava ocorrendo, por isso recomendamos atenção!

O esquema de phishing

Os invasores tentam se passar por clientes em potencial. Os e-mails são enviados por endereços registrados em serviços de e-mail gratuitos. Esses serviços não têm uma má reputação conhecida e geralmente são usados para o envio de e-mails corporativos, especialmente por pequenas empresas. Seja qual for o idioma nativo da vítima (vimos ataques direcionados a empresas na Rússia, República Tcheca, Malásia e Egito), os e-mails dos atacantes são sempre escritos em inglês.

No primeiro contato, eles fazem perguntas sobre os produtos oferecidos, citando nomes reais de produtos. Isso indica uma preparação minuciosa para os ataques. Eles não enviam e-mails idênticos para empresas de manufatura com perfis semelhantes, mas pesquisam cuidadosamente informações públicas disponíveis on-line sobre cada vítima. Se alguém responder ao primeiro e-mail, os invasores continuam a conversa. Às vezes, antes de ir direto ao seu objetivo, que é extrair credenciais de contas de e-mail corporativas, eles trocam várias mensagens nas quais, como distração, esclarecem certos detalhes ou fazem perguntas adicionais. Mas, na maior parte das vezes, eles enviam o link de phishing já no segundo e-mail.

Os invasores enviam especificações detalhadas de um produto no qual afirmam estar interessados, perguntam se o produto pode ser gravado de acordo com um esboço ou usam qualquer outro pretexto para tentar fazer com que a vítima abra o arquivo enviado.

Site de phishing

Na realidade, não há nenhum arquivo. O site de phishing que é aberto quando a vítima clica no link imita um serviço na nuvem popular para editar documentos em PDF. O botão “Baixar” leva a um formulário de login no qual a vítima é solicitada a inserir seu endereço de e-mail corporativo e sua senha para acessar o arquivo confidencial. Obviamente, isso é “por motivos de segurança”. Se um funcionário da empresa alvo não parar para pensar por que inseriria suas credenciais de login corporativas em um site completamente sem relação com a empresa, um site que claramente não tem como verificar sua autenticidade, seu endereço de e-mail e a senha associada serão enviados para o servidor dos invasores.

Como se manter em segurança?

Os ataques de phishing modernos estão se tornando cada vez mais sofisticados e, graças ao uso de ferramentas de IA pelos atacantes, também mais convincentes. É por isso que, em primeiro lugar, recomendamos aumentar a conscientização sobre segurança dos funcionários sempre que possível. E para garantir que eles tenham que colocar esse conhecimento em prática o mínimo possível, recomenda-se implementar uma solução de segurança no nível do gateway de e-mail. O Kaspersky Secure Mail Gateway detecta esse ataque de phishing antes mesmo de os atacantes passarem para a tentativa de phishing propriamente dita.

Não é segredo que os cibercriminosos vêm usando grandes modelos de linguagem para otimizar suas operações. Como resultado, as inúmeras campanhas de phishing e malware direcionadas às organizações tornaram-se muito mais sofisticadas. Esses e-mails agora contêm menos erros evidentes, e o tom deles se aproxima muito de uma correspondência comercial legítima. No entanto, os métodos usados para distribuir essas campanhas sempre apresentam um indício claro: uma tentativa de roubar credenciais ou executar código malicioso. Os ataques de comprometimento de e-mail comercial (BEC), no entanto, representam um desafio ainda maior.

Os ataques BEC normalmente dependem inteiramente da engenharia social, induzindo um funcionário legítimo a executar as ações solicitadas pelos invasores. Esses ataques também se tornaram muito mais sofisticados desde o surgimento dos LLMs. Se as táticas forem bem-sucedidas, por exemplo, se eles conseguirem convencer um funcionário a transferir fundos para uma conta de terceiros em vez da conta de um prestador de serviços, a empresa poderá perder muito dinheiro em questão de instantes. Foi por isso que desenvolvemos uma tecnologia especializada para detectar e-mails de BEC gerados com IA.

Como funciona a tecnologia de detecção de BEC gerado com IA

Sem entrar em muitos detalhes técnicos, veja como essa nova tecnologia funciona. Como você deve saber, os grandes modelos de linguagem não produzem textos da mesma forma que os seres humanos. Em vez disso, eles preveem as palavras que têm maior probabilidade de se adequar à tarefa descrita no prompt. Além disso, os cibercriminosos tendem a seguir o caminho mais fácil: em vez de reinventar a roda, recorrem aos modelos de IA mais amplamente disponíveis.

Como o objetivo dos invasores é relativamente claro, podemos extrair do texto frases-chave específicas de ataques de BEC. Além disso, aprendemos a identificar quando um texto foi gerado por uma máquina. Esses indicadores são um dos pilares da nossa tecnologia de detecção. Como resultado, nossa solução de segurança agora consegue identificar e bloquear tentativas de ataques BEC logo no estágio inicial, antes mesmo que o invasor tenha a oportunidade de enganar um funcionário. Atualmente, a tecnologia detecta e-mails de BEC gerados com IA em inglês, russo, alemão, francês, italiano, espanhol, português e turco.

Quais de nossas soluções apresentam a tecnologia de detecção de BEC gerada com IA?

Nosso portfólio de soluções de segurança corporativa inclui o Kaspersky Security for Mail Server, que incorpora o Kaspersky Secure Mail Gateway. É no gateway seguro de e-mail que nossa tecnologia de detecção de e-mails BEC gerados por IA está implementada. Mais especificamente, o recurso está disponível na licença KSMS Plus após a recente atualização para o KSMG 3.1. Visite a página oficial do Kaspersky Secure Mail Server para saber mais sobre nossas soluções de segurança de e-mail e os recursos adicionados na atualização mais recente.

One of the most common pieces of anti-phishing advice is to double-check the website’s domain name before providing your credentials. Typically, a fraudulent domain stands out to the trained eye, differing from the official URL by at least a few characters. Recently, however, we encountered a campaign where attackers instruct victims to input data directly into a legitimate, trusted corporate site: the Microsoft Identity Platform, which supports an OAuth 2.0 specification known as the Device Authorization Grant.

This specific protocol extension was designed to simplify the login experience for smart TVs, IoT hardware, printers, and other input-constrained devices that lack a full browser or keyboard. It allows users to use a nearby smartphone or PC for authorizing these devices to access their accounts. To complete the process, the user enters a one-time code on a designated authentication page. The Microsoft Identity Platform returns this code along with a link to enter it in response to a request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode; hence, an attack scenario exploiting this mechanism is called Device Code Phishing.
In this post, we break down how the Device Authorization Grant specification (also known as the Device Authorization Grant Flow or Device Code Flow) works, analyze real-world attacks leveraging this technology, and outline effective strategies to defend against Device Code Phishing.

Core steps of Device Authorization Grant

1. Requesting the authorization code

When a user launches an app on a client device, such as a streaming app on a Smart TV, the app detects that it is unauthenticated and sends a POST request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode. This request includes the client_id (the unique identifier of the app registered in Microsoft Entra ID / Azure AD) and the scope (the requested access permissions). In response, the application receives several parameters: device_code (a secret code for internal use), user_code (a short code displayed to the end-user), verification_uri (the login URL the user needs to visit), expires_in (the code’s lifespan), and interval (how frequently the app should poll the server).

2. Displaying the code to the user

The device displays both the user_code and the verification_uri to the user, instructing them to complete authentication on another device. For instance, a smart TV will display the code and URL — often rendering the verification_uri as a QR code — so the user can access it via their smartphone.

3. Entering the code and confirming access

By scanning the QR code with a smartphone camera or manually typing out the address, the user navigates to the verification_uri (such as https://microsoft.com/devicelogin) and enters the user_code.

4. Polling the server

The device (smart TV) begins polling the server to check the authorization status — essentially verifying whether the user has approved the access request. It does this by sending a POST request to the token endpoint: https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. The request passes the grant_type parameter with the value urn:ietf:params:oauth:grant-type:device_code, indicating the use of the Device Authorization Grant method. This signals to the authorization server exactly which authentication method is being used to request access tokens. The server waits for the user to enter the user_code on their secondary device and approve access to their resources or data. Until that approval happens, the server responds with an error code like authorization_pending (keep waiting) or slow_down (reduce the polling frequency).

5. Issuing access tokens

Once the user successfully approves the application’s request, the server responds to the application by issuing an access_token (to access the data), a refresh_token (to renew access later), an id_token (containing user profile details like name and email), along with several other service parameters.

6. Automatic access renewal

The device (our smart TV) uses the refresh_token to silently renew the access_token without requiring any further user interaction. When the current access_token expires (typically after 1 hour), the device automatically sends a token refresh request containing the refresh_token to the token endpoint. It then receives a fresh pair of access and refresh tokens, ensuring the user remains authenticated seamlessly.

While this workflow is truly convenient for input-constrained devices, attackers can abuse it to hijack user accounts and maintain persistent access for extended periods using the issued refresh_token. Let’s use a real-world example to break down this attack vector.

Analysis of a Device Code Phishing attack

In a phishing campaign we observed spanning from early April to mid-May 2026, the initial email was styled as a notice from a law firm. Attached to the email was a password-protected PDF file.

Once the victim opened the PDF and entered the password, they were presented with a landing page listing several documents. However, viewing these documents required clicking a provided link.

A close look at the target URL reveals that instead of pointing to a typical, easily recognizable phishing domain, it actually points to a legitimate Microsoft address. However, the URL parameters are configured to redirect the user to a phishing resource.

The link within the document does not keep the user on the Microsoft platform; instead, it immediately redirects them to a phishing page designed to mimic a corporate legal portal.

Interestingly, the landing page featured multiple CAPTCHAs, presumably deployed to filter out security crawlers. Once past these hurdles, the user was routed to a final page that instructed them to copy a one-time code. This code was the user_code that the attacker’s server-side application had already fetched by querying https://login.microsoftonline.com/{tenant}/oauth2/v2.0/devicecode, as detailed in the workflow above.

Já escrevemos várias vezes sobre como códigos QR são usados em esquemas de phishing. Nosso gateway seguro de e-mail até inclui tecnologia para ler esses códigos (não apenas em e-mails, mas também em anexos) e verificar os links incorporados. Ainda assim, os criminosos não desistem de enviar códigos QR às suas vítimas. Recentemente, temos observado um aumento no uso de arte ASCII para essa finalidade. Trata-se de imagens criadas a partir de caracteres de texto. Isso é particularmente irônico, considerando que, no passado, os phishers tentavam escapar da verificação de links escondendo-os em imagens e, agora, estão tentando burlar a análise de imagens voltando ao uso de texto. Mas com algumas adaptações.

A arte esquecida do ASCII e como os criminosos a utilizam

Hoje pode parecer difícil acreditar, mas houve uma época em que os computadores não eram capazes de exibir imagens gráficas. Por isso, as primeiras imagens digitais eram construídas com caracteres de texto. Após a adoção do padrão ASCII (American Standard Code for Information Interchange) em 1963, seus caracteres passaram a ser amplamente utilizados para criar esse tipo de arte, garantindo que as imagens fossem exibidas da mesma forma em diferentes computadores. Com o passar do tempo, outros símbolos de texto, como os presentes no conjunto Unicode expandido, também passaram a ser utilizados na criação dessas imagens. Ainda assim, o termo “arte ASCII” continuou sendo usado para descrever esse estilo artístico de forma geral. Houve artistas que se dedicaram seriamente a essa técnica. Os primeiros sites da Internet utilizavam arte ASCII em seu design e até mesmo os primeiros conteúdos pornográficos digitais eram representados exclusivamente por caracteres de texto.

Com a evolução das tecnologias gráficas, a arte ASCII perdeu popularidade. Ela voltou a ganhar destaque nos anos 2000, durante o auge do spam por e-mail. Naquela época, os spammers utilizavam a técnica principalmente para disfarçar palavras associadas a spam que poderiam acionar filtros de e-mail. Além disso, mensagens compostas por texto consumiam menos recursos dos servidores do que imagens. Outro fator era que muitos usuários pagavam pelo volume de tráfego de Internet utilizado e, por isso, frequentemente desativavam o carregamento de imagens em seus clientes de e-mail. Naturalmente, naquela época, ampliamos nossas soluções de segurança para e-mail com tecnologias específicas para detectar e bloquear arte ASCII maliciosa.

Agora, a técnica de ASCII foi redescoberta, desta vez por criminosos que buscam contornar sistemas capazes de reconhecer códigos QR presentes em imagens.

Como é um ataque de phishing com arte ASCII?

Veja um exemplo recente. O pretexto em si é bem comum: alguém supostamente enviou à vítima um documento confidencial via DocuSign, mas, para abri-lo, o destinatário precisa escanear o código QR no e-mail para acessar um site e inserir suas credenciais corporativas.

À primeira vista, o código parece estranho. Isso acontece porque ele é desenhado utilizando caracteres pseudo-gráficos e até mesmo os espaços entre as linhas ficam visíveis. Na realidade, não há nenhuma imagem propriamente dita no código da mensagem de e-mail. Nos bastidores, o código QR se parece com algo assim:

Como resultado, os mecanismos de verificação de links não conseguem identificar o endereço, e as ferramentas de análise de imagens não conseguem detectar a URL oculta no código QR. Com isso, os criminosos acreditam que o e-mail de phishing chegará à vítima sem problemas. Spoiler: não esquecemos como bloquear arte ASCII.

É normal receber um código QR por e-mail?

Em teoria, existem situações legítimas em que o uso de um código QR faz sentido. Ele é uma forma prática de compartilhar contatos, links para aplicativos móveis, localizações em mapas ou informações de configuração. Em outras palavras, funciona bem quando o objetivo é transferir informações diretamente para um dispositivo móvel.

No entanto, se alguém pedir que você utilize um código QR para inserir credenciais corporativas em um smartphone, isso deve ser considerado um forte sinal de alerta. E quando esse código QR é criado com arte ASCII, trata-se claramente de uma tentativa de phishing ou de direcionamento para uma URL maliciosa. Esse tipo de técnica tem apenas uma finalidade: tentar contornar mecanismos de segurança.

Como se proteger?

Para impedir que e-mails de phishing, contendo ou não arte ASCII, cheguem às caixas de entrada dos colaboradores, recomendamos a adoção de um gateway de e-mail seguro antiphishing. Como camada adicional de defesa, é importante instalar soluções de segurança em todos os dispositivos utilizados para acessar a Internet.

Também recomendamos a realização periódica de treinamentos de conscientização em segurança, para que os colaboradores conheçam as táticas de phishing mais recentes. Vale destacar, especificamente, que a presença de arte ASCII em e-mails modernos pode ser um indicativo importante de uma tentativa de ataque de phishing.

Introduction

The primary goal for attackers in a phishing campaign is to bypass email security and trick the potential victim into revealing their data. To achieve this, scammers employ a wide range of tactics, from redirect links to QR codes. Additionally, they heavily rely on legitimate sources for malicious email campaigns. Specifically, we’ve recently observed an uptick in phishing attacks leveraging Amazon SES.

The dangers of Amazon SES abuse

Amazon Simple Email Service (Amazon SES) is a cloud-based email platform designed for highly reliable transactional and marketing message delivery. It integrates seamlessly with other products in Amazon’s cloud ecosystem, AWS.

At first glance, it might seem like just another delivery channel for email phishing, but that isn’t the case. The insidious nature of Amazon SES attacks lies in the fact that attackers aren’t using suspicious or dangerous domains; instead, they are leveraging infrastructure that both users and security systems have grown to trust. These emails utilize SPF, DKIM, and DMARC authentication protocols, passing all standard provider checks, and almost always contain .amazonses.com in the Message-ID headers. Consequently, from a technical standpoint, every email sent via Amazon SES – even a phishing one – looks completely legitimate.

Phishing URLs can be masked with redirects: a user sees a link like amazonaws.com in the email and clicks it with confidence, only to be sent to a phishing site rather than a legitimate one. Amazon SES also allows for custom HTML templates, which attackers use to craft more convincing emails. Because this is legitimate infrastructure, the sender’s IP address won’t end up on reputation-based blocklists. Blocking it would restrict all incoming mail sent through Amazon SES. For major services, that kind of measure is ineffective, as it would significantly disrupt user workflows due to a massive number of false positives.

How compromise happens

In most cases, attackers gain access to Amazon SES through leaked IAM (AWS Identity and Access Management) access keys. Developers frequently leave these keys exposed in public GitHub repositories, ENV files, Docker images, configuration backups, or even in publicly accessible S3 buckets. To hunt for these IAM keys, phishers use various tools, such as automated bots based on the open-source utility TruffleHog, which is designed for detecting leaked secrets. After verifying the key’s permissions and email sending limits, attackers are equipped to spread a massive volume of phishing messages.

Examples of phishing with Amazon SES

In early 2026, one of the most common themes in phishing emails sent with Amazon SES was fake notifications from electronic signature services.

The email’s technical headers confirm that it was sent with Amazon SES. At first glance, it all looks legitimate enough.

In these emails, the victim is typically asked to click a link to review and sign a specific document.

Upon clicking the link, the user is directed to a sign-in form hosted on amazonaws.com. This can easily mislead the victim, convincing them that what they’re doing is safe.

The resulting form is, of course, a phishing page, and any data entered into it goes directly to the attackers.

Amazon SES and BEC

However, Amazon SES is used for more than just standard phishing; it’s also a vehicle for a very sophisticated type of BEC campaigns. In one case we investigated, a fraudulent email appeared to contain a series of messages exchanged between an employee of the target organization and a service provider about an outstanding invoice. The email was sent as if from that employee to the company’s finance department, requesting urgent payment.

The PDF attachments didn’t contain any malicious phishing URLs or QR codes, only payment details and supporting documentation.

Naturally, the email didn’t originate with the employee, but with an attacker impersonating them. The entire thread quoted within the email was actually fabricated, with the messages formatted to appear as a legitimate forwarded thread to a cursory glance. This type of attack aims to lower the user’s guard and trick them into transferring funds to the scammers’ account.

Takeaways

Phishing via Amazon SES experienced an uptick in January 2026 and has remained relatively steady through Q1. By weaponizing this service, attackers avoid the effort of building dubious domains and mail infrastructure from scratch. Instead, they hijack existing access keys to gain the ability to blast out thousands of phishing emails. These messages pass email authentication, originate from IP addresses that are unlikely to be blocklisted, and contain links to phishing forms that look entirely legitimate.

Since these Amazon SES phishing attacks stem from compromised or leaked AWS credentials, prioritizing the security of these accounts is critical. To mitigate these risks, we recommend following these guidelines:

• Implement the principle of least privilege when configuring IAM access keys, granting elevated permissions only to users who require them for specific tasks.
• Transition from IAM access keys to roles when configuring AWS; these are profiles with specific permissions that can be assigned to one or several users.
• Enable multi-factor authentication, an ever-relevant step.
• Configure IP-based access restrictions.
• Set up automated key rotation and run regular security audits.
• Use the AWS Key Management Service to encrypt data with unique cryptographic keys and manage them from a centralized location.

We recommend that users remain vigilant when handling email. Do not determine whether an email is safe based solely on the From field. If you receive unexpected documents via email, a prudent precaution is to verify the request with the sender through a different communication channel. Always carefully inspect where links in the body of an email actually lead. Additionally, robust email security solutions can provide an essential layer of protection for both corporate and personal correspondence.

Uma variedade de criadores de aplicativos com tecnologia de IA promete dar vida às suas ideias com rapidez e facilidade. Infelizmente, sabemos exatamente quem está sempre à procura de novas ideias para dar vida, principalmente porque somos muito bons em identificar e bloquear as antigas. Estamos falando de phishers, é claro. Recentemente, descobrimos que eles adicionaram um novo truque ao seu arsenal: gerar sites usando o criador de aplicativos da Web com tecnologia IA Bubble. É muito provável que essa tática já esteja disponível em uma ou mais plataformas de phishing como serviço, o que praticamente garante que essas armadilhas começarão a aparecer em uma ampla variedade de ataques. Mas vamos detalhar em etapas.

Por que os phishers estão usando o Bubble?

Incluir um link direto para um site de phishing em um e-mail é um caminho sem volta para o fracasso. Há uma grande probabilidade de a mensagem nem chegar ao destino, pois os filtros de segurança provavelmente a bloquearão antes que o usuário a veja. Da mesma forma, o uso de redirecionamentos automatizados já está no radar das soluções de segurança modernas. E os QR codes? Embora fazer com que a vítima escaneie um código com o celular, em vez de clicar em um link, possa funcionar em teoria, os phishers inevitavelmente perdem tráfego nessa etapa: nem todo mundo está disposto a inserir credenciais corporativas em um dispositivo pessoal. É aqui que os serviços automatizados de geração de código socorrem os cibercriminosos.

O Bubble se posiciona como uma plataforma no-code para o desenvolvimento de aplicativos da Web e móveis. Essencialmente, um usuário descreve o que precisa em uma interface visual e a plataforma gera uma solução finalizada. Os phishers adotaram essa tecnologia para criar aplicativos da Web cujos endereços, depois, eles incorporam em seus e-mails de phishing. Embora a função real desses aplicativos se resuma ao mesmo antigo redirecionamento automatizado para um site malicioso, há algumas nuances específicas em jogo.

Primeiro, o aplicativo da Web resultante é hospedado diretamente nos servidores da plataforma. O URL pronto para uso em um e-mail de phishing se parece com https://%name%.bubble.io/. Do ponto de vista das soluções de segurança, parece ser um site legítimo e antigo.

Em segundo lugar, o código desse aplicativo da Web não se parece com um redirecionamento típico. Para ser honesto, é difícil dizer com o que ele se parece. O código gerado por essa plataforma no-code é uma enorme mistura de JavaScript e estruturas isoladas de Shadow DOM (Document Object Model). Mesmo para um especialista, é difícil entender o que está acontecendo à primeira vista; é preciso analisar o código a fundo para entender como tudo funciona e com qual objetivo. Os algoritmos automatizados de análise de código da Web têm ainda mais chances de falhar, frequentemente chegando ao veredicto de que é apenas um site funcional e útil.

O que são essas plataformas de phishing e qual é o objetivo?

Os phishers atuais raramente desenvolvem e implementam novos truques do zero. A maioria usa kits de phishing, essencialmente pacotes do tipo “faça você mesmo o seu esquema fraudulento”, ou até mesmo plataformas de phishing como serviço em larga escala.

Essas plataformas fornecem aos invasores um kit de ferramentas sofisticado (e altamente frustrante) que está em constante evolução para melhorar a entrega de e-mail e burlar as defesas antiphishing. Por exemplo, essas ferramentas permitem que os invasores, entre muitas outras coisas, façam o seguinte: interceptem cookies de sessão; realizem phishing pelo Google Tarefas (uma tática que abordamos em uma postagem anterior); executem ataques de intermediário (AiTM) para validar a autenticação de dois fatores (2FA) e burlá-la em tempo real; criem sites de phishing equipados com honeypots e geofencing para se esconder dos rastreadores de segurança; e usem assistentes de IA para gerar e-mails de phishing únicos. Para piorar a situação, a infraestrutura dessas plataformas geralmente é hospedada em serviços perfeitamente legítimos como AWS, tornando suas táticas ainda mais difíceis de detectar.

As mesmas plataformas são usadas para criar a página de destino final que coleta credenciais. Nesse caso específico, o aplicativo da Web hospedado no Bubble redireciona as vítimas para um site com uma verificação da Cloudflare que imita a janela de login da Microsoft.

Aparentemente, no universo paralelo dos invasores, o Skype ainda é uma ferramenta de comunicação viável, mas fora isso, o site é bastante convincente.

Como proteger a sua empresa contra ataques de phishing sofisticados

No cenário digital atual, os funcionários precisam entender que as credenciais corporativas devem ser inseridas apenas em serviços e sites que inegavelmente pertencem à empresa. Você pode conscientizar sua equipe sobre ameaças cibernéticas modernas usando a Kaspersky Automated Security Awareness Platform para treinamento on-line.

É claro que até o funcionário mais cauteloso pode ocasionalmente morder a isca. Recomendamos equipar todas as estações de trabalho conectadas à Internet com soluções de segurança robustas que simplesmente bloquearão qualquer tentativa de visitar um site malicioso. Por fim, para reduzir o número de e-mails perigosos que ocupam as caixas de entrada corporativas, sugerimos implementar um produto de segurança de gateway com tecnologias antiphishing avançadas.

Temos discutido repetidamente esquemas de phishing em que invasores exploram vários servidores legítimos para enviar e-mails. Caso consigam sequestrar algum servidor de SharePoint, eles o usarão; caso contrário, se limitarão a enviar notificações por meio de um serviço gratuito, como o GetShared. Contudo, o enorme ecossistema do Google é um dos alvos favoritos dos criminosos, e a bola da vez é o Google Tarefas. Como de costume, este truque tem como principal objetivo driblar os filtros de e-mail, explorando a boa reputação do intermediário.

Como é o phishing no Google Tarefas

O destinatário recebe uma notificação legítima de um endereço @google.com com a mensagem: “Você tem uma nova tarefa”. Basicamente, os invasores tentam fazer parecer que a empresa passou a usar o gerenciador de tarefas do Google e, por isso, a vítima precisa clicar imediatamente em um link para preencher um formulário de verificação.

Para impedir que o destinatário tenha tempo para pensar se isso é necessário, a tarefa geralmente inclui um prazo curto e é marcada com alta prioridade. Ao clicar no link dentro da tarefa, a vítima é direcionada para uma URL que leva a um formulário onde deve inserir suas credenciais corporativas para “confirmar seu status de funcionário”. Essas credenciais, obviamente, são o objetivo final do ataque de phishing.

Como proteger as credenciais de funcionários contra phishing

Naturalmente, os funcionários devem ser alertados sobre a existência desse esquema. Por exemplo, compartilhando um link para o nosso acervo de postagens sobre como identificar o phishing. Mas, na realidade, o problema não é com nenhum serviço específico, mas sim com a cultura geral de segurança cibernética dentro de uma empresa. Os processos de fluxo de trabalho precisam ser claramente definidos para que todos os funcionários entendam quais ferramentas são realmente usadas pela empresa. Recomenda-se manter um documento corporativo público com a lista dos serviços autorizados e as pessoas ou departamentos responsáveis por eles. Isso proporciona aos funcionários um meio de verificar se aquele convite, tarefa ou notificação é legítimo. Além disso, nunca é demais lembrar que as credenciais corporativas devem ser inseridas somente em recursos internos da empresa. Para automatizar o processo de treinamento e manter sua equipe atualizada sobre as ameaças cibernéticas modernas, você pode usar uma ferramenta dedicada, como a Kaspersky Automated Security Awareness Platform.

Além disso, recomendamos reduzir a chegada de e-mails potencialmente perigosos às caixas de entrada dos funcionários com uma solução de segurança de gateway de e-mail especializada. Também é vital equipar todas as estações de trabalho conectadas à Web com um software de segurança. Mesmo que um invasor consiga enganar um funcionário, o produto de segurança bloqueará a tentativa de visitar o site de phishing, evitando o vazamento das credenciais corporativas.