O código fonte do Trojan bancário Pegasus foi
publicado recentemente. Apesar da menção do grupo Carbanak em nome do arquivo, pesquisadores do Minerva Labs
negaram o envolvimento do Trojan nesse grupo e provaram seu envolvimento no grupo
Buhtrap (Ratopak). Dentro do arquivo, há uma breve descrição do trabalho do Trojan, seus códigos-fonte, uma descrição do sistema de pagamento bancário e os dados de funcionários de muitos bancos russos.
A arquitetura do código-fonte desse malware é bastante interessante. A funcionalidade é dividida em módulos montados em um único "binpack" no estágio de compilação. O processo de compilação também inclui a assinatura de arquivos executáveis com um certificado do arquivo tric.pfx, que não está no arquivo morto.
Não menos curiosa é a atividade de rede do Pegasus, que, após a infecção, tenta se espalhar dentro do domínio e sabe como proxy de dados entre máquinas que usam pipes e o transporte Mailslot. Nós nos concentramos em estudar os recursos da atividade de rede do Trojan e adicionamos rapidamente o Pegasus detecta o produto
PT Network Attack Discovery . Isso permitirá que todos os seus usuários detectem oportunamente a atividade desse cavalo de Troia e suas modificações na rede. Neste artigo, darei uma descrição detalhada dos mecanismos de distribuição de rede e a interação entre cópias do Pegasus.
Introdução
Uma vez na máquina, o módulo principal InstallerExe injeta o código no svchost.exe usando a técnica Process Hollowing e, após inicializar os módulos principais, o Pegasus inicia vários processos paralelos:
- Replicação de Domínio - envolve inteligência na rede e tenta se espalhar para outras máquinas Windows.
- O Ouvinte do Mailslot ouve mensagens de broadcast do slot de correio, através das quais o Pegasus envia contas mineradas. O nome do slot é gerado em tempo de compilação.
- O ouvinte do servidor de tubos escuta o tubo do Windows com o nome gerado em nome da máquina. Esses tubos são usados principalmente para detectar outras cópias do Pegasus na rede e sua interação.
- Senhas de logon periodicamente, a cada poucos minutos, tentam despejar dados da conta com um módulo da Mimikatz.
- A conectividade de rede é responsável pela comunicação com o servidor CnC e mensagens periódicas.
// start transports which links data with our CB-manager pwInitPipeServerAsync(dcmGetServerCallback()); mwInitMailslotServer(dcmGetServerCallback()); ... // start broadcasting creds to other machines cmStartupNetworkBroadcaster();
Replicação de domínio
Um dos subsistemas do Pegasus é responsável pelo movimento lateral em uma rede Windows. A distribuição é dividida em duas etapas importantes:
- Detecção de carros vizinhos.
- Tentativa de replicação em uma máquina.
A descoberta de máquinas vizinhas em um domínio é feita através de duas chamadas de API:
NetServerEnum, que requer o serviço Navegador e chama WNetOpenEnum / WNetEnumResource.
Todas as máquinas encontradas no domínio devem ser verificadas se já estiverem infectadas. O Pegasus pesquisa o nome do tubo gerado a cada 200 milissegundos por mais de 20 vezes seguidas. Usamos esse comportamento anormal como um dos indicadores da atividade do Pegasus no domínio. Como não detectou nenhum sinal de infecção, o malware prossegue para a próxima etapa - tentativa de replicação.
A replicação é a seguinte. Usando as contas encontradas (KM) no host, o Pegasus tenta efetuar login na máquina usando o protocolo SMB nas esferas IPC $ e ADMIN $ e, se houver acesso ao IPC $ e não houver acesso ao ADMIN $, o Pegasus conclui que está certo a conta é insuficiente e deve ser marcada como inválida. Tendo obtido acesso ao ADMIN $ ball, que é um alias para a pasta% windir%, o malware tenta determinar a arquitetura da máquina para usar o módulo apropriado no futuro.
O algoritmo de determinação da arquitetura é baseado em cabeçalhos de arquivo PE na máquina remota. Como um arquivo, o Pegasus tenta ler os 4 primeiros kilobytes do notepad.exe na pasta% windir%. Uma desvantagem óbvia desse método é que, no Windows Server 2012, o bloco de notas está localizado no caminho% windir% \ System32.
Localização notepad.exe no Windows 7:
C:\Users\Administrator>where notepad.exe C:\Windows\System32\notepad.exe C:\Windows\notepad.exe
No Windows Server 2012:
C:\Users\Administrator>where notepad.exe C:\Windows\System32\notepad.exe
Se não detectar o notepad.exe, o Pegasus não poderá infectar o servidor, mesmo que tenha informações da conta com os direitos necessários. A simples ausência de bloco de notas em% windir% pode interromper a distribuição do Pegasus no Windows Server 2012. O uso do regedit.exe a esse respeito é mais confiável.
Após definir com êxito a arquitetura do servidor de destino, o Pegasus carrega um pequeno conta-gotas RSE (Remote Service Exe) com cerca de 10 kilobytes de tamanho, cuja tarefa é carregar o pacote de bin dos módulos Pegasus através do tubo de forma clara e transferir o controle para o módulo Shellcode. O nome do conta-gotas é composto de maneira pseudo-aleatória e consiste em uma sequência de caracteres hexadecimais de 8 a 15 caracteres. O gerador pseudo-aleatório é inicializado dependendo do nome da máquina de destino e será o mesmo entre as partidas para evitar possíveis desordens de% windir% com cópias anteriores do conta-gotas.
O conta-gotas é verificado quanto à integridade e possível exclusão pelo antivírus, após o qual é iniciado por um dos dois mecanismos implementados - SCM ou WMI, e primeiro o Pegasus tenta iniciar o RSE por meio do mecanismo WMI e, somente depois, usando o Service Control Manager (SCM). Isso ocorre porque o SCM deixa mais rastreamentos nos logs do Windows. Os criadores do Pegasus também planejaram outros métodos de distribuição - Wsh Remote, Powershell Remoting, Task Scheduler e um módulo para executar comandos via RDP estava em desenvolvimento.
Como mencionado acima, após um lançamento bem-sucedido, o conta-gotas verifica e abre o canal para ouvir e transfere o controle para a carga útil recebida.
Como o código Pegasus é injetado pelo método Process Hollowing no processo svchost.exe, nem o módulo InstallerExe original deve permanecer no disco no caso de uma infecção primária, nem o conta-gotas RSE no caso de distribuição. Se o conta-gotas ainda estiver acessível por um caminho conhecido, o Pegasus o removerá do seu próprio modo:
- substituindo o conteúdo do arquivo por dados aleatórios;
- sobrescrever com dados vazios (zeros);
- renomear arquivo;
- exclusão de arquivo.
Após uma infecção bem-sucedida, o processo de distribuição da Replicação de Domínio é iniciado novamente.
Trabalhos de e-mail
Depois que o Pegasus obtiver acesso aos dados da conta de outra cópia do Pegasus ou do módulo mod_LogonPasswords, ele começará a transmitir dados dos EUA por domínio. A distribuição é realizada usando o mecanismo SMB baseado em Mailslot, que permite a transmissão unidirecional de uma pequena porção de dados em um domínio. A distribuição ocorre de acordo com um nome de slot gerado aleatoriamente e, para que todas as máquinas infectadas no domínio possam enviar e receber dados por um único nome, o gerador pseudo-aleatório de nomes é inicializado a partir da variável TARGET_BUILDCHAIN_HASH especificada na configuração durante a compilação.
Como o mecanismo Mailslot impõe um limite no tamanho máximo do pacote, apenas um KM é enviado por vez, de acordo com o princípio da última hora de correspondência: entre todos os KMs disponíveis, o domínio cuja última data de correspondência é a mais antiga é enviado por domínio.
Os dados no Mailslot não são transmitidos em texto não criptografado, mas agrupados em três camadas de criptografia XOR, e as chaves são transmitidas junto com os dados. A primeira camada de dados é o envelope NetMessageEnvelope com verificação de integridade de dados pelo algoritmo SHA1, usado para todos os dados transmitidos pela rede local. 4 bytes de dados no início do pacote são a chave, que é alterada por mudanças de bits de 5 bits à direita por ciclo. Dentro do envelope, há uma estrutura de dados codificada em XOR com campos diretos nos EUA e a data em que foram adicionados. A chave de 8 bytes também está localizada no início da estrutura, mas é aplicada sem compensações. Após decodificar a estrutura do KM, resta apenas desserializar os campos individuais das estruturas ENC_BUFFER, como nome do computador, nome do domínio, nome do usuário e senha. Esses campos são criptografados com uma chave de 8 bytes com compensações. O script para descriptografar o pacote Mailslot e um exemplo desse pacote podem ser encontrados aqui:
script ,
PCAP .
O período para o envio de mensagens do Mailslot na versão de lançamento varia de 20 segundos a 11 minutos.
// some random wait before making next step DbgPrint("going to sleep");
Além de trocar contas, o mecanismo Mailslot é usado para procurar uma máquina infectada com acesso à Internet e para anunciar o acesso à Internet. O envelope NetMessageEnvelope armazena o tipo de mensagem que está sendo enviada. A troca de dados entre a máquina sem acesso e a máquina com acesso à Internet é realizada através dos tubos.
Obras de tubulação
Para comunicação bidirecional ou transferência de grandes quantidades de dados, as cópias Pegasus usam pipes como canal de comunicação. O nome do canal, embora também seja gerado por um gerador pseudo-aleatório, mas depende do nome da máquina e da construção e, portanto, permite que as partes do cliente e do servidor usem o mesmo nome.
Na comunicação unidirecional, por exemplo, ao transferir o binpack durante a replicação para outra máquina, os dados não são criptografados e transmitidos de forma clara. O Binpack começa com uma estrutura SHELLCODE_CONTEXT com um comprimento de 561 bytes.
Durante a transmissão bidirecional, por exemplo, proxy de dados entre uma cópia do Pegasus sem acesso à Internet e um servidor CnC, a mesma estrutura de envelope NetMessageEnvelope com criptografia XOR é usada como no caso do Mailslot, porque permite distinguir entre diferentes tipos de mensagens no campo id.
Em termos de arquitetura, o proxy de dados é realizado por meio de uma solicitação para transferir uma parte dos dados (PMI_SEND_QUERY), receber a identificação da solicitação em resposta e consultar o status da tarefa por identificação (PMI_CHECK_STATUS_QUERY). Como regra, outra estrutura do Envelope é transferida como carga, adicionando várias funcionalidades e outra camada de criptografia.
Além disso, trabalhar com pipes não termina na interação entre máquinas infectadas. O módulo mod_KBRI_hd injeta código nos processos cmd.exe que intercepta as chamadas MoveFileExW e analisa todos os dados que estão sendo copiados, pois isso faz parte do processo de pagamento. Se o arquivo copiado contiver dados de interesse dos invasores - dados com pagamentos, uma notificação sobre isso será enviada ao servidor CnC. A comunicação entre o módulo mod_KBRI injetado no cmd.exe e uma cópia do Pegasus é realizada dentro da máquina infectada por meio de um canal cujo nome não é gerado, mas está codificado no código fonte:
\.\pipe\pg0F9EC0DB75F67E1DBEFB3AFA2
A funcionalidade do módulo também inclui a substituição de contas de dados em tempo real, de acordo com o modelo. Um exemplo de padrões para pesquisar na captura de tela.
Tráfego Cnc
Um fluxo separado é responsável pela troca direta de dados com o servidor CnC, que verifica a fila de blocos de dados de processos internos ou outras cópias de malware a cada poucos minutos e os envia ao servidor.
Durante a inicialização do módulo mod_NetworkConnectivity, ele executa uma verificação de vários estágios da conexão de rede:
1) Detectando configurações do servidor proxy e tentando se conectar ao
www.google.com :
- Na ramificação do registro \\ Software \\ Microsoft \\ Windows \\ CurrentVersion \\ Internet Settings.
- Via WPAD (chame WinHttpGetProxyForUrl).
- Por meio da configuração de proxy para o usuário atual (chame WinHttpGetIEProxyConfigForCurrentUser).
2) Verificando a conexão com os servidores de atualização da Microsoft e os dados retornados (
authrootseq.txt ,
authrootstl.cab ,
rootsupd.exe )
3) Testando conexões HTTPS com um dos 6 endereços:
Somente após passar todas as verificações, a Pegasus acredita que possui o acesso necessário à rede externa e pode anunciar isso através do domínio Mailslot com uma mensagem. Além disso, o Pegasus pode se disfarçar e se comunicar com o servidor CnC apenas durante o horário comercial - das 9h às 19h, horário local.
O Pegasus envia pedaços de dados embrulhados em um envelope com o cálculo do hash da quantia no formato criptografado usando a criptografia DES no modo CRYPT_MODE_CBC / PKCS5_PADDING. A chave de criptografia depende apenas da variável durante a compilação e, portanto, podemos descriptografar o tráfego entre o malware e o servidor, conhecendo apenas seu BUILDCHAIN_HASH. No código-fonte dentro do arquivo morto, essa variável tinha o valor 0x7393c9a643eb4a76. Um script para descriptografar o Check-in no servidor e um exemplo desse pacote podem ser encontrados aqui:
script ,
PCAP .
Ele transfere esse conteúdo (estrutura INNER_ENVELOPE) para o servidor CnC durante o Check-in ou junto com qualquer dado. Inicialmente, existem 28 bytes de um envelope com um campo de comprimento e uma soma SHA1.
Os mesmos dados são transferidos entre máquinas durante o proxy através de pipes, mas agrupados dentro do envelope NetMessageEnvelope que conhecemos com uma soma de hash e criptografia XOR.
O operador CnC pode enviar comandos para execução às cópias e mensagens do Pegasus com comandos ou outros dados, por exemplo, EID_CREDENTIALS_LIST pode conter suas próprias camadas de criptografia de campo, como vimos no exemplo de contas de transmissão.
Detecção
Antes de tudo, estávamos interessados em detectar a atividade do Pegasus na rede e, depois de estudar cuidadosamente os códigos-fonte e executar no ambiente de teste, descobrimos essas anomalias e artefatos de rede que indicam claramente a presença desse malware complexo na rede. O Pegasus realmente pode ser chamado de versátil - ele usa ativamente o protocolo SMB para enviar mensagens e estabelecer comunicação com outras cópias, se espalha para outras máquinas e se comunica com o servidor CnC de maneira especial. Ao instalar uma rede ponto a ponto no domínio, as cópias do Pegasus abrem caminho para a rede externa e se comunicam com o servidor CnC ao proxyizar o tráfego entre si. O uso de certificados para assinar arquivos executáveis e o acesso aos recursos da Microsoft e Mozilla durante a verificação da conexão dificulta a detecção de sua atividade e detecção no host.
O projeto de código-fonte do Pegasus é bastante bem estruturado e descrito, portanto, em um futuro próximo, podemos esperar o empréstimo de partes de seu código por outros programas maliciosos e o aparecimento de modificações.
Muitos dos mecanismos para executar comandos remotamente e pesquisar dados da conta permaneceram não realizados, os desenvolvedores também adicionariam a capacidade de alterar o código de shell durante a implementação em tempo real. E estas não são todas as suas idéias.
Desenvolvemos várias assinaturas para PT NAD e IDS Suricata, que nos permitem identificar a atividade de rede específica do Pegasus em diferentes estágios, a partir dos primeiros segundos de sua atividade. Você pode encontrar assinaturas abertas para o Suricata IDS no
github e no
Twitter ; elas chegarão automaticamente ao seu Suricata se você usar o mecanismo de atualização suricata-update.
Você pode ver como as assinaturas da atividade Pegasus funcionam na captura de tela abaixo. Este é o nosso novo produto
PT Network Attack Discovery que identifica incidentes e ajuda a investigá-los:
Além disso, os seguintes indicadores de comprometimento (IC) podem ser usados para detecção:
MAILSLOT \ 46CA075C165CBB2786
pipe \ pg0F9EC0DB75F67E1DBEFB3AFA2
hxxp: //denwer/pegasus/index.php
hxxp: //mp3.ucrazy.org/music/index.php
hxxp: //support.zakon-auto.net/tuning/index.asp
hxxp: //video.tnt-online.info/tnt-comedy-tv/stream.php
Postado por Cyril Shipulin de @attackdetection,
Twitter |
Telegram