DirtyMoe: certificado de assinatura de código

Um artigo sobre o malware DirtyMoe analisa como o Windows opera com uma assinatura de código de um driver que é assinado com certificados roubados e como eles são usados ​​para assinar outro software malicioso, incluindo outros drivers do Windows.

O malware DirtyMoe usa um driver assinado com um certificado revogado que pode ser carregado diretamente no kernel do Windows. Portanto, um dos objetivos é analisar como o Windows funciona com uma assinatura de código de drivers do Windows. Da mesma forma, também estaremos interessados ​​na verificação de assinatura de código de aplicativos de modo de usuário, uma vez que o controle de conta de usuário (UAC) não bloqueia a execução do aplicativo, mesmo que este também seja assinado com um certificado revogado. O segundo objetivo é uma análise estatística dos certificados que assinam o driver DirtyMoe porque os certificados também são usados ​​para assinar outro software malicioso. Nós nos concentramos na determinação da origem e prevalência do certificado e em uma análise rápida dos 10 principais softwares assinados com esses certificados.

Ao contrário do que muitas vezes se supõe, o Windows carrega um driver assinado com um certificado revogado. Além disso, os resultados indicam que o UAC não verifica a revogação online, mas apenas por meio do armazenamento local do sistema, que é atualizado manualmente por um usuário. Os certificados DirtyMoe são usados ​​para assinar muitos outros softwares e o número de incidentes ainda está crescendo. Além disso, Taiwan e a Rússia parecem ser os mais afetados por essas assinaturas falsas.

De maneira geral, os certificados analisados ​​podem ser declarados maliciosos e devem ser monitorados. O UAC contém uma vulnerabilidade significativa em sua rotina de verificação de assinatura de código. Portanto, além de evitar o download de fontes usuais, os usuários do Windows também não devem confiar totalmente apenas nas proteções integradas. Devido à falha na verificação do certificado, a verificação manual do certificado é recomendada para executáveis ​​que requerem privilégios elevados.

1. Introdução

O malware DirtyMoe é um backdoor malicioso e complexo projetado para ser modularizado, indetectável e indetectável. O principal objetivo do DirtyMoe é o criptojacking e os ataques DDoS. Basicamente, ele pode fazer tudo o que os invasores quiserem. O estudo anterior, publicado em DirtyMoe: Introdução e Visão Geral , mostrou que DirtyMoe também emprega vários mecanismos de autoproteção e anti-forenses. Uma das salvaguardas mais significativas, defender DirtyMoe, é um rootkit. O que é significativo sobre o uso do rootkit é que ele oferece técnicas avançadas para ocultar atividades maliciosas na camada do kernel. Como o DirtyMoe é um malware complexo e passou por um desenvolvimento de longo prazo, os autores do malware também implementaram vários mecanismos de rootkit. The DirtyMoe: driver rootkitA postagem examina a funcionalidade do driver DirtyMoe em detalhes.

No entanto, outro aspecto importante do driver do rootkit é uma assinatura digital. Os rootkits geralmente exploram o sistema usando um driver do Windows. A Microsoft começou a exigir a assinatura de código com certificados em que um fornecedor de driver é confiável e verificado por uma autoridade de certificação (CA) em que a Microsoft confia. No entanto, o Windows não permite o carregamento de drivers não assinados desde o Windows Vista de 64 bits e versões posteriores. Embora o princípio da assinatura do código seja correto e seguro, o Windows permite carregar um driver cujo emissor do certificado revogou explicitamente o certificado usado. As razões para esse comportamento são várias, seja em termos de desempenho ou compatibilidade com versões anteriores. O ponto fraco desse gerenciamento de certificado é se os autores de malware roubam qualquer certificado que foi verificado pela Microsoft e revogado pela CA no passado. Em seguida, os autores do malware podem usar esse certificado para fins maliciosos. É justamente o caso da DirtyMoe, que ainda assina seu motorista com certificados roubados. Além disso, os usuários não podem afetar a verificação do codesign por meio do controle de conta do usuário (UAC), uma vez que os drivers são carregados no modo kernel.

Motivados pelo carregamento de drivers com certificados revogados, os principais problemas abordados neste artigo são a análise do mecanismo de funcionamento do Windows com assinatura de código no kernel e modo de usuário; e análise detalhada de certificados usados ​​para assinatura de código do driver DirtyMoe.

Este documento primeiro apresenta uma breve visão geral do UAC e da assinatura de código dos drivers do Windows. Existem também várias observações sobre o princípio do UAC e como o Windows gerencia a lista de certificados revogados (CRL). A parte restante do artigo visa revisar em detalhes as informações disponíveis sobre os certificados que foram usados ​​para codificar as assinaturas do driver DirtyMoe.

Até agora, três certificados diferentes foram descobertos e confirmados por nosso grupo de pesquisa como maliciosos. Os drivers assinados com esses certificados podem ser carregados apesar de sua revogação no kernel do Windows de 64 bits. Um objetivo inicial da última parte é uma análise dos certificados suspeitos do ponto de vista estatístico. Existem três pontos de vista que estudamos. O primeiro é a origem geológica das amostras capturadas assinadas com o certificado malicioso. O segundo aspecto é o número de amostras capturadas, incluindo um fator de predição para cada certificado. O último quadro de referência selecionado é uma visão geral estatística sobre um tipo de software assinado porque os autores do malware usam os certificados para assinar vários softwares, por exemplo, software crackeado ou outros aplicativos de usuário populares que foram corrigidos com uma carga maliciosa. Selecionamos os 10 melhores softwares assinados com certificados revogados e realizamos uma análise rápida. As categorias deste software nos ajudam a determinar o tipo de software visado principalmente que os autores de malware assinaram. Outro escopo significativo desta pesquisa é procurar informações sobre empresas cujos certificados provavelmente foram vazados ou roubados.

2. Antecedentes

As assinaturas digitais são capazes de fornecer evidências da identidade, origem e status dos documentos eletrônicos, incluindo software. O usuário pode verificar a validade das assinaturas com a autoridade de certificação. Os desenvolvedores de software usam assinaturas digitais para uma assinatura de código de seus produtos. Os autores do software garantem através da assinatura que os executáveis ​​ou scripts não foram corrompidos ou alterados desde que os produtos foram assinados digitalmente. Os usuários de software podem verificar a credibilidade dos desenvolvedores de software antes da execução ou instalação.

Cada software assinado por código fornece informações sobre seu emissor e uma URL aponta para a lista de certificados revogados (CRL) atual, conhecida como ponto de distribuição de CRL. O Windows pode seguir o URL e verificar a validade do certificado usado. Se a verificação falhar, o Controle de Conta de Usuário (UAC) bloqueia a execução do software em que a assinatura de código não é válida. Igualmente importante é a assinatura de código dos drivers do Windows que usam uma abordagem diferente para verificação de assinatura digital. Enquanto as assinaturas de software do modo de usuário são opcionais, o driver do Windows deve ser assinado por uma CA em que o Windows confie. A assinatura do driver é obrigatória desde o Windows Vista de 64 bits.

2.1 Controle de conta de usuário e assinatura digital

O Windows 10 solicita ao usuário uma confirmação se o usuário deseja executar o software com alta permissão. O Controle de Conta de Usuário (UAC) deve ajudar a evitar que os usuários executem inadvertidamente software malicioso ou outros tipos de alterações que podem desestabilizar o sistema Windows. Além disso, o UAC usa codificação de cores para diferentes cenários – azul para uma assinatura verificada, amarelo para um não verificado e vermelho para um certificado rejeitado; veja a Figura 1 .

Figura 1 : UAC de software verificado, não verificado e rejeitado que requer os privilégios mais altos

Infelizmente, os usuários são o elo mais fraco na cadeia de segurança e muitas vezes optam por ignorar esses avisos. O próprio Windows não oferece proteção 100% contra editores desconhecidos e até mesmo certificados revogados. Portanto, a ignorância e a desatenção do usuário auxiliam os autores de malware.

2.2 Drivers do Windows e assinatura digital

A política de certificado é diametralmente diferente para drivers do Windows em comparação com outro software de modo de usuário. Embora o software em modo de usuário não exija assinatura de código, a assinatura de código é obrigatória para um driver do Windows; além disso, uma autoridade de certificação confiável pela Microsoft deve ser usada. No entanto, a política de certificados para os drivers do Windows é bastante complicada, como demonstra o MSDN [1] .

2.2.1 Assinatura do Motorista

Historicamente, os drivers de 32 bits de todos os tipos não eram assinados, por exemplo, drivers para impressoras, scanners e outros hardwares específicos. O Windows Vista trouxe uma nova política de assinatura, mas a Microsoft não conseguia parar de oferecer suporte aos drivers legados devido à compatibilidade com versões anteriores. No entanto, o Windows Vista de 64 bits e posterior deve exigir drivers assinados digitalmente de acordo com a nova política. Conseqüentemente, os drivers de 32 bits não precisam ser assinados, pois esses drivers não podem ser carregados nos kernels de 64 bits. A assinatura de código de drivers de 32 bits é uma boa prática, embora a política de certificados não exija isso.

A Microsoft não tem capacidade para assinar cada driver, mais precisamente arquivo, fornecido por terceiros. Portanto, uma política de certificado cruzado é usada para fornecer um instrumento para criar uma cadeia de confiança. Esta política permite a liberação de um certificado subordinado que constrói a cadeia de confiança da autoridade de certificação raiz da Microsoft para várias outras CAs que a Microsoft credenciou. A lista de certificados cruzados atual está documentada em [2] . Na verdade, a assinatura final do driver é feita com um certificado emitido pela CA subordinada, que a Microsoft autorizou.

Os exemplos da cadeia de certificação ilustram a Figura 2 e a seguinte saída de signtool;
veja a Figura 3 .

Figura 2 : Cadeia de certificação de um driver Avast

Figura 3 : Saída de signtool.exe para um driver Avast

2.2.2 Verificação da Assinatura do Motorista

Para software em modo de usuário, as assinaturas digitais são verificadas remotamente por meio da lista CRL obtida dos emissores de certificado. A verificação de assinatura dos drivers do Windows não pode ser realizada online em comparação com o software do modo de usuário devido à ausência de conexão de rede durante a inicialização do kernel. Além disso, a inicialização do kernel deve ser rápida e uma abordagem razoável para lidar com a verificação de assinatura é implementar uma versão leve do algoritmo de verificação.

O sistema Windows possui certificados raiz codificados de várias CAs e, portanto, pode verificar a cadeia de certificados de assinatura offline. No entanto, o kernel não tem chance de autenticar assinaturas contra CRLs. O mesmo se aplica a certificados expirados. Em conjunto, essa abordagem é implementada devido ao desempenho do kernel e à compatibilidade com versões anteriores do driver. Portanto, certificados vazados e comprometidos de um fornecedor de driver confiável causam um grave problema para a segurança do Windows.

3. CRL, UAC e drivers

Como foi apontado na seção anterior, a CRL contém uma lista de certificados revogados. O UAC deve verificar a cadeia de confiança do software em execução que requer permissão superior. A caixa de diálogo do UAC mostra o status da verificação do certificado. Ele pode terminar com dois status, por exemplo, editor verificado ou editor desconhecido [3] , consulte a Figura 1 .

No entanto, temos um cenário em que o software é assinado com um certificado revogado e a execução não é bloqueada pelo UAC. Além disso, a assinatura do código é marcada como o editor desconhecido (UAC com o título amarelo), embora o certificado esteja em CRL.

3.1 Serviços de criptografia e armazenamento CRL

Os serviços criptográficos confirmam as assinaturas dos arquivos do Windows e armazenam as informações dos arquivos na C:\Users\<user>\AppData\LocalLow\Microsoft\CryptnetUrlCachepasta, incluindo a CRL do arquivo verificado. A CryptnetUrlCachepasta (cache) é atualizada, por exemplo, se os usuários checam manualmente as assinaturas digitais por meio de “ Propriedades -> Assinatura Digital ” ou por meio das signtoolferramentas, conforme ilustram a Figura 3 e a Figura 4 . A verificação do certificado processa toda a cadeia de confiança, incluindo CRL e possíveis depósitos de revogações na pasta de cache.

Figura 4 : Lista de assinatura digital via Explorer

Outro armazenamento de CRLs pode ser Certificate Storageacessado por meio da Ferramenta do Gerenciador de Certificados; veja a
Figura 5 . Este armazenamento pode ser gerenciado pelo administrador local ou domínio.

Figura 5 : Ferramenta de gerenciamento de certificados

3.2 Verificação de CRL pelo UAC

O próprio UAC não verifica a assinatura do código, ou mais precisamente a cadeia de confiança, online; é provavelmente devido ao desempenho do sistema. A verificação do código do UAC verifica a assinatura e a CRL por meio do CryptnetUrlCachee do sistema Certificate storage. Portanto, o UAC marca o software malicioso, assinado com o certificado revogado, como o editor desconhecido porque CryptnetUrlCachenão está atualizado inicialmente.

Suponha que o usuário adicione a CRL apropriada Certificate Storagemanualmente usando este comando:
certutil -addstore -f Root CSC3-2010.crl

Nesse caso, o UAC detectará com êxito o software como suspeito e exibirá esta mensagem: “ Um administrador bloqueou você de executar este aplicativo. ”Sem assistência de serviços criptográficos e, portanto, offline.

A atualização do Windows não inclui CRLs de autoridades de certificação cruzada que a Microsoft autorizou para a assinatura de códigos de arquivos do Windows. Este fato foi verificado por meio de atualizações e versões do Windows da seguinte forma:

• Ferramenta de remoção de software malicioso do Windows x64 – v5.91 (KB890830)
• 2021-06 Atualização cumulativa para Windows 10 versão 20H2 para sistema baseado em x64 (KB5003690)
• Versão do Windows: 21H1 (OB Build 19043.1110)

Em resumo, o UAC verifica as assinaturas digitais por meio do armazenamento local do sistema de CRL e não verifica a assinatura do código online.

3.3 Driver e CRL do Windows

Voltando rapidamente ao código de código do driver do Windows que é exigido pelo kernel. O kernel pode verificar a assinatura offline, mas não pode verificar a CRL, pois os serviços criptográficos e o acesso à rede não estão disponíveis no momento da inicialização.

Passando agora para as evidências experimentais na verificação CRL offline de drivers. É evidente no caso descrito na Seção 3.2 que o UAC pode verificar a CRL offline. Portanto, a hipótese testada é que o kernel do Windows pode verificar a CRL de um driver carregado offline se uma CRL apropriada estiver armazenada em Certificate Storage. Usamos o malware DirtyMoe para implantar o driver malicioso que é assinado com o certificado revogado. A CRL correspondente do certificado revogado foi importada para Certificate Storage. No entanto, o driver ainda estava ativo após a reinicialização do sistema. Indica que o rootkit foi carregado com sucesso no kernel, embora o certificado do driver tenha sido revogado e a CRL atual tenha sido importada paraCertificate Storage. Existe uma grande probabilidade de que o kernel evite a verificação da CRL até mesmo no armazenamento local.

4. Análise de certificado

O escopo desta pesquisa são três certificados como segue:

Pequim Kate Zhanhong Technology Co., Ltd.
Válido de: 28-Nov-2013 (2:00:00)
Válido para: 29-Nov-2014 (1:59:59)
SN:3c5883bd1dbcd582ad41c8778e4f56d9
Impressão digital:02a8dc8b4aead80e77b333d61e35b40fbbb010a0
Status de revogação: Revogado em 22 de maio de 2014 (9:28: 59)
Ponto de distribuição de CRL: http://cs-g2-crl.thawte.com/ThawteCSG2.crl
IoCs:
88D3B404E5295CF8C83CD204C7D79F75B915D84016473DFD82C0F1D3C375F968
376F4691A80EE97447A66B1AF18F4E0BAFB1C185FBD37644E1713AD91004C7B3
937BF06798AF9C811296A5FC1A5253E5A03341A760A50CAC67AEFEDC0E13227C

Beijing Founder Apabi Technology Limited
Válido de: 22 de maio de 2018 (2:00:00)
Válido até: 29 de maio de 2019 (14:00:00)
SN:06b7aa2c37c0876ccb0378d895d71041
Impressão digital:8564928aa4fbc4bbecf65b402503b2be3dc60d4d
Status de revogação: Revogado em 22 de maio de 2018 (2:00:01)
Ponto de distribuição de CRL: http://crl3.digicert.com/sha2-assured-cs-g1.crl
IoCs:
B0214B8DFCB1CC7927C5E313B5A323A211642E9EB9B9F081612AC168F45BF8C2
5A4AC6B7AAB067B66BF3D2BAACEE300F7EDB641142B907D800C7CB5FCCF3FA2A
DA720CCAFE572438E415B426033DACAFBA93AC9BD355EBDB62F2FF01128996F7

Shanghai Yulian Software Technology Co., Ltd. (上 海域 联 软件 技术 有限公司)
Válido de: 23-mar-2011 (2:00:00)
Válido para: 23-mar-2012 (1:59:59)
SN:5f78149eb4f75eb17404a8143aaeaed7
Impressão digital:31e5380e1e0e1dd841f0c1741b38556b252e6231
Status de revogação: Revogado em 18 de abril de 2011 (10:42:04)
Ponto de distribuição de CRL: http://csc3-2010-crl.verisign.com/CSC3-2010.crl
IoCs:
15FE970F1BE27333A839A873C4DE0EF6916BD69284FE89F2235E4A99BC7092EE
32484F4FBBECD6DD57A6077AA3B6CCC1D61A97B33790091423A4307F93669C66
C93A9B3D943ED44D06B348F388605701DBD591DAB03CA361EFEC3719D35E9887

4.1 Beijing Kate Zhanhong Technology Co., Ltd.

Não encontramos nenhuma informação relevante sobre a empresa Beijing Kate Zhanhong Technology . O Avast capturou 124 ocorrências assinadas com os certificados Beijing Kate de 2015 a 2021. No entanto, a previsão para 2021 indica uma tendência de queda; veja a Figura 6 . Apenas 19 resultados foram capturados nos primeiros 7 meses deste ano, então a previsão para este ano (2021) é de aprox. 30 acessos assinados com este certificado.

Figura 6 : Número de acertos e previsão de Beijing Kate

Noventa e cinco por cento do total de acessos foram localizados na Ásia; consulte a Tabela 1 para obter a distribuição detalhada do GeoIP dos últimos anos significativos.

Tabela 1 : Distribuição geológica dos certificados Beijing Kate

Os autores de malware usam esse certificado para assinar drivers do sistema Windows em 61% das ocorrências monitoradas, e os executáveis ​​do Windows são assinados em 16% das ocorrências. No geral, parece que os autores do malware se concentram nos drivers do Windows, que devem ser assinados com todos os certificados verificados.

4.2 Fundador de Pequim Apabi Technology Limited

O fundador de Pequim, Apabi Technology Co., Ltd. foi fundado em 2001 e é um provedor de serviços e tecnologia de publicação digital profissional subordinado ao Grupo de Crédito Fundador da Universidade de Pequim. A empresa também desenvolve software para leitura de e-books como o Apabi Reader [4] .

O certificado de Fundador de Pequim foi considerado malicioso em 166 acessos com 18 SHAs exclusivos. A amostra mais representada é um executável chamado “Linking.exe” que foi atingido em 8 países, a maioria na China; exatamente 71 casos. A primeira ocorrência e o pico de acertos foram observados em 2018. A incidência de acertos foi uma ordem de magnitude menor nos anos anteriores, e prevemos um aumento da ordem de dezenas de acertos, conforme ilustra a Figura 7 .

Figura 7 : Número de acertos e previsão do Fundador de Pequim

4.3 Shanghai Yulian Software Technology Co., Ltd.

A Shanghai Yulian Software Technology Co. foi fundada em 2005, que fornece garantias de segurança de rede para operadoras de rede. O seu portfólio cobre serviços na área de segurança da informação, nomeadamente e-commerce, segurança da informação empresarial, serviços de segurança e integração de sistemas [5] .

O certificado da Shanghai Yulian Software é o mais difundido em comparação com outros. O Avast obteve esse certificado em 10.500 casos nos últimos oito anos. Além disso, a prevalência de amostras assinadas com este certificado está aumentando, embora o certificado tenha sido revogado por seu emissor em 2011. Além disso, o pico de ocorrência foi em 2017 e 2020. Assumimos um aumento linear da incidência e uma previsão para 2021 é baseado nos primeiros meses de 2021. E, portanto, a previsão para 2021 indica que este certificado revogado também dominará em 2021; veja a tendência na Figura 8 . Não temos registro do que causou a queda significativa em 2018 e 2019.

Figura 8 : Número de acessos e previsão do Shanghai Yulian Software

Os certificados anteriores dominam apenas na Ásia, mas o certificado da Shanghai Yulian Software prevalece na Ásia e na Europa, como ilustra a Figura 9 . Os países dominantes são Taiwan e Rússia. China e Tailândia estão em uma estreita dobradiça; consulte a Tabela 2 para obter a distribuição detalhada dos países, vários países selecionados.

Figura 9 : Distribuição de acessos no ponto de vista do continente para o Shanghai Yulian Software

Tabela 2 : Distribuição geológica do certificado do Software Shanghai Yulian

Como em casos anteriores, os autores de malware têm usado os certificados do Shanghai Yulian Software para assinar drivers do Windows em 75% das ocorrências. Outros 16% foram usados ​​para executáveis ​​EXE e DLL; consulte a Figura 10 para obter a distribuição detalhada.

Figura 10 : Distribuição de tipos de arquivo para o Shanghai Yulian Software

Figura 11 : Distribuição do motorista Denuvo entre os países

4) WsAP-Filmora.dll

Wondershare Filmora é um editor de vídeo simples que possui versões gratuitas e pagas [11] . Portanto, há um lugar para rachaduras e atividades de malware. Todos os caminhos de sucesso apontam para atividade de crack em que os usuários tentaram contornar a versão de teste do editor Filmora. Nenhum caminho PDB foi capturado; portanto, não podemos determinar os autores do malware que receberam outras amostras assinadas com os mesmos certificados. WsAP-Filmora.dll é amplamente difundido em todo o mundo (73 países); veja a distribuição detalhada dos países na Figura 12 .

Figura 12 : Distribuição do Filmora DLL entre os países

Figura 13 : Assinaturas digitais do cliente μTorrent original e malicioso

A assinatura maliciosa contém caracteres chineses, embora a prevalência da amostra aponte para a Rússia. Além disso, a China não tem sucessos. A Figura 14 ilustra uma distribuição detalhada do aplicativo malicioso μTorrent por país.

Figura 14 : Distribuição do cliente µTorrent entre os países

4.3.2 Rootkit YDArk

Encontramos um repositório Github que contém uma ferramenta YDArk que monitora as atividades do sistema por meio de um driver assinado com o certificado comprometido. O último sinal foi feito em maio de 2021; portanto, parece que o certificado roubado ainda está em uso, apesar do fato de ter sido revogado há 10 anos. O repositório é gerenciado por dois usuários, ambos localizados na China. O driver YDArk foi assinado com os certificados de comprometimento por ScriptBoy2077 , que admitiu que o certificado está comprometido e expirou por esta nota:

“ Assinei o arquivo .sys com um certificado comprometido e expirado, pode ser útil para meus amigos que não sabem como carregar um driver não assinado. ”

A chave privada do certificado comprometido não está disponível no clearnet. Procuramos pelo nome do certificado, número de série, hashes, etc .; portanto, podemos presumir que o certificado e a chave privada podem estar localizados na darknet e compartilhados dentro de um grupo restrito de autores de malware. Consequentemente, a relação entre YDArk, mais precisamente ScriptBoy2077, e o driver DirtyMoe é atraente. Além disso, os servidores C&C DirtyMoe também estão localizados na maioria dos casos na China, conforme descrito em DirtyMoe: Introdução e Visão Geral .

5. Discussão

A descoberta mais interessante desta pesquisa foi que o Windows permite carregar drivers assinados com certificados revogados, mesmo se uma CRL apropriada estiver armazenada localmente. O Windows verifica com êxito a revogação de assinatura offline para aplicativos de modo de usuário por meio do UAC. No entanto, se o Windows carregar drivers com o certificado revogado no kernel, apesar da CRL atualizada, é evidente que o kernel do Windows evita a verificação da CRL. Portanto, é provável que a implementação ausente da verificação CRL seja omitida devido ao desempenho no momento da inicialização. É uma hipótese, portanto, pesquisas adicionais precisarão ser realizadas para compreender totalmente o processo e a implementação do carregamento do driver e da verificação da CRL.

Outra descoberta importante foi que a CRL online não é consultada pelo UAC na verificação de assinaturas digitais para aplicativos de modo de usuário, que requerem permissão superior. É um tanto surpreendente que o UAC bloqueie os aplicativos apenas se o usuário verificar manualmente a cadeia de confiança antes de o aplicativo ser executado; em outras palavras, se a CRL atual for baixada e atualizada antes da execução do UAC. Portanto, a evidência sugere que nem o UAC não protege totalmente os usuários contra softwares mal-intencionados que foram assinados com certificados revogados. Conseqüentemente, os usuários devem ter cuidado quando o UAC aparecer. 

O driver do DirtyMoe vem assinando com três certificados que analisamos nesta pesquisa. As evidências sugerem que os certificados do DirtyMoe são usados ​​para a assinatura de código de outro software potencialmente malicioso. É difícil determinar quantos autores de malware usam os certificados revogados com precisão. Classificamos alguns clusters de amostras SHA exclusivas que apontam para os mesmos autores de malware por meio de caminhos PDB. No entanto, muitos outros grupos não podem ser identificados de forma inequívoca. Há uma probabilidade de que os autores de malware que usam os certificados revogados sejam um grupo restrito; no entanto, um trabalho adicional que compare as semelhanças de código do software assinado é necessário para confirmar esta suposição. Esta hipótese é apoiada pelo fato de que as amostras estão predominantemente concentradas em Taiwan e na Rússia em um horizonte de tempo tão longo. Além disso, chaves privadas vazadas geralmente estão disponíveis na Internet, mas os certificados revogados não têm registro. Isso pode significar que as chaves privadas são repassadas dentro de uma determinada comunidade de autores de malware.

De acordo com esses dados, podemos inferir que o certificado Shanghai Yulian Software Technology é o uso mais comum e está em ascensão, embora o certificado tenha sido revogado há 10 anos. Os dados geológicos demonstram que os autores de malware visam principalmente os continentes asiático e europeu, mas a razão para isso não é aparente; portanto, as perguntas ainda permanecem. Em relação aos tipos de software mal utilizado, a análise de amostras assinadas com o Shanghai Yulian SoftwareO certificado confirmou que a maioria das amostras são rootkits implantados junto com software crackeado ou corrigido. Outros tipos de software mal utilizado são aplicativos de usuário populares, como videogames, software de comunicação, editores de vídeo, etc. Um dos problemas é que os usuários observam o comportamento correto de software suspeito, mas mecanismos maliciosos ou backdoors também são implantados.

Em resumo, os certificados do DirtyMoe ainda são usados ​​para assinatura de código de outro software diferente do malware DirtyMoe, embora os certificados tenham sido revogados há muitos anos.

6. Conclusão

A análise de malware do driver DirtyMoe (rootkit) descobriu três certificados usados ​​para a assinatura de códigos de executáveis ​​suspeitos. Os certificados foram revogados a meio do seu período de validade. No entanto, os certificados ainda são amplamente usados ​​para a assinatura de código de outro software malicioso.

Os certificados revogados são usados ​​indevidamente principalmente para a assinatura de código de drivers maliciosos do Windows (rootkits) porque o sistema Windows de 64 bits começou a exigir as assinaturas do driver para maior segurança. Por outro lado, o Windows não implementa a verificação de assinaturas via CRL. Além disso, os autores de malware abusam dos certificados para assinar software popular para aumentar a credibilidade, enquanto o software é corrigido com cargas maliciosas. Outro ponto essencial é que o UAC verifica as assinaturas em relação à CRL local, que pode não estar atualizada. O UAC não baixa a versão atual da CRL quando os usuários desejam executar o software com a permissão mais alta. Conseqüentemente, pode ser uma fraqueza séria.

Uma fonte de incerteza é a origem dos autores de malware que usaram indevidamente os certificados revogados. Tudo aponta para um pequeno grupo do autor localizado principalmente na China. Uma investigação mais aprofundada de amostras assinadas é necessária para confirmar se as amostras contêm cargas úteis com funcionalidade semelhante ou semelhanças de código.

No geral, esses resultados e estatísticas sugerem que os usuários do Windows ainda são descuidados ao executar programas baixados de fontes estranhas, incluindo vários cracks e keygens. Além disso, o Windows tem um mecanismo fraco e ineficaz que alertaria fortemente os usuários que eles tentam executar software com certificados revogados, embora existam técnicas para verificar a validade das assinaturas digitais.

Referências

[1] Assinatura de driver
[2] Certificados cruzados para assinatura de código no modo kernel
[3] Como o Windows lida com arquivos em execução cujo (s) certificado (s) de editor foram revogados
[4] Fundador de Pequim, Apabi Technology Limited
[5] Shanghai Yulian Software Technology Co. , Ltd.
[6] Driver de monitoramento de rede WFP (firewall)
[7] Hyper-V Virtual Switch
[8] Lineage Login
[9] Dr. Web: Trojan.MulDrop16.18994
[10] Denuvo
[11] Filmora
[12] μTorrent

Fonte: Avast