A new Equation Editor exploit goes commercial, as maldoc attacks using it spike

There is a distinct point of maturation in the life cycle of an Office exploit: the point where it becomes generally available for the crimeware groups. Before that point the exploit has affected only a few selected victims of targeted attacks. From that point on it becomes widespread and threatens the general user population.

CVE-2018-0798, yet another Equation Editor vulnerability, reached this point of maturation around the end of June 2019.

How the exploit works

This exploit was used in targeted attacks we observed over the past several months, staying mostly under the radar. A detailed description of the vulnerability and its usage in targeted attacks, published earlier this month, explains the fundamentals.

At some point, someone appears to have integrated the exploit implementation that was used in the targeted attacks into a malicious Office document builder tool, with only minor changes. This sets the stage for much broader adoption of the attack technique.

The similarities are unmistakable: For example, the exploit trigger is exactly the same, and the shellcode (responsible for decrypting and executing the payload) is nearly identical to the shellcode used in the targeted attacks. Although CVE-2018-0798 is a relatively simple buffer overflow vulnerability, there are a few factors that make it difficult to tweak the exploit trigger itself, hence the virtually identical implementation.

The attack uses Equation Editor to put the malicious buffer through several transformations, and during processing the memory layout will be rather different from the file layout, which complicates analysis (and tweaking). Moreover, the attacker only controls the lower word of the return address on the stack. These complications make it less likely that the crimeware implementations will significantly change the exploit trigger.

The weaponized RTF files that are part of this campaign have a curious characteristic: some junk content near the header — content that fits a pattern normally seen in PDF files. It seems like the presence of this PDF header data content might be an attempt to confuse document filetype parsers in AV scanners.

Malicous RTF file with PDF fragments

An interesting feature in the shellcode is that the Windows API functions are not called from the shellcode itself. Instead, the clearerr function from the msvcrt.dll is patched with a short code that invokes the desired API function.

The original code of clearerr looks like this:

clearerr before the patch

This is replaced with a code that first checks if the API function was already hooked by a security software (the presence of 0xE9 and 0xEB indicate that the original entry of the API handler was patched, redirected to a monitoring function). If patching is detected, the shellcode will skip the first 5 bytes, the redirector, and jumps directly into the body of the function, done by the JMP EAX instruction.

clearerr after the patch

The result of this trick is that all of the Windows API calls that the shellcode uses will appear to be initiated from msvcrt.dll, which makes it a much less suspicious activity for behavior monitoring software.

The only significant change in the crimeware cases is the extracted payload. The APT samples were self-contained, the final payload was stored in the RTF file. On the other hand, in the crimeware samples the payload is a very simple downloader trojan, that fetches the final payload from a hardcoded URL.

In both cases the RTF file contains an embedded payload. There were a few different implementations in the APT cases. In the most simple of them, the payload is embedded into the RTF file without any encryption, as illustrated in the following picture where the MZ marker of the embedded executable is clearly visible in the RTF content.

Embedded executable payload’s characteristic MZ header is clearly visible in RTF

In the typical cases a one-byte XOR algorithm is used where the encryption key changes for each data byte. This makes it more difficult to recognize the embedded content which at first looks like some random data.

Embedded encrypted content in RTF

The crimeware builder chose a bogus (yet more convenient) implementation of the latter, more details in the next section.

The downloader component

The CVE-2018-0798 exploit triggers the shellcode that decrypts the payload (one-byte XOR algorithm, the key is 0xFC) and executes it. More precisely, the encryption algorithm is supposed to be a running key byte-wise XOR algorithm, but the APT sample that was used as a template for the crimeware builder used a bogus implementation of this algorithm.

Instead of key changing for each file position, the key changes only for the first 4 bytes, for the rest of the file it will be 0xFC. The following picture shows large blocks of 0xFC bytes in the embedded payload, which clearly reveals the encryption key.

The encrypted downloader with the URL in it

It should not be a coincidence that the crimeware builder chose this implementation. It is much easier to patch only the hardcoded encoded URL in the RTF file with fixed key, than to recode the embedded EXE and rebuild the RTF file for every sample.

The program downloads the hardcoded URL, saves it to the %APPDATA% folder, then executes it.

The critical Windows API function names are slightly obfuscated, the first character of the name is changed.

The same downloader executable is present in all recent crimeware sample; Only the hardcoded download URL changes. This is a good choice for the easy development of the builder.

What the malicious spam messages look like

We’ve observed several email distribution campaigns using these weaponized Office documents. The identified payload of the infection campaigns were all the “usual suspect” crimeware family payloads: Fareit, Lokibot, Formbook, or AzoruLT. The most widely distributed payload is Fareit.

We have observed that the spam campaigns use a wide selection of social engineering tropes.

Cargo arrival notice themed messages:

Fedex tracking was particularly popular:

And of course the order confirmation spam:

Lokibot was distributed using a “payment advice”-themed message:

And in messages that purported to contain a product inquiry:

The “give us your best price quote” email was used to distribute Formbook:

The vulnerability affects all Equation Editor versions (even the ones that were patched for CVE-2017-11882).

The patch for the CVE-2018-0802 exploit permanently “fixes” the vulnerability by eliminating the Equation Editor altogether.

Since the end of June, we’ve started to observe an increase in the use of this vulnerability in phishing campaigns. Since that time, we’ve observed about 200 new malicious RTF documents using this exploit. These documents are very similar to each other. This, and the large number of samples indicated that a builder tool that generates the weaponized .doc files probably is in circulation. We can expect the use of this exploit to rise, at least for the near future.

We have the following detections that provide generic coverage for the known samples:


Indicators of Compromise

File hashes for the samples analyzed in this report are on the SophosLabs Github.

Identity Theft on the Job Market

Identity theft is getting more subtle: “My job application was withdrawn by someone pretending to be me“:

When Mr Fearn applied for a job at the company he didn’t hear back.

He said the recruitment team said they’d get back to him by Friday, but they never did.

At first, he assumed he was unsuccessful, but after emailing his contact there, it turned out someone had created a Gmail account in his name and asked the company to withdraw his application.

Mr Fearn said the talent assistant told him they were confused because he had apparently emailed them to withdraw his application on Wednesday.

“They forwarded the email, which was sent from an account using my name.”

He said he felt “really shocked and violated” to find out that someone had created an email account in his name just to tarnish his chances of getting a role.

This is about as low-tech as it gets. It’s trivially simple for me to open a new Gmail account using a random first and last name. But because people innately trust email, it works.


Sym Mobile Threat: Invasores podem manipular seus arquivos de mídia do WhatsApp e Telegram

Arquivos de mídia do WhatsApp e do Telegram podem ser expostos e manipulados por agentes maliciosos, de acordo com pesquisa nova da equipe de Segurança de SOs Modernos da Symantec, que se concentra na proteção de endpoints e sistemas operacionais móveis. A falha de segurança, chamada “Media File Jacking” (sequestro de arquivos de mídia), afeta o WhatsApp para Android por padrão, e o Telegram para Android se certos recursos forem ativados. Ela é proveniente do lapso de tempo entre o momento em que os arquivos de mídia recebidos por meio dos aplicativos são gravados em disco e o momento em que são carregados na interface de conversa dos aplicativos para os usuários consumirem. Esse lapso de tempo crítico gera uma oportunidade para agentes maliciosos intervirem e manipularem arquivos de mídia sem o conhecimento do usuário. Se a falha de segurança for explorada, um invasor malicioso pode explorar e manipular informações confidenciais como fotos e vídeos pessoais, documentos corporativos, faturas e gravações de voz. Os invasores poderiam se aproveitar das relações de confiança entre um remetente e um destinatário ao usar esses aplicativos de mensagens instantâneas para ganho pessoal ou para criar caos.

No entanto, como já mencionamos no passado, nenhum código está imune a vulnerabilidades de segurança.

A ameaça de sequestro de arquivos de mídia é especialmente preocupante tendo em vista a percepção comum de que a nova geração de aplicativos de mensagens instantâneas é imune à manipulação de conteúdo e a riscos de privacidade graças à utilização de mecanismos de segurança como a criptografia de ponta a ponta. Os usuários geralmente confiam no fato de que aplicativos de mensagens instantâneas como WhatsApp e Telegram protegem a integridade tanto do remetente e do destinatário quanto do conteúdo da mensagem em si. Isso se contrasta com aplicativos e protocolos mais antigos como o SMS, que sabidamente são falsificados bem facilmente. No entanto, como já mencionamos no passado, nenhum código está imune a vulnerabilidades de segurança. Embora a criptografia de ponta a ponta seja um mecanismo eficiente para garantir a integridade das comunicações, ela não será suficiente se houver vulnerabilidades no nível do aplicativo no código. O que nossa pesquisa sobre o sequestro de arquivos de mídia demonstra é que os invasores podem manipular arquivos de mídia ao aproveitar falhas de lógica nos aplicativos que ocorrem antes e/ou depois que o conteúdo é criptografado para transmissão.

Analisamos o sequestro de arquivos de mídia, como essa falha pode ser explorada e seu impacto em potencial em mais detalhes abaixo.

Contexto técnico

Os aplicativos de Android podem armazenar arquivos e dados em dois locais de armazenamento: o interno e o externo. Arquivos salvos no armazenamento interno só podem ser acessados pelo próprio aplicativo e não por outros. Arquivos salvos em uma pasta púbica do armazenamento externo podem ser lidos e gravados globalmente; portanto, podem ser modificados por outros aplicativos ou usuários fora do controle do aplicativo original. De acordo com a documentação para desenvolvedores do Android, “o armazenamento interno é o ideal quando você quiser garantir que nem o usuário nem outros aplicativos possam acessar seus arquivos”. Por sua vez, “o armazenamento externo é o melhor lugar para arquivos que não requerem restrições de acesso e/ou que você queira compartilhar com outros aplicativos, ou permitir que o usuário acesse com um computador”.

Por padrão, o WhatsApp armazena arquivos de mídia recebidos por um dispositivo no armazenamento externo, no seguinte caminho: /storage/emulated/0/WhatsApp/Media/. No Telegram, se um usuário ativar o recurso “Salvar na Galeria”, assumindo que é uma ação segura e sem entender as consequências indiretas, o Telegram, de forma similar, vai armazenar arquivos em: /storage/emulated/0/Telegram/. Ambas as pastas são públicas. Os aplicativos carregam os arquivos recebidos das pastas públicas para que os usuários as vejam na interface de conversa, quando eles entrarem na conversa correspondente.

O fato de que os arquivos são gravados no armazenamento externo e carregados dele sem mecanismos de segurança adequados (veja mais informações na seção “Como os desenvolvedores de aplicativos podem se proteger da ameaça”, abaixo) permite que outros aplicativos com permissão de gravação no armazenamento externo coloquem em risco a integridade dos arquivos de mídia. A gravação no armazenamento externo (WRITE_EXTERNAL_STORAGE) é uma permissão comum solicitada por aplicativos Android; mais de um milhão de aplicativos no Google Play têm esse acesso. De fato, com base em nossos dados internos sobre aplicativos, descobrimos que, em média, quase 50% dos aplicativos de um dispositivo têm essa permissão.

Quando pesquisamos o fluxo do tratamento dos arquivos de mídia no WhatsApp e no Telegram, descobrimos que, entre o recebimento e gravação em disco dos arquivos no dispositivo (ETAPA 1) e o carregamento deles para os usuários os consumirem nos aplicativos (ETAPA 3), surge a oportunidade perfeita de exploração: um malware pode analisar instantaneamente os arquivos e manipulá-los (ou simplesmente os substituir por arquivos escolhidos pelo invasor) para algum ganho escuso (ETAPA 2).

Pense nisso como uma corrida entre o invasor e o aplicativo que carrega os arquivos. Se o invasor chegar primeiro aos arquivos – isso pode acontecer quase em tempo real se o malware monitorar as alterações nas pastas públicas – os destinatários verão os arquivos manipulados antes de sequer ver os originais. Além disso, a miniatura que aparecer na notificação que os usuários veem também exibirá a imagem ou arquivo manipulado, de forma que os destinatários não terão indicação alguma de que os arquivos foram alterados. Além disso, os dados podem ser manipulados no WhatsApp tanto ao enviar arquivos – indicando que o ataque foi lançado no dispositivo do remetente – quanto ao recebê-los – quando o ataque acontece no dispositivo do destinatário.

Como já discutimos, a permissão WRITE_EXTERNAL_STORAGE é muito comum entre aplicativos Android e, geralmente, os usuários não se incomodam em conceder a permissão como parte do processo de adoção dos aplicativos. Portanto, é possível que um usuário instale inadvertidamente o malware supracitado, ao contrário do que faria com outro aplicativo que peça permissões mais agressivas (como sensores críticos do dispositivo ou acesso a recursos); nesse caso, um usuário poderia ser mais cuidadoso antes de aceitar a instalação.

Além disso, a vulnerabilidade de sequestro de arquivos de mídia indica um problema maior: o uso inseguro de recursos de armazenamento por parte dos desenvolvedores de aplicativos. Em 2018, pesquisadores descobriram uma falha similar, relacionada à forma com que alguns aplicativos Android utilizam o armazenamento externo, abrindo a porta para a manipulação de dados por parte dos invasores. O ataque chamado Man-in-the-Disk pode ocorrer quando os desenvolvedores deixam de tomar precauções de segurança ao armazenar arquivos no armazenamento externo. Isso pode resultar na instalação silenciosa de aplicativos potencialmente maliciosos e a negação de serviço para aplicativos.


Vamos examinar algumas situações nos quais invasores podem explorar essa vulnerabilidade para fraudar vítimas:

1. Manipulação de imagens. Nesta situação, um aplicativo aparentemente inocente, mas realmente malicioso, baixado pelo usuário pode manipular fotos pessoais quase em tempo real, sem a vítima saber. O aplicativo é executado em segundo plano e realiza um ataque de sequestro de arquivos de mídia enquanto a vítima usa o WhatsApp. Ele monitora fotos recebidas pelo aplicativo de mensagens, identifica rostos nas fotos e os substitui por outras coisas, como outros rostos ou objetos. Um usuário do WhatsApp pode enviar uma foto de família para um de seus contatos, mas o destinatário vê uma foto modificada. Embora esse ataque possa parecer trivial e meramente irritante, ele demonstra a possibilidade de manipular imagens dinamicamente. Em uma situação similar com consequências mais amplas, os arquivos de mídia de um candidato a cargo político ou um executivo de empresa poderiam ser manipulados, permitindo aos invasores extorquir ou incriminar seus alvos.

[embedded content]

2. Manipulação de pagamentos. Em um dos ataques de sequestro de arquivos de mídia mais danosos, um agente malicioso pode manipular uma fatura enviada por um fornecedor a um cliente, para forçar um pagamento a uma conta falsa. Assim como na situação anterior, um aplicativo aparentemente legítimo, mas na verdade malicioso, procura arquivos de fatura em PDF recebidos via WhatsApp e então programaticamente troca as informações de conta bancária exibidas na fatura pelas do agente malicioso. O cliente recebe a fatura que estava esperando, mas não sabe que ela foi alterada. Até a fraude ser descoberta, o dinheiro pode estar totalmente fora de alcance. Para piorar, a falsificação de faturas pode ser distribuída de forma ampla e não direcionada, visando quaisquer faturas a serem manipuladas, afetando várias vítimas que usam aplicativos de mensagens como o WhatsApp para fazer negócios.

[embedded content]

3. Falsificação de mensagens de áudio. Nesta situação, um invasor explora as relações de confiança entre funcionários de uma empresa. Um CEO envia ao CFO uma mensagem de áudio via WhatsApp, solicitando uma apresentação de slides atualizada para uma reunião de conselho na semana seguinte. O invasor, usando reconstrução de voz por meio de tecnologia de deep learning – algo que está se tornando cada vez mais viável hoje em dia – altera o arquivo de áudio original para comunicar ao CFO, com a própria voz do CEO, que é preciso transferir um pagamento imediatamente para uma entidade fictícia, que na verdade é o invasor. O agente malicioso não só manipula a comunicação do CEO como dá um passo além e reconstrói a voz dele, gerando uma técnica de fraude muito eficiente. A mensagem original do CEO é substituída quando chega ao celular do CFO. O que o CFO ouve, no fim das contas, é uma mensagem de áudio crível de seu chefe com a ordem de fazer um pagamento, algo que um funcionário desavisado pode facilmente ver como uma solicitação legítima.

[embedded content]

4. Outro exemplo interessante em que podemos encontrar um ataque de sequestro de arquivos de mídia é o das fake news. No Telegram, administradores usam o conceito de “canais” para transmitir mensagens a um número ilimitado de assinantes que consomem o conteúdo publicado. Um invasor pode alterar os arquivos que aparecem no feed do canal em tempo real. Vamos considerar, por exemplo, uma emissora de notícias confiável que mantém um canal no Telegram. Os assinantes confiam no canal para obter notícias críveis. Um invasor pode comunicar mentiras no canal ao manipular os arquivos de mídia recebidos ali. O interessante é que isso acontece sem o conhecimento e consentimento nem do dono do canal, nem da vítima final. Esse exemplo ilustra como tanto o remetente quanto o destinatário podem ser prejudicados pelo ataque: os destinatários consomem fake news e a reputação ou a credibilidade do dono do canal é abalada.

Como os desenvolvedores de aplicativos podem se proteger da ameaça

Como mencionamos antes, o WhatsApp salva arquivos no armazenamento externo automaticamente, enquanto o Telegram faz isso quando o recurso “Salvar na Galeria” é ativado. No entanto, em ambos o casos, nenhum dos aplicativos implementou qualquer medida para proteger seus usuários de um ataque de sequestro de arquivos de mídia.

Para garantir que os arquivos de mídia fiquem a salvo de agentes maliciosos, recomendamos as seguintes medidas:

  • Valide a integridade dos arquivos: em um arquivo de metadados, armazene um valor de hash para cada arquivo de mídia recebido antes de gravá-lo em disco. Então, confirme que o arquivo não foi alterado (ou seja, o hash é o mesmo) antes que o arquivo de mídia seja carregado pelo aplicativo na conversa correspondente para os usuários verem. Essa etapa pode ajudar os desenvolvedores a validar que os arquivos não foram manipulados antes do carregamento. Essa abordagem faz o equilíbrio entre as necessidades de segurança (proteção contra ataques de sequestro de arquivos de mídia) e de funcionalidade (como o suporte a aplicativos de backup de terceiros) dos aplicativos de mensagens.
  • Armazenamento interno: se for possível, armazene os arquivos de mídia em uma pasta não pública, como o armazenamento interno. Alguns aplicativos de mensagens instantâneas já optaram por essa medida.
  • Criptografia: esforce-se para criptografar arquivos confidenciais, como geralmente é feito com as mensagens de texto nas soluções de mensagens modernas. Essa medida, assim como a anterior, dará aos arquivos melhor proteção contra exposição e manipulação. A desvantagem é que outros aplicativos, como os de backup de fotos, não poderão acessar facilmente esses arquivos.

Com o lançamento do Android Q, o Google planeja fazer mudanças na forma com que os aplicativos acessam arquivos no armazenamento externo do dispositivo. O armazenamento com escopo planejado para o Android é mais restrito, o que pode ajudar a combater ameaças como a falha no WhatsApp/Telegram que descobrimos. Com o armazenamento com escopo, os aplicativos terão sua própria área de armazenamento em uma pasta específica para cada um, mas não poderão acessar arquivos na partição de armazenamento inteira, a menos que o usuário conceda uma permissão explícita. Embora isso tenha potencial para melhorar a proteção da privacidade do usuário, também acarreta mudanças importantes na forma com que milhões de aplicativos utilizam o armazenamento externo. Em parte por causa desses desafios, o Google anunciou recentemente que planeja colocar a API em vigor somente em 2020, na próxima versão principal da plataforma. Mesmo nesse prazo, o impacto da mudança levará tempo para surgir, devido à fragmentação de versões do sistema operacional Android.

Processo de revelação

A Symantec notificou o Telegram e o Facebook/WhatsApp sobre a vulnerabilidade de sequestro de arquivos de mídia.


Os mecanismos de detecção de malware da Symantec, que capacitam o Symantec Endpoint Protection Mobile (SEP Mobile) e o Norton Mobile Security, detectam aplicativos que exploram a vulnerabilidade descrita.

Sendo assim, as empresas que utilizam o SEP Mobile e os usuários do Norton Mobile Security se beneficiam da análise profunda de aplicativos e da detecção de comportamento malicioso, suspeito e indesejado que os mecanismos proporcionam e já estão protegidos contra a ameaça descrita.


Desativando o armazenamento de arquivos de mídia no armazenamento externo

Os usuários dos aplicativos de mensagens podem mitigar o risco de sequestro de arquivos de mídia desativando o recurso que salva os arquivos no armazenamento eterno. Mostramos abaixo como fazer isso no WhatsApp e no Telegram.

WhatsApp: Configurações -> Conversas -> Visibilidade de mídia

Telegram: Configurações -> Configurações de Chats -> Salvar na Galeria

About the Author

Yair Amit

VP & CTO, Modern OS Security

He leads the company’s research, vision and R&D center for securing iOS & Android devices, also envisioning the security model of future desktop operating systems. Working in the security industry for the past 15 years, his work has yielded dozens of patents.

About the Author

Alon Gat

Software Engineer

Alon is a Software Engineer at Symantec’s Modern OS Security team, where he leads backend development projects. He has over 10 years of development and architecture experience, with a focus on cyber security. Alon also enjoys coding with his new-born son.