Resumo

Na primeira postagem DirtyMoe: introdução e visão geral do malware modularizado , descrevemos um dos malwares complexos e sofisticados chamado DirtyMoe. As principais funções observadas do malware são Cryptojacking e ataques DDoS, que ainda são populares. Não há dúvida de que o malware foi lançado com fins lucrativos, e todas as evidências apontam para território chinês. Na maioria dos casos, a campanha PurpleFox é usada para explorar sistemas vulneráveis ​​onde o exploit ganha os privilégios mais altos e instala o malware através do instalador MSI. Resumindo, o instalador faz mau uso do Windows System Event Notification Service (SENS) para a implantação de malware. No final da implantação, dois processos (trabalhadores) executam atividades maliciosas recebidas de servidores C&C bem ocultos.

Como mencionamos no primeiro post , todo malware bom deve implementar um conjunto de técnicas de proteção, anti-forense, anti-rastreamento e anti-depuração. Uma das técnicas mais usadas para ocultar atividades maliciosas é o uso de rootkits. Em geral, o objetivo principal dos rootkits é ocultar a si mesmo e a outros módulos do malware hospedado na camada do kernel. Os rootkits são ferramentas potentes, mas apresentam um alto risco de serem detectados porque os rootkits funcionam no modo kernel e cada bug crítico leva ao BSoD.

O objetivo principal deste próximo artigo é analisar as técnicas de rootkit que o DirtyMoe usa. A parte principal deste estudo examina a funcionalidade de um driver DirtyMoe, com o objetivo de fornecer informações complexas sobre o driver em termos de análise estática e dinâmica. As principais técnicas do rootkit DirtyMoe podem ser listadas da seguinte forma: o driver pode se ocultar e outras atividades de malware no kernel e no modo de usuário. Além disso, o driver pode executar comandos recebidos do modo de usuário com os privilégios do kernel. Outro aspecto significativo do driver é a injeção de um arquivo DLL arbitrário nos processos de destino. Por último, mas não menos importante, está a funcionalidade do driver que censura o conteúdo do sistema de arquivos. Da mesma forma, descrevemos a rotina refinada que implanta o driver no kernel e qual método anti-forense os autores do malware usaram.

Outro ponto essencial desta pesquisa é a investigação dos meta-dados do motorista, que mostraram que o motorista está codificado com os certificados que foram roubados e revogados no passado. No entanto, os certificados são amplamente difundidos e mal utilizados em outros softwares mal-intencionados no presente.

Por fim, a última parte resume a funcionalidade do rootkit e reúne as principais descobertas dos certificados digitais, fazendo uma ligação entre o DirtyMoe e outros softwares mal-intencionados. Além disso, discutimos o nível de implementação e as fontes das técnicas de rootkit usadas.

1. Amostra

O assunto desta pesquisa é um exemplo com SHA-256: 
AABA7DB353EB9400E3471EAAA1CF0105F6D1FAB0CE63F1A2665C8BA0E8963A05
O exemplo é um driver do Windows que DirtyMoe descarta na inicialização do sistema.

Observação: o VirusTotal mantém um registro de 44 de 71 mecanismos AV (62%) que detectam as amostras como maliciosas. Por outro lado, o arquivo DLL DirtyMoe é detectado por 86% dos AVs registrados. Portanto, a cobertura de detecção é suficiente, pois o driver é despejado do arquivo DLL.

Informação básica
  • Tipo de arquivo: executável portátil 64
  • Informações do arquivo: Microsoft Visual C ++ 8.0 (driver)
  • Tamanho do arquivo: 116,04 KB (118824 bytes)
  • Assinatura digital: Shanghai Yulian Software Technology Co., Ltd. (上 海域 联 软件 技术 有限公司)
Importações

O driver importa duas bibliotecas FltMgrntosrnlA Tabela 1 resume os métodos mais suspeitos do ponto de vista do motorista.

RotinaDescrição
FltSetCallbackDataDirtyA pré ou pós-operação de um driver de minifiltro chama a rotina para indicar que ele modificou o conteúdo da estrutura de dados de retorno de chamada.
FltGetRequestorProcessIdA rotina retorna o ID do processo para o processo solicitado para uma determinada operação de E / S.
FltRegisterFilterFltRegisterFilter registra um driver de minifiltro.
ZwDeleteValueKey
ZwSetValueKey
ZwQueryValueKey
ZwOpenKey
As rotinas excluem, definem, consultam e abrem entradas do registro no modo kernel.
ZwTerminateProcessA rotina termina um processo e todos os seus threads no modo kernel.
ZwQueryInformationProcessRecupera informações sobre o processo especificado.
MmGetSystemRoutineAddressRetorna um ponteiro para uma função especificada por um parâmetro de rotina.
ZwAllocateVirtualMemoryReserva um intervalo de endereços virtuais acessíveis por aplicativo no processo especificado no modo kernel.

Tabela 1 . Métodos de kernel importados pelo driver DirtyMoe

À primeira vista, o driver procura a rotina do kernel por meio de MmGetSystemRoutineAddress()uma forma de ofuscação, pois a tabela de strings contém nomes de rotina operando com VirtualMemory; por exemplo, ZwProtectVirtualMemory()ZwReadVirtualMemory()ZwWriteVirtualMemory(). A rotina do kernel ZwQueryInformationProcess()e cadeias de caracteres como services.exewinlogon.exeapontam que o rootkit provavelmente funciona com estruturas de kernel dos processos críticos do Windows.

2. Análise do driver DirtyMoe

O driver DirtyMoe não executa nenhuma atividade de malware específica. No entanto, ele fornece uma ampla escala de técnicas de rootkit e backdoor. O driver foi projetado como um sistema de suporte de serviço para o serviço DirtyMoe no modo de usuário.

O driver pode executar ações originalmente necessárias com altos privilégios, como gravar um arquivo na pasta do sistema, gravar no registro do sistema, eliminar um processo arbitrário, etc. O malware no modo de usuário apenas envia um código de controle definido e dados para o driver e fornece ações de maior privilégio.

Além disso, o malware pode usar o driver para ocultar alguns registros, ajudando a mascarar atividades maliciosas. O driver afeta o registro do sistema e pode ocultar chaves arbitrárias. Além disso, o processo do sistemaservices.exeé corrigido em sua memória e o driver pode excluir serviços arbitrários da lista de serviços em execução. Além disso, o driver modifica as estruturas do kernel gravando os drivers carregados, para que o malware possa escolher qual driver está visível ou não. Portanto, o malware está ativo, mas o sistema e o usuário não podem listar os registros de malware usando chamadas de API padrão para enumerar o registro do sistema, serviços ou drivers carregados. O malware também pode ocultar arquivos necessários armazenados no sistema de arquivos, uma vez que o driver implementa um mecanismo do minifiltro. Consequentemente, se um usuário solicitar um registro do sistema de arquivos, o driver captura essa solicitação e pode afetar o resultado da consulta que é passado ao usuário.

O driver consiste em 10 funcionalidades principais, conforme ilustra a Tabela 2 .

FunçãoDescrição
Entrada do motoristarotina chamada pelo kernel quando o driver é carregado.
Iniciar rotinaé executado como um thread do kernel, restaurando a configuração do driver do registro do sistema.
Controle de dispositivoprocessa códigos de controle de E / S definidos pelo sistema (IOCTLs) controlando o driver a partir do modo de usuário.
Driver de minifiltroa rotina completa o processamento para um ou mais tipos de operações de E / S;QueryDirectory neste caso. Em outras palavras, a rotina filtra as enumerações das pastas.
Notificação de discussãorotina registra um retorno de chamada fornecido pelo driver que é notificado quando um novo encadeamento é criado.
Retorno de chamada do driver NTFSenvolve o retorno de chamada original do driver NTFS para a IRP_MJ_CREATEfunção principal.
Ocultação de registroEste método de gancho fornece ocultação de chave de registro.
Serviço de Esconderijoé uma rotina que esconde um serviço definido.
Escondendo Motoristaé uma rotina que esconde um driver definido.
Descarga do motoristarotina é chamada pelo kernel quando o driver é descarregado.

Tabela 2 . Funcionalidade do driver principal

A maioria das funcionalidades implementadas estão disponíveis como amostras públicas em fóruns na Internet. O nível de habilidades de programação é diferente para cada funcionalidade do driver. Parece que o autor do driver mesclou as amostras públicas na maioria dos casos. Portanto, o driver contém alguns bugs e código não utilizado. O driver ainda está em desenvolvimento e provavelmente iremos encontrar outras versões.

2.1 Entrada do Motorista

entrada do driver é a primeira rotina chamada pelo kernel após o carregamento do driver. O driver inicializa um grande número de variáveis ​​globais para a operação adequada do driver. Em primeiro lugar, o driver detecta a versão do sistema operacional e configura os deslocamentos necessários para o uso malicioso posterior. Em segundo lugar, a variável para apontar da imagem do driver é inicializada. A imagem do driver é usada para ocultar um driver. O driver também associa as seguintes funções principais:

  1. IRP_MJ_CREATEIRP_MJ_CLOSE– nenhuma ação de juros,
  2. IRP_MJ_DEVICE_CONTROL – usado para configuração e controle do driver,
  3. IRP_MJ_SHUTDOWN – grava dados definidos por malware no disco e no registro.

entrada do driver cria um link simbólico para o driver e tenta associá-lo a outro monitoramento malicioso ou filtragem de retornos de chamada. O primeiro é um minifiltro ativado pelo FltRegisterFilter()método que registra o FltPostOperation(); ele filtra o acesso às unidades do sistema e permite ocultar arquivos e diretórios.

Além disso, o método de inicialização troca uma função principal IRP_MJ_CREATEpor \FileSystem\Ntfsdriver. Portanto, cada chamada de API CreateFile()ou uma função do modo kernel IoCreateFile()pode ser monitorada e afetada pelo MalNtfsCreatCallback()retorno de chamada malicioso .

Outro método de entrada de driver define um método de retorno de chamada usando PsSetCreateThreadNotifyRoutine(). Ele NotifyRoutine()monitora a criação de um processo de kernel e o malware pode injetar código malicioso em processos / threads recém-criados.

Finalmente, o driver tenta restaurar sua configuração a partir do registro do sistema.

2.2 Iniciar rotina

rotina de início é executada como um encadeamento do sistema kernel criado na rotina de entrada do driver . A rotina de início grava a versão do driver no registro SYSTEM da seguinte maneira:

  • Chave: HKLM\SYSTEM\CurrentControlSet\Control\WinApi\WinDeviceVer
  • Valor: 20161122

Se a seguinte SOFTWAREchave de registro estiver presente, o driver carrega os artefatos necessários para a injeção do processo:

  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Secure

A última parte do Start Routine carrega o resto das entradas necessárias do registro. A lista completa do registro do sistema está documentado no Apêndice A .

2.3 Controle de dispositivo

O controle de dispositivo é um mecanismo para controlar um driver carregado. Um driver recebe o IRP_MJ_DEVICE_CONTROLcódigo de controle de E / S (IOCTL) se um thread de modo de usuário chama Win32 API DeviceIoControl(); visite [1] para obter mais informações. O aplicativo de modo de usuário envia IRP_MJ_DEVICE_CONTROLdiretamente para um driver de dispositivo específico. O driver então executa a operação correspondente. Portanto, aplicativos mal-intencionados no modo de usuário podem controlar o driver por meio desse mecanismo.

O driver suporta aprox. 60 códigos de controle. Dividimos os códigos de controle em 3 grupos básicos: controle , inserção e configuração .

Controlando

Existem 9 códigos de controle principais invocando a funcionalidade do driver a partir do modo de usuário. A Tabela 3 aseguir resume o controle de IOCTL que pode ser enviado por malware usando a API do Win32.

IOCTLDescrição
0x222C80O driver aceita outros IOCTLs somente se o driver estiver ativado. O malware no modo de usuário pode ativar o driver enviando este IOCTL e o código de autorização iguais 0xB6C7C230.
0x2224C0 O malware envia dados que o driver grava no registro do sistema. Uma chave, valor e tipo de dados são definidos por Definir códigos de controle. 
variável usada: regKey, regValue, regData, regType
0x222960Este IOCTL limpa todos os dados armazenados pelo driver. 
variável usada: consulte Configurandoinserindovariáveis
0x2227ECSe o malware precisar ocultar um driver específico, o driver adiciona um nome de driver específico a 
listBaseDllName e o oculta usando Driver Hiding .
0x2227E8O driver adiciona o nome da chave do registro à lista WinDeviceAddress e oculta essa chave 
usando o recurso Ocultar o Registro . 
variável usada: WinDeviceAddress
0x2227F0O driver oculta um determinado serviço definido pelo nome da imagem DLL. O nome é inserido navariável listServices e a técnica Service Hiding oculta o serviço no sistema.
0x2227DCSe o malware quiser desativar o ocultamento do registro , o driver restaura o kernel original 
GetCellRoutine().
0x222004O malware envia uma ID de processo que deseja encerrar. O driver chama a função do kernel 
ZwTerminateProcess()e encerra o processo e todos os seus threads, independentemente dos privilégios do malware.
0x2224C8O malware envia dados que o driver grava no arquivo definido pela variável filePath ; consulteDefinindo a variável de códigos de controle 
usados: filePath, fileData

Tabela 3 . Controlando IOCTLs

Inserindo

Existem 11 códigos de controle que inserem itens em listas brancas / negras. A Tabela 4 a seguir resume as variáveis ​​e sua finalidade.

Lista Branca / NegraVariávelPropósito
Registro HIVEWinDeviceAddressDefine uma lista de entradas de registro que o malware deseja ocultar no sistema.
Nome do arquivo de imagem do processoWinDeviceMakerRepresenta uma lista de permissões de processos definidos pelo nome do arquivo de imagem do processo . É usado no retorno de chamada do driver NTFS e concede acesso aos sistemas de arquivos NTFS. Além disso, ele opera no driver do minifiltro e evita a ocultação de arquivos definidos na variável WinDeviceNumber . O último uso está naocultação de registro ; o malware não esconde as chaves de registro dos processos permitidos.
WinDeviceMakerBDefine uma lista de permissões de processos definidos pelo nome do arquivo de imagem do processo . É usado no retorno de chamada do driver NTFS e concede acesso aos sistemas de arquivos NTFS.
WinDeviceMakerOnlyEspecifica uma lista negra de processos definidos pelo nome do arquivo de imagem do processo . É usado no retorno de chamada do driver NTFS e recusa o acesso aos sistemas de arquivos NTFS.
Nomes de arquivos 
caminho completo )
WinDeviceName 
WinDeviceNameB
Determina uma lista de permissões de arquivos que devem receber acesso por retorno de chamada do driver NTFS . É usado em combinação com WinDeviceMaker e WinDeviceMakerB . Portanto, se um arquivo estiver na lista branca e um processo solicitado também estiver na lista branca, o driver concede acesso ao arquivo.
WinDeviceNameOnlyDefine uma lista negra de arquivos cujo acesso deve ser negado peloretorno de chamada do driver NTFS . Ele é usado em combinação comWinDeviceMakerOnly . Portanto, se um arquivo estiver na lista negra e um processo de solicitação também estiver na lista negra, o driver recusa o acesso ao arquivo.
Nomes de arquivos 
contendo número )
WinDeviceNumberDefine uma lista de arquivos que devem ser ocultados no sistema pelodriver do minifiltro . O malware usa uma convenção de nome da seguinte forma: [A-Z][a-z][0-9]+\.[a-z]{3}. Portanto, um nome de arquivo inclui um número.
ID do processoListProcessId1Define uma lista de processos que requerem acesso a sistemas de arquivos NTFS. O malware não restringe o acesso a esses processos;consulte Retorno de chamada do driver NTFS .
ListProcessId2A mesma finalidade que ListProcessId1 . Além disso, é usado como lista de permissões para ocultar o registro, de forma que o driver não restrinja o acesso. O driver do minifiltro não limita os processos nesta lista.
Nomes de motoristaslistBaseDllNameDefine uma lista de drivers que devem ser ocultados no sistema; 
veja Driver Hiding .
Nomes de serviçolistServicesEspecifica uma lista de serviços que devem ser ocultados no sistema; 
veja Esconder Serviço .

Tabela 4 . Listas brancas e negras

Configuração

Os códigos de controle de configuração armazenam valores escalares como uma variável global. A Tabela 5 a seguir resume e agrupa essas variáveis ​​e sua finalidade.

FunçãoVariávelDescrição
Gravação de arquivo 
(desligamento)
filename1_for_ShutDown
data1_for_ShutDown
Define um nome de arquivo e dados para o primeiro arquivo gravado durante o desligamento do driver.
filename2_for_ShutDown
data2_for_ShutDown
Define um nome de arquivo e dados para o segundo arquivo gravado durante o desligamento do driver.
Gravação de registro 
(desligamento)
regKey1_shutdown 
regValue1_shutdown 
regData1_shutdown 
regType1
Especifica o primeiro caminho da chave do Registro, nome do valor, dados e tipo (REG_BINARY, REG_DWORD, REG_SZ, etc.) gravados durante o desligamento do driver.
regKey2_shutdown 
regValue2_shutdown 
regData2_shutdown 
regType2
Especifica o segundo caminho da chave de registro, nome do valor, dados e tipo (REG_BINARY, REG_DWORD, REG_SZ, etc.) gravados durante o desligamento do driver.
Gravação de dados de arquivocaminho de arquivoDetermina o nome do arquivo que será usado para gravar dados; 
consulte ControlandoIOCTL 0x2224C8.
Escrita de registroregKey 
regValue 
regType
Especifica o caminho da chave do registro, nome do valor e tipo (REG_BINARY, REG_DWORD, REG_SZ, etc.); 
consulte ControlandoIOCTL 0x2224C0.
Desconhecido
não utilizado )
dwWinDevicePathA 
dwWinDeviceDataA
Mantém um caminho e dados para o arquivo A.
dwWinDevicePathB 
dwWinDeviceDataB
Mantém um caminho e dados para o arquivo B.

Tabela 5 . Variáveis ​​de driver globais

A seguinte Tabela 6 resume as variáveis ​​usadas para a injeção do processo; veja Notificação de Tópico .

FunçãoVariávelDescrição
Processo para injetardwWinDriverMaker2 
dwWinDriverMaker2_2
Define dois argumentos de linha de comando. Se um processo com um dos argumentos for criado, o driver deve injetar o processo.
dwWinDriverMaker1 
dwWinDriverMaker1_2
Define dois nomes de processo que devem ser injetados se o processo for criado.
DLL para injetardwWinDriverPath1 
dwWinDriverDataA
Especifica um nome de arquivo e dados para a injeção de processo definida por dwWinDriverMaker2 ou dwWinDriverMaker1 .
dwWinDriverPath1_2 
dwWinDriverDataA_2
Define um nome de arquivo e dados para a injeção de processo definida por dwWinDriverMaker2_2 ou dwWinDriverMaker1_2 .
dwWinDriverPath2 
dwWinDriverDataB
Mantém um nome de arquivo e dados para a injeção de processo definida por dwWinDriverMaker2 ou dwWinDriverMaker1 .
dwWinDriverPath2_2 
dwWinDriverDataB_2
Especifica um nome de arquivo e dados para a injeção de processo definida por dwWinDriverMaker2_2 ou dwWinDriverMaker1_2 .

Tabela 6 . Variáveis ​​de injeção

2.4 Driver de minifiltro

O driver do minifiltro é registrado na rotina de entrada do driver usando o FltRegisterFilter()método. Um dos argumentos do método define os métodos de configuração ( FLT_REGISTRATION) e retorno de chamada ( FLT_OPERATION_REGISTRATION). Se a solicitação do sistema QueryDirectory for invocada, o driver do malware captura essa solicitação e a processa FltPostOperation().

FltPostOperation()método pode modificar um resultado das operações QueryDirectory (IRP). Na verdade, o driver do malware pode afetar (ocultar, inserir, modificar) uma enumeração de diretório. Portanto, alguns aplicativos no modo de usuário podem não ver a imagem real do diretório solicitado.

O driver afeta os resultados do QueryDirectory apenas se um processo solicitado não estiver presente nas listas de desbloqueio. Existem duas listas de permissões. As primeiras listas de desbloqueio ( ID do processo e nomes de arquivo ) fazem com que os resultados do QueryDirectory não sejam modificados se o ID do processo ou nome do arquivo de imagem do processo, solicitando a operação de E / S fornecida ( QueryDirectory ), estiver presente nas listas de permissão . Ele representa os processos de malware que devem ter acesso ao sistema de arquivos sem restrições. A lista de desbloqueio adicional é chamada WinDeviceNumber , definindo um conjunto de sufixos. O FltPostOperation()itera cada item do QueryDirectory. Se o nome do item enumerado tiver um sufixo definido na lista de desbloqueio , o driver remove o item dos resultados do QueryDirectory . Ele garante que os arquivos da lista de permissões não sejam visíveis para processos não relacionados a malware [2] . Portanto, o driver pode ocultar facilmente um diretório / arquivo arbitrário para os aplicativos de modo de usuário, inclusive explorer.exe. O nome da lista de permissões WinDeviceNumber é provavelmente derivado de nomes de arquivos de malware, por exemplo Ke145057.xsl, uma vez que o sufixo é um número; ver Apêndice B .

2.5 Retorno de chamada do driver NTFS

Quando o driver é carregado, a rotina de entrada do driver modifica o driver do sistema para o sistema de arquivos NTFS. O método de retorno de chamada original para a IRP_MJ_CREATEfunção principal é substituído por um retorno de chamada malicioso, MalNtfsCreatCallback()conforme ilustra a Figura 1 . O retorno de chamada malicioso determina o que deve obter acesso e o que não deve.

Figura 1 . Reescrever IRP_MJ_CREATE callback do driver NTFS regular

O retorno de chamada malicioso estará ativo apenas se o registro do driver do minifiltro tiver sido feito e o retorno de chamada original tiver sido substituído. Existem listas de permissões e uma lista de proibições. As listas brancas armazenam informações sobre nomes de imagem de processo permitidos , ID de processo e arquivos permitidos . Se o processo de solicitação de acesso ao disco estiver na lista de permissões, o arquivo solicitado também deverá estar na lista de permissões. É dupla proteção. A lista negra se concentra no processamento de nomes de imagens . Portanto, os processos na lista negra não têm acesso ao sistema de arquivos. Figura 2demonstra a lista de permissões de processos. Se um processo estiver na lista de desbloqueio, o driver chama o retorno de chamada original; caso contrário, a solicitação termina com acesso negado.

Figura 2 . Conceda acesso a processos permitidos

Em geral, se o retorno de chamada malicioso determinar que o processo de solicitação está autorizado a acessar o sistema de arquivos, o driver chama a IRP_MJ_CREATEfunção principal original . Caso contrário, o driver conclui a solicitação como STATUS_ACCESS_DENIED.

2.6 Ocultação de registro

O driver pode ocultar uma determinada chave de registro. Cada manipulação com uma chave de registro é interceptada pelo método do kernel GetCellRoutine(). O gerenciador de configuração atribui um bloco de controle para cada chave de registro aberta. A CM_KEY_CONTROL_BLOCKestrutura do bloco de controle ( ) mantém todos os blocos de controle em uma tabela hash para pesquisar rapidamente os blocos de controle existentes. O GetCellRoutine()método de gancho calcula um endereço de memória de uma chave solicitada. Portanto, se o driver do malware assumir o controle do GetCellRoutine(), o driver pode filtrar quais chaves de registro ficarão visíveis; mais precisamente, quais chaves serão pesquisadas na tabela hash.

O driver do malware encontra um endereço do original GetCellRoutine()e o substitui por seu próprio método de gancho malicioso MalGetCellRoutine(),. O driver usa uma implementação bem documentada [3, 4] . Ele apenas passa pelas estruturas do kernel obtidas por meio da ZwOpenKey()chamada do kernel. Em seguida, o driver procura CM_KEY_CONTROL_BLOCK, e sua estrutura HHIVE associada corresponde à chave solicitada. A estrutura HHIVE contém um ponteiro para o GetCellRoutine()método, que o driver substitui; veja a Figura 3 .

Figura 3 . Substituindo GetCellRoutine

A armadilha desse método é que os deslocamentos da estrutura, variável ou método pesquisados ​​são específicos para cada versão ou compilação do Windows. Portanto, o driver deve determinar em qual versão do Windows o driver é executado.

MalGetCellRoutine()método de gancho executa 3 operações básicas como segue:

  1. O driver chama o GetCellRoutine()método original do kernel .
  2. Verifica as listas de permissões em busca de uma chave de registro solicitada.
  3. Captura ou libera a chave de registro solicitada de acordo com a verificação da lista de permissões.
Ocultar chave de registro

A técnica de ocultação usa um princípio simples. O driver itera em todo um HIVE de uma chave solicitada. Se o driver encontrar uma chave de registro para ocultar, ele retornará a última chave de registro do HIVE iterado. Quando a interação está no final do HIVE, o driver não retorna a última chave já que ela foi retornada antes, mas apenas retorna NULL, que encerra a busca do HIVE.

A consequência deste princípio é que se o driver quiser ocultar mais de uma chave, o driver retorna a última chave do HIVE pesquisado mais vezes. Portanto, os resultados finais da consulta do registro podem conter chaves duplicadas.

Whitelisting

Os serviços services.exeSystemsão incluídos na lista de permissões por padrão e não há restrição. Os nomes de imagem de processo na lista de permissões também não têm nenhuma restrição de acesso ao registro.

Um mecanismo de tomada de decisão é mais complicado para o Windows 10. O driver oculta a chave de solicitação apenas para o regedit.exeaplicativo se a compilação do Windows 10 for 14393 (julho de 2016) ou 15063 (março de 2017).

2.7 Notificação de discussão

O principal objetivo da Notificação de Thread é injetar código malicioso em threads criados. O driver registra uma rotina de notificação de thread PsSetCreateThreadNotifyRoutine()durante a inicialização do Device Entry . A rotina registra um retorno de chamada que é subsequentemente notificado quando um novo thread é criado ou excluído. O callback suspeito ( PCREATE_THREAD_NOTIFY_ROUTINENotifyRoutine()leva três argumentos: ProcessID , ThreadID e sinalizador Create . O driver afeta apenas os encadeamentos nos quais Criar sinalizador está definido como TRUE, portanto, apenas os encadeamentos recém-criados.

A lista de permissões concentra-se em dois aspectos. O primeiro é o nome da imagem e o segundo são os argumentosda linha de comando de um thread criado. O nome da imagem é armazenado em WinDriverMaker1 e os argumentos são armazenados como uma soma de verificação na variável WinDriverMaker2 . O driver é projetado para injetar apenas dois processos definidos por um nome de processo e dois processos definidos por argumentos de linha de comando . Não há listas brancas, apenas 4 variáveis ​​globais.

2.7.1 Pesquisa de método de kernel

A injeção bem-sucedida do código malicioso requer vários métodos de kernel. O driver não chama esses métodos diretamente devido às técnicas de detecção e tenta ofuscar o método necessário. O motorista requer os seguintes métodos de kernel: ZwReadVirtualMemoryZwWriteVirtualMemoryZwQueryVirtualMemoryZwProtectVirtualMemoryNtTestAlert,LdrLoadDll

Os métodos do kernel são necessários para uma injeção de thread bem-sucedida porque o driver precisa ler / gravar os dados do processo de uma thread injetada, incluindo a instrução do programa.

Pesquisa de método de memória virtual

O driver obtém o endereço do ZwAllocateVirtualMemory()método. Como ilustra a Figura 4 , todos os métodos de pesquisa são localizados consecutivamente após o ZwAllocateVirtualMemory()método em ntdll.dll.

Figura 4. Segmento de código de ntdll.dll com métodos VirtualMemory

O driver começa a inspecionar os segmentos de código a partir do endereço do ZwAllocateVirtualMemory()e procura por instruções que representem o movimento constante para eax(por exemplo mov eax, ??h). Ele identifica os VirtualMemorymétodos; consulte a Tabela 7 para obter as constantes.

ConstanteMétodo
0x18ZwAllocateVirtualMemory
0x23ZwQueryVirtualMemory
0x3ANtWriteVirtualMemory
0x50ZwProtectVirtualMemory

Tabela 7 . Métodos de constantes de memória virtual para Windows 10 (64 bits)

Quando uma constante apropriada é encontrada, o endereço final de um método de pesquisa é calculado da seguinte maneira:

method_address = constant_address - alignment_constant
onde alignment_constantajuda a apontar para o início do método pesquisado.

As etapas para encontrar métodos podem ser resumidas da seguinte forma:

  1. Obtenha o endereço de ZwAllocateVirtualMemory(), que não é suspeito em termos de detecção.
  2. Cada método procurado contém uma constante específica em um endereço específico ( constant_address).
  3. Se for encontrado, outro offset específico ( ) é subtraído; O é específico para cada versão do Windows.constant_addressalignment_constant
    alignment_constant

A implementação exata do método Virtual Memory Method Lookup é mostrada na Figura 5 .

Figura 5. Implementação da rotina de pesquisa procurando os métodos do kernel VirtualMemory

O sucesso dessa ofuscação depende da identificação da versão do Windows. Encontramos uma versão do Windows 7 que retorna métodos diferentes dos desejados pelo malware; nomeadamente, ZwCompressKey()ZwCommitEnlistment()ZwCreateNamedPipeFile()ZwAlpcDeleteSectionView()
alignment_constanté derivado da versão atual do Windows durante a inicialização do driver; consulte a rotina de entrada do driver .

Pesquisa NtTestAlert e LdrLoadDll

Uma abordagem diferente é usada para obter NtTestAlert()LdrLoadDll()rotinas. O driver se conecta ao winlogon.exeprocesso e obtém o ponteiro para a estrutura do kernel que PEB_LDR_DATAcontém o cabeçalho PE e as importações de todos os processos no sistema. Se a tabela de importação incluir um método obrigatório, o driver extrairá o endereço base, que é o ponto de entrada para a rotina procurada.

2.7.2 Processo de injeção

O objetivo da injeção do processo é carregar uma biblioteca DLL definida em um novo thread por meio da função do kernel LdrLoadDll(). A injeção do processo é um pouco diferente para as versões do sistema operacional x86 e x64.

A versão do sistema operacional x64 abusa da NtTestAlert()rotina original , que verifica a fila APC do thread. O APC (Asynchronous Procedure Call) é uma técnica para enfileirar um trabalho a ser feito no contexto de um thread específico. É chamado periodicamente. O driver reescreve as instruções do NtTestAlert()que salta para o ponto de entrada do código malicioso.

Modificação do código NtTestAlert

A primeira etapa para a injeção do processo é encontrar memória livre para uma caverna de código. O driver encontra a memória livre próxima ao NtTestAlert()endereço da rotina. A caverna de código inclui um código de shell, conforme demonstra a Figura 6 ..

Figura 6. Carga útil maliciosa sobrescrevendo a rotina NtTestAlert () original

O shellcode prepara um parâmetro ( code_caveendereço) para o código malicioso e, em seguida, salta para ele. O NtTestAlert()endereço original é movido raxporque o código malicioso termina com a instrução de retorno e, portanto, o original NtTestAlert()é invocado. Por fim, rdxcontém o endereço de salto, onde o driver injetou o código malicioso. O próximo item da caverna de código é um caminho para o arquivo DLL, que deve ser carregado no processo injetado. Outros itens da caverna de código são o endereço original e as instruções do código original do NtTestAlert().

O driver grava o código malicioso no endereço definido em dll_loading_shellcode. As instruções originais do NtTestAlert()são reescritas com a instrução que apenas salta para o shellcode. Isso faz com que, quando o NtTestAlert()é chamado, o shellcode seja ativado e salte para o código malicioso.

Código Malicioso x64

O código malicioso para x64 é simples. Em primeiro lugar, ele recupera a instrução original do NtTestAlert()código reescrito . Em segundo lugar, o código invoca o LdrLoadDll()método encontrado e carrega a DLL apropriada no espaço de endereço do processo injetado. Finalmente, o código executa a instrução de retorno e volta para a NtTestAlert()função original .

A versão do sistema operacional x86 abusa diretamente do ponto de entrada do processo injetado. O procedimento é muito semelhante ao da injeção x64, e o código malicioso x86 também é idêntico à versão x64. No entanto, o código malicioso x86 precisa encontrar uma variante de 32 bits do  LdrLoadDll()método. Ele usa a técnica semelhante descrita acima ( pesquisa NtTestAlert e LdrLoadDll ).

2.8 Serviço de Esconderijo

O Windows usa o Gerenciador de Controle de Serviços (SCM) para gerenciar os serviços do sistema. O executável do SCM é services.exe. Este programa é executado na inicialização do sistema e executa várias funções, como executar, encerrar e interagir com os serviços do sistema. O processo SCM também mantém todos os serviços executados em uma SERVICE_RECORDestrutura de registro de serviço não documentado ( ).

O driver deve corrigir o registro de serviço para ocultar um serviço necessário. Em primeiro lugar, o driver deve encontrar o processo services.exee anexá-lo a este via KeStackAttachProcess(). O autor do malware definiu uma sequência de bytes que o driver procura na memória do processo para encontrar o registro do serviço. O services.exemantém todos os serviços executados como uma lista vinculada de SERVICE_RECORD [5] . O driver de malware itera essa lista e desvincula os serviços necessários definidos pela lista de permissões listServices ; consulte a Tabela 4 .

A seqüência de byte usado para o Windows 2000, XP, Vista e Windows 7 é a seguinte: {45 3B E5 74 40 48 8D 0D}. Há outra sequência de bytes {48 83 3D ?? ?? ?? ?? ?? 48 8D 0D}que nunca é usada porque está vinculada à versão do Windows que o driver do malware nunca identificou; talvez em desenvolvimento.

Os serviços ocultos não podem ser detectados usando o comando PowerShell Get-Service, o Gerenciador de Tarefas do Windows, o Process Explorer, etc. No entanto, os serviços iniciados são registrados por meio do Log de Eventos do Windows. Portanto, podemos enumerar todos os serviços regulares e todos os serviços registrados. Então, podemos criar diferenças para encontrar serviços ocultos.

2.9 Esconder o Motorista

O driver é capaz de ocultar a si mesmo ou a outro driver malicioso baseado no IOCTL do modo de usuário. A entrada de driver é iniciada por um parâmetro que representa um objeto de driver ( DRIVER_OBJECT) da imagem de driver carregada. O objeto do driver contém um item oficialmente não documentado chamado seção do driver. A LDR_DATA_TABLE_ENTRYestrutura do kernel armazena informações sobre o driver carregado, como endereço de base / ponto de entrada, nome da imagem, tamanho da imagem, etc. A seção do driver aponta para LDR_DATA_TABLE_ENTRYuma lista duplamente vinculada que representa todos os drivers carregados no sistema.

Quando um aplicativo de modo de usuário lista todos os drivers carregados, o kernel enumera a lista duplamente vinculada da LDR_DATA_TABLE_ENTRYestrutura. O driver de malware itera toda a lista e desvincula itens (drivers) que deveriam estar ocultos. Portanto, o kernel perde ponteiros para os drivers ocultos e não pode enumerar todos os drivers carregados [6] .

2.10 Descarregamento do Driver

A função Driver Unload contém código suspeito, mas parece nunca ser usado nesta versão. O restante da funcionalidade de descarregamento executa o procedimento padrão para descarregar o driver do sistema.

3. Carregando o driver durante a inicialização

O serviço DirtyMoe carrega o driver malicioso. Uma imagem de driver não é armazenada permanentemente em um disco, pois o serviço sempre extrai, carrega e exclui as imagens de driver na inicialização do serviço. O objetivo secundário do serviço é eliminar evidências sobre o carregamento de motoristas e, eventualmente, complicar uma análise forense. O serviço visa camuflar a atividade do registro e do disco. O serviço DirtyMoe é registrado da seguinte forma:

Service name: Ms<volume_id>App; por exemplo, MsE3947328App
Registry key: HKLM\SYSTEM\CurrentControlSet\services\<service_name>
ImagePath: %SystemRoot%\system32\svchost.exe -k netsvcs
ServiceDll: C:\Windows\System32\<service_name>.dll, ServiceMain
ServiceType: SERVICE_WIN32_SHARE_PROCESS
ServiceStart: SERVICE_AUTO_START

3.1 Operação de registro

Na inicialização, o serviço cria um registro de registro, descrevendo o driver malicioso a ser carregado; veja o seguinte exemplo:

Registry key: HKLM\SYSTEM\CurrentControlSet\services\dump_E3947328
ImagePath: \??\C:\Windows\System32\drivers\dump_LSI_FC.sys
DisplayName: dump_E3947328

À primeira vista, é evidente que ImagePathnão reflete DisplayName, que é a convenção de nomenclatura comum do Windows. Além disso, ImagePathprefixado com dump_string é usado para drivers virtuais (carregados apenas na memória) gerenciando o despejo de memória durante a falha do Windows. O malware tenta usar a convenção de nome de driver virtual para não ser tão visível. O princípio do Dump Memory usando os drivers virtuais é descrito em [7, 8] .

ImagePathos valores são diferentes para cada reinicialização do Windows, mas sempre abusa do nome do driver nativo do sistema; veja alguns exemplos coletados durante inicialização do Windows: dump_ACPI.sysdump_RASPPPOE.sysdump_LSI_FC.sysdump_USBPRINT.sysdump_VOLMGR.sysdump_INTELPPM.sys,dump_PARTMGR.sys

3.2 Carregando o Driver

Quando a entrada do registro está pronta, o serviço DirtyMoe despeja o driver no arquivo definido por ImagePath. Em seguida, o serviço carrega o driver via ZwLoadDriver().

3.3 Limpeza de evidências

Quando o driver é carregado com ou sem sucesso, o serviço DirtyMoe começa a mascarar vários componentes maliciosos para proteger toda a hierarquia do malware.

O serviço DirtyMoe remove a chave de registro que representa o driver carregado; consulte Operação de registro . Além disso, o driver carregado oculta os serviços de malware, conforme descreve a seção Service Hiding . As entradas de registro relacionadas ao driver são removidas por meio da chamada de API. Portanto, uma trilha forense pode ser encontrada no registro SYSTEM HIVE, localizado em %SystemRoot%\system32\config\SYSTEM. A chamada API apenas remove um ponteiro HIVE relevante, mas os dados não referenciados ainda estão presentes no HIVE armazenado no disco. Portanto, podemos ler as entradas de registro removidas por meio do RegistryExplorer .

O driver carregado também remove o dump_arquivo de driver despejado ( prefixo). Não foi possível restaurar este arquivo por meio de ferramentas que permitem a recuperação de arquivos excluídos, mas ele foi extraído diretamente do arquivo DLL do serviço.

Captura de imagem de driver e chaves de registro

O serviço de malware é responsável pelo carregamento do driver e limpa as evidências de carregamento. Colocamos um ponto de interrupção no nt!IopLoadDriver()método do kernel, que é alcançado se um processo deseja carregar um driver no sistema. Esperamos pelo driver desejado e depois listamos todos os processos do sistema. O serviço correspondente ( svchost.exe) tem uma pilha de chamadas que contém a chamada do kernel para o carregamento do driver, mas o serviço correspondente foi eliminado pela modificação do registro EIP. O processo (serviço) foi encerrado e todo o Windows terminou em BSoD. O Windows fez um despejo de memória, portanto, os caches do sistema de arquivos foram esvaziados e o serviço malicioso não concluiu a limpeza a tempo. Portanto, fomos capazes de montar um volume e ler todos os dados desejados.

3.4 Rastros Forenses

Embora o serviço DirtyMoe se esforce muito para encobrir as atividades maliciosas, existem alguns aspectos que ajudam a identificar o malware.

O serviço DirtyMoe e o próprio driver carregado estão ocultos; entretanto, o sistema de Log de Eventos do Windows registra informações sobre os serviços iniciados. Portanto, podemos obter informações adicionais, como ProcessID e ThreadID de todos os serviços, incluindo os serviços ocultos.

O WinDbg conectado ao kernel do Windows pode exibir todos os módulos carregados usando o lmcomando. A lista de módulos pode descobrir drivers não virtuais com prefixo dump_e identificar os drivers maliciosos.

O volume conectado off-line pode fornecer a biblioteca DLL dos serviços e outros arquivos de suporte, que infelizmente são criptografados e ofuscados com VMProtect. Finalmente, o registro SYSTEM offline armazena registros do serviço DirtyMoe.

4. Certificados

O Windows Vista e as versões posteriores do Windows exigem que os drivers carregados sejam assinados por código. O código-assinatura digital deve verificar a identidade e integridade do fornecedor do driver [9] . No entanto, o Windows não verifica o status atual de todos os certificados que assinam um driver do Windows. Portanto, se um dos certificados no caminho expirou ou foi revogado, o driver ainda está carregado no sistema. Não discutiremos por que o Windows carrega drivers com certificados inválidos, uma vez que este tópico é muito amplo. A compatibilidade com versões anteriores, mas também um impacto potencial na implementação do kernel desempenham um papel.

Os drivers DirtyMoe são assinados com três certificados, conforme 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 de novembro de 2014- Status de revogação : 02A8DC8B4AEAD80E77B333D61E35B40FBBB010A0 28:59)

Beijing Founder Apabi Technology Limited
Válido de: 22 de maio de 2018 (2:00:00) 
Válido para: 29 de maio de 2019 (14:00:00) 
SN: 06B7AA2C37C0876CCB0378D895D71041 
Impressão digital: 8564928AA4FBC4BBECF65B402503B2BE3DC60D4D 
Revogação Status: 2018 (2:00:01)

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)

Os certificados foram revogados por suas autoridades de certificação e estão registrados como roubados, vazados, uso indevido, etc. [10] . Embora todos os certificados tenham sido revogados no passado, o Windows carrega esses drivers com êxito porque as autoridades de certificação raiz estão marcadas como confiáveis.

5. Resumo e discussão

Resumimos a principal funcionalidade do driver DirtyMoe. Discutimos a qualidade da implementação do driver, mecanismos anti-forenses e certificados roubados para o carregamento bem-sucedido do driver.

5.1 Funcionalidade Principal

Autorização

O driver é controlado por meio de códigos IOCTL que são enviados por processos de malware no modo de usuário. Porém, o driver implementa o instrumento de autorização, que verifica se os IOCTLs são enviados por processos autenticados. Portanto, nem todos os processos podem se comunicar com o driver.

Afetando o sistema de arquivos

Se um rootkit estiver no kernel, ele pode fazer “qualquer coisa”. O driver DirtyMoe se registra no gerenciador de filtros e começa a influenciar os resultados das operações de E / S do sistema de arquivos; na verdade, ele começa a filtrar o conteúdo do sistema de arquivos. Além disso, o driver substitui a NtfsCreatCallback()função de retorno de chamada do driver NTFS, para que o driver possa determinar quem deve obter acesso e o que não deve acessar o sistema de arquivos.

Monitoramento de thread e injeção de código

O driver DirtyMoe registra uma rotina maliciosa que é invocada se o sistema criar um novo encadeamento. A rotina maliciosa abusa do mecanismo do kernel APC para executar o código malicioso. Ele carrega DLL arbitrária no novo thread. 

Ocultação de registro

Essa técnica abusa do método de gancho do kernel que indexa as chaves do registro no HIVE. A execução do código do método de gancho é redirecionada para a rotina maliciosa para que o driver possa controlar a indexação das chaves de registro. Na verdade, o driver pode selecionar quais chaves serão indexadas ou não.

Serviço e ocultação de motorista

O patch de estruturas específicas do kernel faz com que certas funções da API não enumerem todos os serviços do sistema ou drivers carregados. Os serviços e drivers do Windows são armazenados como uma lista duplamente vinculada no kernel. O driver corrompe as estruturas do kernel para que os serviços e drivers maliciosos sejam desvinculados dessas estruturas. Conseqüentemente, se o kernel itera essas estruturas para fins de enumeração, os itens maliciosos são ignorados.

5.2 Técnica Anti-Forense

Como mencionamos acima, o driver é capaz de se esconder. Mas antes de carregar o driver, o serviço DirtyMoe deve registrar o driver no registro e despejar o driver no arquivo. Quando o driver é carregado, o serviço DirtyMoe exclui todas as entradas de registro relacionadas ao carregamento do driver. O driver exclui seu próprio arquivo do sistema de arquivos por meio do modo kernel. Portanto, o driver é carregado na memória, mas seu arquivo se foi.

O serviço DirtyMoe remove as entradas do registro por meio de chamadas de API padrão. Podemos restaurar esses dados do armazenamento físico, pois as chamadas de API apenas removem o ponteiro do HIVE. O arquivo de driver despejado nunca é fisicamente armazenado na unidade de disco porque seu tamanho é muito pequeno e está presente apenas na memória cache. Da mesma forma, o arquivo é removido do cache antes da liberação do cache para o disco, portanto, não podemos restaurar o arquivo do disco físico.

5.3 Discussão

Todo o driver funciona como um pacote super rootkit tudo-em-um. Qualquer malware pode se registrar no driver se conhecer o código de autorização. Após o registro bem-sucedido, o malware pode usar uma ampla gama de funcionalidades do driver. Hipoteticamente, o código de autorização é codificado e o nome do driver pode ser derivado para que possamos nos comunicar com o driver e interrompê-lo.

O sistema carrega o driver por meio do serviço DirtyMoe em alguns segundos. Além disso, o arquivo do driver nunca está presente fisicamente no sistema de arquivos, apenas no cache. O driver é carregado por meio da chamada de API e o serviço DirtyMoe mantém um manipulador do arquivo do driver, portanto, a manipulação do arquivo com o arquivo do driver é limitada. No entanto, o driver remove seu próprio arquivo usando uma chamada de kernel. Portanto, o arquivo do driver é removido do cache do sistema de arquivos e o manipulador do driver ainda é relevante, com a diferença de que o arquivo do driver não existe, incluindo seus rastreamentos forenses.

O malware DirtyMoe é escrito usando Delphi na maioria dos casos. Naturalmente, o driver é codificado em C. O estilo de código do driver e do restante do malware é muito diferente. Analisamos que a maioria das funcionalidades do driver são baixadas de fóruns da Internet como amostras públicas. Cada parte de implementação do driver também é escrita em um estilo diferente. Os autores do malware fundiram a funcionalidade de rootkit individual em um kit. Eles também mesclaram bugs conhecidos, de modo que o driver mostra alguns sintomas significativos de presença do driver no sistema. Os autores precisaram adaptar a funcionalidade das amostras públicas ao seu propósito, mas isso foi feito de uma forma muito diletante. Parece que os autores do malware estão familiarizados apenas com o Delphi.

Finalmente, os certificados de assinatura de código usados ​​foram revogados no meio de seu período de validade. No entanto, os certificados ainda são amplamente usados ​​para assinatura de código, portanto, as chaves privadas dos certificados provavelmente foram roubadas ou vazadas. Além disso, os certificados roubados foram assinados pela autoridade de certificação em que a Microsoft confia, portanto, os certificados assinados dessa forma podem ser carregados com êxito no sistema, apesar de sua revogação. Além disso, a tendência no uso de certificados é crescente e as previsões mostram que continuará a crescer no futuro. Analisaremos os problemas dos certificados de assinatura de código em uma postagem futura.

6. Conclusão

DirtyMoe driver is an advanced piece of rootkit that DirtyMoe uses to effectively hide malicious activity on host systems. This research was undertaken to inspect the rootkit functionally of the DirtyMoe driver and evaluate the impact on infected systems. This study set out to investigate and present the analysis of the DirtyMoe driver, namely its functionality, the ability to conceal, deployment, and code-signature.

A pesquisa mostrou que o driver fornece funcionalidades essenciais para ocultar processos, serviços e chaves de registro maliciosos. Outra ação perigosa do driver é a injeção de código malicioso em processos recém-criados. Além disso, o driver também implementa o minifiltro, que monitora e afeta as operações de E / S no sistema de arquivos. Portanto, o conteúdo do sistema de arquivos é filtrado e os arquivos / diretórios apropriados podem ser ocultados para os usuários. Uma implicação dessa descoberta é que o próprio malware e seus artefatos estão ocultos até mesmo para antivírus. Mais importante, o driver implementa outra técnica anti-forense que remove a evidência do driver do disco e do registro imediatamente após o carregamento do driver. No entanto, alguns rastros podem ser encontrados nas máquinas da vítima.

Este estudo forneceu a primeira revisão abrangente do driver que protege e atende a cada serviço e processo de malware do malware DirtyMoe. O escopo deste estudo foi limitado em termos de funcionalidade do driver. No entanto, mais investigações experimentais são necessárias para encontrar e investigar outras amostras que foram assinadas pelos certificados revogados. Por causa disso, o autor do malware pode ser rastreado e identificado usando certificados abusados.

IoCs

Amostras (SHA-256)
550F8D092AFCD1D08AC63D9BEE9E7400E5C174B9C64D551A2AD19AD19C0126B1
AABA7DB353EB9400E3471EAAA1CF0105F6D1FAB0CE63F1A2665C8BA0E8963A05
B3B5FFF57040C801A4392DA2AF83F4BF6200C575AA4A64AB9A135B58AA516080
CB95EF8809A89056968B669E038BA84F708DF26ADD18CE4F5F31A5C9338188F9
EB29EDD6211836E6D1877A1658E648BEB749091CE7D459DBD82DC57C84BC52B1

Referências

[1] Arquitetura do driver em modo kernel
[2] Driver para ocultar processos e arquivos
[3] Um trecho de código para ocultar entradas de registro
[4] Oculto
[5] Abrindo a porta do hacker
[6] Ocultando driver carregado com DKOM
[7] Crashdmp -ster Mergulhando no Windows 8 Crash Dump Stack
[8] Drivers fantasmas chamados dump _ *. sys
[9] Driver Signing
[10] Hosts australianos atingidos por um Manic Menagerie de malware

Apêndice A

Entradas de registro usadas na rotina inicial

\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceAddress
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceNumber
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceId
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceName
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceNameB
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceNameOnly
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverMaker1
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverMaker1_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverMaker2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverMaker2_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDevicePathA
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDevicePathB
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverPath1
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverPath1_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverPath2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverPath2_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceDataA
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDeviceDataB
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverDataA
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverDataA_2
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverDataB
\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\WinApi\\WinDriverDataB_2


Apêndice B

Exemplo de entradas de registro configurando o driver

Chave: ControlSet001\Control\WinApi
Valor: WinDeviceAddress
Dados Ms312B9050App:;   

Valor: WinDeviceNumber
Dados:
\WINDOWS\AppPatch\Ke601169.xsl;
\WINDOWS\AppPatch\Ke237043.xsl;
\WINDOWS\AppPatch\Ke311799.xsl;
\WINDOWS\AppPatch\Ke119163.xsl;
\WINDOWS\AppPatch\Ke531580.xsl;
\WINDOWS\AppPatch\Ke856583.xsl;
\WINDOWS\AppPatch\Ke999860.xsl;
\WINDOWS\AppPatch\Ke410472.xsl;
\WINDOWS\AppPatch\Ke673389.xsl;
\WINDOWS\AppPatch\Ke687417.xsl;
\WINDOWS\AppPatch\Ke689468.xsl;
\WINDOWS\AppPatch\Ac312B9050.sdb;
\WINDOWS\System32\Ms312B9050App.dll;

Valor: WinDeviceName
Dados:
C:\WINDOWS\AppPatch\Ac312B9050.sdb;
C:\WINDOWS\System32\Ms312B9050App.dll;

Valor: WinDeviceId
Dados dump_FDC.sys:;

Deseja ler mais sobre segurança? Clique aqui…

By Lucas Rodrigues Monteiro

Bacharel em Sistemas da Informação, Certificado MCTS 70-680 / MOS, Trabalho como Administrador de Redes, Firewall e Servidores Windows e Linux! Minhas atividades favoritas são: Caminhar, Fazer Trilhas, Natureza, Insetos e claro ler sobre Tecnologia.

Deixe uma resposta

Translate »