Operação ‘Harvest’: Um Mergulho Profundo em uma Campanha de Longo Prazo

A equipe de Pesquisa Avançada de Ameaças (ATR) da McAfee Enterprise trabalhou com sua equipe de RI de Serviços Profissionais para dar suporte a um caso que inicialmente começou como um incidente de malware, mas acabou se revelando um ataque cibernético de longo prazo. ATR fornece uma visão profunda desta campanha de longo prazo, onde eles irão mapear nossas descobertas em relação ao modelo Enterprise MITER ATT & CK. Eles também ampliarão e verão como a tradução para as Técnicas MITER, contexto histórico e artefatos de evidência como malware PlugX e Winnti levaram a um link com outra campanha, que acreditamos altamente para ser executada pelo mesmo adversário.

Sumário executivo

Após uma resposta a um incidente recente, a equipe de Pesquisa Avançada de Ameaças (ATR) da McAfee Enterprise trabalhou com sua equipe de RI de Serviços Profissionais para dar suporte a um caso que inicialmente começou como um incidente de malware, mas acabou sendo um ciberataque de longo prazo.

Do ponto de vista da inteligência cibernética, um dos maiores desafios é ter informações sobre táticas, técnicas e procedimentos (TTPs) que um adversário está usando e, em seguida, mantê-los atualizados. No ATR, normalmente monitoramos muitos adversários durante anos e coletamos e armazenamos dados, que variam de indicadores de comprometimento (IOCs) a TTPs.

Neste relatório, a ATR fornece uma visão profunda dessa campanha de longo prazo, na qual mapearemos nossas descobertas em relação ao modelo Enterprise MITER ATT & CK. Haverá partes que serão censuradas por respeitarmos a confidencialidade da vítima. Também daremos zoom e veremos como a tradução para as Técnicas MITER, o contexto histórico e os artefatos de evidências como o malware PlugX e Winnti levaram a um link com outra campanha, na qual confiamos altamente para ser executada pelo mesmo adversário.

Os IOCs que podem ser compartilhados estão no final deste documento.

Os clientes da McAfee estão protegidos contra malware / ferramentas descritas neste blog. Os clientes do MVISION Insights terão todos os detalhes, IOCs e TTPs compartilhados por meio de seu painel. As plataformas MVISION Endpoint, EDR e UCE fornecem capacidade de detecção e prevenção baseada em assinatura e comportamento para muitas das técnicas usadas neste ataque. Um blog mais detalhado com recomendações específicas sobre o uso do portfólio da McAfee e soluções integradas de parceiros para se defender contra esse ataque pode ser encontrado aqui .

Análise técnica

Vetores de infecção inicial [ TA0001 ]

Investigações forenses identificaram que o ator estabeleceu o acesso inicial ao comprometer o servidor web da vítima [ T1190 ]. No servidor web, um software foi instalado para manter a presença e armazenamento de ferramentas [ T1105 ] que seriam usadas para coletar informações sobre a rede da vítima [ T1083 ] e movimentação lateral / execução de arquivos [ T1570 ] [ T1569.002 ]. Exemplos das ferramentas descobertas são PSexec, Procdump e Mimikatz.

Escalonamento e persistência de privilégios [ TA0004 ,  TA0003 ]

O adversário foi observado usando técnicas de escalonamento de privilégios múltiplos e persistência durante o período de investigação e presença na rede. Vamos destacar alguns em cada categoria.

Além do uso de Mimikatz para despejar credenciais, os adversários usaram duas ferramentas para escalonamento de privilégios [ T1068 ]. Uma das ferramentas era o “RottenPotato”. Esta é uma ferramenta de código aberto que é usada para obter um identificador para um token privilegiado, por exemplo, “NT AUTHORITY \ SYSTEM”, para poder executar tarefas com direitos de sistema.

Exemplo de RottenPotato sobre a elevação desses direitos:

Figura 1 RottenPotato

 

A segunda ferramenta descoberta, “BadPotato”, é outra ferramenta de código aberto que pode ser usada para elevar os direitos do usuário aos direitos do sistema.

Figura 2 BadPotato

 

O código BadPotato pode ser encontrado no GitHub, onde é oferecido como um projeto do Visual Studio. Inspecionamos a versão compilada do adversário usando DotPeek e procuramos por artefatos no código. Inspecionando o cabeçalho do arquivo (COFF), observamos o carimbo de data / hora de compilação do arquivo:

TimeDateStamp: 05/12/2020 08:23:47 – Data e hora em que a imagem foi criada

PlugX

Outra técnica importante e característica de escalonamento de privilégios que o adversário usou nesta campanha de longo prazo foi o PlugX de malware como backdoor. O PlugX usa a técnica “DLL Sideloading” [ T1574.002 ]. O PlugX foi observado como de costume, onde um único executável (RAR) continha as três partes:

• Executável válido.
• DLL associada com o gancho para a carga útil.
• Arquivo de carga útil com a configuração para se comunicar com o Command & Control Server (C2).

O adversário usou a versão autônoma ou distribuiu três arquivos em diferentes ativos na rede para obter o controle remoto desses ativos. As amostras descobertas e analisadas comunicavam para dois domínios. Ambos os domínios foram registrados durante o período da campanha.

Uma das amostras do PlugX consistia nas seguintes três partes:

Nome do arquivo	Hashes
HPCustPartic.exe	SHA256: 8857232077b4b0f0e4a2c3bb5717fd65079209784f41694f8e1b469e34754cf6
HPCustPartUI.dll	SHA256: 0ee5b19ea38bb52d8ba4c7f05fa1ddf95a4f9c2c93b05aa887c5854653248560
HPCustPartic.bin	SHA256: 008f7b98c2453507c45dacd4a7a7c1b372b5fafc9945db214c622c8d21d29775

O arquivo .exe é um executável válido e assinado e, neste caso, um executável da HP (participação do cliente HP). Também observamos outros executáveis ​​válidos sendo usados, variando de fornecedores de antivírus a software de vídeo. Quando o executável é executado, a DLL ao lado dele é carregada. A DLL é válida, mas contém um pequeno gancho para a carga útil que, em nosso caso, é o arquivo .bin. A DLL carrega a configuração do PlugX e a injeta em um processo.

Executamos as amostras em uma configuração de teste e despejamos a memória da máquina para realizar análises de memória com volatilidade. Após as etapas básicas de análise forense, executamos o plug-in malfind para detectar possível código injetado em um processo. A partir da saída redigida do plugin, observamos os seguintes valores para o processo com possível código injetado:

Processo: svchost.exe Pid: 860 Endereço: 0xb50000

Processo: explorer.exe Pid: 2752 Endereço: 0x56a000

Processo: svchost.exe Pid: 1176 Endereço: 0x80000

Processo: svchost.exe Pid: 1176 Endereço: 0x190000

Processo: rundll32.exe Pid: 3784 Endereço: 0xd0000

Processo: rundll32.exe Pid: 3784 Endereço: 0x220000

Uma observação é a menção do processo SVCHOST com um valor ProcessID de 1176 que é mencionado duas vezes, mas com endereços diferentes. Isso é semelhante ao RUNDLL32.exe que é mencionado duas vezes com o PID 3785 e endereços diferentes. Uma maneira de identificar qual malware pode ter sido usado é despejar esses processos com o PID relevante usando o módulo procdump, carregá-los para um serviço de análise online e esperar pelos resultados. Como este é um caso muito delicado, adotamos uma abordagem diferente. Usando o melhor dos dois mundos (volatilidade e Yara), usamos um conjunto de regras que consiste em padrões de malware observados na memória ao longo do tempo. A execução desse conjunto de regras sobre os dados no despejo de memória revelou a seguinte saída (redigida para fins de legibilidade):

Figura 3 Despejo de memória Yarascan de saída

 

A saída da varredura de regra de Yara (e havia muito mais saída) confirmou a presença do código do módulo PlugX no PID 1176 do serviço SVCHOST. Além disso, a regra foi disparada no PID 3784, que pertencia ao RUNDLL32.exe.

Investigando os dumps após a análise dinâmica, observamos dois nomes de domínio usados ​​para o tráfego C2:

• sery.brushupdata.com
• dnssery.brushupdata.com

Em particular, vimos o seguinte valor codificado que pode ser outra carga sendo baixada:

sery.brushupdata.com/CE1BC21B4340FEC2B8663B69

As famílias PlugX que observamos usavam DNS [ T1071.001 ] [ T1071.004 ] como canal de transporte para o tráfego C2, em particular consultas TXT. Investigando o tráfego de nossas amostras, observamos a assinatura de verificação (“20 2A 2F 2A 0D”) que é típica para o tráfego de rede PlugX:

00000000: 47 45 54 20 2F 42 34 42 42 44 43 43 30 32 39 45

00000010: 31 31 39 37 31 39 46 30 36 35 36 32 32 20 48 54

00000020: 54 50 2F 31 2E 31 0D 0A 41 63 63 65 70 74 3A 20

00000030:            2A 2F 2A 0D 0A 43 6F 6F 6B 69 65 3A 20 44 36 43

00000040: 57 50 2B 56 5A 47 6D 59 6B 6D 64 6D 64 64 58 55

00000050: 71 58 4D 31 71 31 6A 41 3D 0D 0A 55 73 65 72 2D

Durante nossa análise das diferentes amostras de PlugX descobertas, os nomes de domínio mencionados acima permaneceram os mesmos, embora os valores de carga útil fossem diferentes. Por exemplo:

• hxxp: //sery.brushupdata.com/B4BBDCC029E119719F065622
• hxxp: //sery.brushupdata.com/07FDB1B97D22EE6AF2482B1B
• hxxp: //sery.brushupdata.com/273CDC0B9C6218BC1187556D

Outros exemplos de PlugX que observamos se injetaram no Windows Media Player e iniciaram uma conexão com os dois domínios a seguir:

• center.asmlbigip.com
• sec.asmlbigip.com

Ola winnti

Outro mecanismo observado foi iniciar um programa como serviço [ T1543.003 ] no Sistema Operacional com os direitos de Sistema adquiridos usando as ferramentas * Potato. O arquivo que o adversário estava usando parecia ser um backdoor que estava usando o formato de arquivo DLL (2458562ca2f6fabddae8385cb817c172).

A DLL é usada para criar um serviço malicioso e seu nome é “ service.dll ”. O nome do serviço criado, “SysmainUpdate”, está usurpando o nome do serviço legítimo “SysMain” que está relacionado à DLL legítima sysmain.dll e também ao serviço Superfetch. A dll é executada usando o comando “rundll32.exe SuperFrtch.dll, # 1”. A função de exportação tem o nome “WwanSvcMain”.

O modelo usa a técnica de persistência utilizando svchost.exe com service.dll para instalar um serviço não autorizado. Parece que a dll emprega vários mecanismos para identificar o sistema de destino e evitar a análise na sandbox, tornando a análise mais difícil. A DLL incorpora várias strings ofuscadas decodificadas durante a execução. Uma vez que a impressão digital foi feita, o malware instalará o serviço malicioso usando a API RegisterServiceHandlerA, SetServiceStatus e, finalmente, CreateEventA. Uma descrição da técnica pode ser encontrada aqui .

O malware também descriptografa e injeta a carga útil na memória. A captura de tela a seguir mostra a rotina de descriptografia.

Figura 4 Rotina de descriptografia

 

Quando analisamos essa rotina única, descobrimos semelhanças e a menção dela em uma publicação que pode ser lida aqui . O malware descrito no artigo é atribuído à família de malware Winnti. O método operacional e o código usado na DLL descrito no artigo são muito semelhantes às nossas análises e observações.

O despejo do processo também revelou outros indicadores. Primeiramente, revelou artefatos relacionados à DLL analisada, “C: \ ProgramData \ Microsoft \ Windows \ SuperfRtch \ SuperfRtch.dat”. Acreditamos que esse arquivo dat pode ser a carga útil carregada.

Em segundo lugar, ao investigar o despejo do processo, observamos atividades da porta dos fundos que fazem parte das tentativas de exfiltração de dados que descreveremos com mais detalhes neste relatório de análise.

Um snippet redigido do código teria a seguinte aparência:

Criando arquivo ***. Rar

Adicionando [dados do local]

  0%

  OK

Outro indicador de descoberta de malware Winnti foi o seguinte caminho de execução que descobrimos no despejo de linha de comando da memória:

cmd / c klcsngtgui.exe 1560413F7E <abbreviation-victim> .dat

O que observamos aqui foi o uso de um executável válido, a chave de descriptografia AES 256 da carga útil (arquivo .dat). Nesse caso, o arquivo de carga útil foi nomeado usando uma abreviatura do nome da empresa vítima. Infelizmente, o adversário removeu o arquivo de carga útil do sistema. A escultura de arquivo não funcionou porque o disco / espaço não alocado foi sobrescrito. No entanto, a reconstrução de rastros da memória revelou que estávamos lidando com o malware Winnti 4.0. O malware foi injetado em um processo SVCHOST onde um local do driver apontava para o arquivo de configuração. Observamos no processo de despejo a exfiltração de dados no sistema, como SO, Processador (arquitetura), Domínio, Nome de Usuário, etc.

Outra pista que nos ajudou foi o uso de tunelamento de DNS pelo Winnti, do qual descobrimos vestígios na memória. O código 208.67.222.222 codificado é resolvido para um servidor DNS OpenDNS legítimo. O IP é colocado na lista gerada pelo malware em tempo de execução. No início do malware, ele preenche a lista com o DNS do sistema, e o servidor OpenDNS é usado apenas como backup para garantir que o domínio C2 seja resolvido.

Outro indicador no despejo do processo foi a configuração da conexão C2 incluindo o User-Agent que foi observado sendo usado pelo malware Winnti 4.0:

Mozilla / 5.0 (Windows NT 6.3; WOW64) AppleWebKit / 537.36 (KHTML, como Gecko) Chrome / 57.0.2987.133 Safari / 537.36

Outras Atividades de Persistência

A atividade WMI [ T1546.003 ] também foi observada para executar comandos nos sistemas.

Do ponto de vista da persistência, tarefas agendadas [ T1053.005 ] e o uso de contas válidas [ T1078 ] adquiridas através do uso de Mimikatz, ou criando lixeiras LSASS, foram observadas sendo utilizadas durante a duração da campanha.

Movimento lateral

De uma perspectiva de movimento lateral, o adversário usou as credenciais obtidas para pular de ativo em ativo. Em um caso particular, observamos um nome de arquivo familiar: “PsExec.exe”. Esta ferramenta SysInternals é frequentemente observada sendo usada em movimentos laterais por adversários, no entanto, ela também pode ser usada pelos administradores de sistemas da rede. Em nosso caso, o executável PsExec tinha um tamanho de arquivo de 9,6 MB, enquanto o PsExec original (dependendo da versão de 32 ou 64 bits) tinha um tamanho máximo de arquivo de 1,3 MB. Uma inspeção estática inicial do arquivo resultou em um blob de código que estava presente no executável com uma pontuação de entropia muito alta (7,99). Ao executar o arquivo a partir da linha de comando, a seguinte saída foi observada:

Figura 5 saída PsExec

 

A notificação de erro e a palavra-chave ‘Impacket’ nos deram uma dica e, depois de vasculhar, encontramos mais. O falso PsExec é um script Python de código aberto que é uma alternativa ao PsExec com capacidade de shell / backdoor. Ele usa um script deste local: hxxps: //github.com/SecureAuthCorp/impacket/blob/master/examples/psexec.pyi. O arquivo é grande, pois incorpora uma interação de protocolo de baixo nível do Impacket. A biblioteca Python combinada com o código do script é compilada com py2exe. O arquivo foi compilado durante o período das atividades de ataque mais recentes e assinado com um certificado expirado.

Exfiltração de dados

Pelo que observamos, o adversário tinha uma intenção de longo prazo de se manter presente na rede da vítima. Com grande confiança, acreditamos que o adversário estava interessado em roubar inteligência proprietária que poderia ser usada para fins militares ou de propriedade intelectual / manufatura.

O adversário usou várias técnicas para filtrar os dados. Em alguns casos, scripts em lote (.bat) foram criados para coletar informações de certos compartilhamentos / pastas de rede e usar a ferramenta ‘rar’ para compactá-los até um determinado tamanho [ T1020] [ T1030 ]. Exemplo de conteúdo em um script de lote:

C: \ Windows \ web \ rar.exe a – [redigido] -r -v50000 [diretório de destino]

Em outras ocasiões, variantes manuais do comando acima foram descobertas após o uso da porta dos fundos personalizada, conforme descrito anteriormente.

Quando os dados foram coletados em um sistema local usando o backdoor, os arquivos foram exfiltrados pelo backdoor e os arquivos rar foram excluídos [ T1070.004 ]. Onde ativos externos foram usados, como um servidor web, os dados foram armazenados em um local no servidor web Internet Information Services (IIS) e exfiltrados por HTTP usando solicitações GET para os caminhos de arquivo exatos [ T1041 ] [ T1567] [ T1071 ] .

Um exemplo de tráfego da web [redigido] nos arquivos de log do IIS:

Data hora		Solicitar	Porta TCP Src	IP fonte	Agente de usuário
Editado	GET /****/[redacted].rar		80	180,50. *. *	MINIXL
redigido	GET /****/[redacted].rar		80	209.58. *. *	MINIXL

Os endereços IP de origem descobertos pertenciam a dois provedores ISP / VPN diferentes baseados em Hong-Kong.

O valor do Agente do Usuário é interessante, “MINIXL”. Quando pesquisamos esse valor, descobrimos um blog do Dell SecureWorks de 2015 que menciona o mesmo User-Agent, mas também muitos dos artefatos mencionados no blog se sobrepõem às observações e TTPs da Operação Harvest [ link ].

O que poderíamos recuperar dos bancos de dados de código aberto é que o uso desse User-Agent em particular é muito limitado e parece se originar da região APAC.

Quem fez isso?

Essa parece ser a pergunta de um milhão de dólares a ser feita. Na McAfee, a atribuição não é nosso foco principal, proteger nossos clientes é nossa prioridade. O que nos importa é que, se aprendermos sobre essas técnicas durante uma investigação, podemos mapeá-las e apoiar nossa equipe de RI no terreno, ou a equipe de RI de um cliente, com o conhecimento que pode ajudar a determinar em qual fase do ataque o as evidências estão apontando e baseadas em dados históricos e inteligência, ajudar no bloqueio da próxima fase e descobrir mais evidências?

Começamos mapeando todas as técnicas e subtécnicas do MITER ATT & CK Enterprise, adicionamos as ferramentas usadas e fizemos uma comparação com os dados técnicos históricos da indústria. Acabamos com quatro grupos que compartilhavam técnicas e subtécnicas. O grupo Winnti foi adicionado por nós desde que descobrimos a função de criptografia exclusiva no backdoor personalizado e indicadores do uso do malware Winnti.

Figura 6 Comparação da técnica ATT e CK

 

O diagrama que reflete nosso resultado insinuou que APT27 e APT41 são os candidatos mais prováveis ​​que se sobrepõem às (sub) técnicas que observamos.

Como todos esses grupos estão em um determinado fuso horário, extraímos todos os carimbos de data / hora da investigação forense com relação a:

• Registro de domínio
• Compilar carimbos de data / hora de malware (considerando engano)
• Timestamps de atividade de linha de comando
• Timestamps de exfiltração de dados
• Carimbos de data e hora da interação do malware, como criação, exclusão, etc.

Quando convertemos todos esses carimbos de data / hora de UTC para os fusos horários dos grupos mencionados acima, terminamos com o esquema de atividade abaixo:

Figura 7 Tempo de operação do adversário

 

Nesta campanha, observamos como o adversário parece trabalhar principalmente de segunda a quinta-feira e tipicamente durante o expediente, embora com algumas exceções pontuais.

As (sub) técnicas de ATT & CK correlacionadas, carimbos de data / hora e ferramentas como PlugX e Mimikatz não são os únicos indicadores de evidência que podem ajudar a identificar um possível adversário. Sintaxe de linha de comando, similaridade de código específico, capacidade do ator ao longo do tempo versus outros grupos e identificadores exclusivos estão no topo da ‘pirâmide de dor’ em inteligência de ameaças. A parte inferior da pirâmide é sobre hashes, URLs e domínios, áreas que são muito voláteis e fáceis de alterar por um adversário.

Figura 8 Pirâmide da Dor

 

Além de investigar esses artefatos, também levamos em consideração possíveis interesses geopolíticos e possíveis enganos ao construir nossa hipótese. Quando mapeamos todos esses, acreditamos que um dos dois grupos mencionados anteriormente fosse o responsável pela campanha que investigamos.

Porém, nosso foco não era sobre atribuição, mas mais em torno de onde está o fluxo do ataque, correspondências contra fluxos de ataques anteriores de grupos e quais técnicas / ferramentas eles estão usando para bloquear as próximas etapas ou onde localizá-los. Quanto mais detalhes pudermos reunir no topo da “pirâmide da dor”, melhor podemos determinar o provável adversário e seus TTPs.

Isso é tudo, pessoal!

Bem, na verdade não. Ao correlacionar as (sub) técnicas observadas, as famílias e o código do malware, descobrimos outro ataque direcionado contra um alvo semelhante na mesma nação com a principal motivação de reunir inteligência. No diagrama a seguir, conduzimos uma comparação de alto nível das ferramentas sendo usadas pelo adversário:

Figura 9 Comparação de ferramentas

 

Embora algumas das ferramentas sejam exclusivas para cada campanha, se forem levadas em consideração ao longo do tempo com o momento em que foram usadas, fazem sentido. Ele demonstra o desenvolvimento do ator e o uso de ferramentas mais novas para conduzir o movimento lateral e obter o nível necessário de direitos do usuário nos sistemas.

No geral, observamos o mesmo modus operandi. Uma vez que um ponto de apoio inicial fosse estabelecido, o adversário implantaria o PlugX inicialmente para criar alguns backdoors na rede da vítima, caso fossem descobertos logo no início. Depois disso, usando Mimikatz e despejando lsass, eles estavam procurando contas válidas. Depois que as contas válidas foram adquiridas, várias ferramentas, incluindo algumas de suas próprias ferramentas, foram usadas para obter informações sobre a rede da vítima. A partir daí, vários compartilhamentos / servidores foram acessados ​​e as informações coletadas. Essas informações foram exfiltradas como arquivos rar e colocadas em um servidor voltado para a Internet para se esconder no tráfego ‘normal’. Representamos isso no gráfico a seguir:

Figura 10 Fluxo de ataque

 

No caso 2019/2020, também observamos o uso de uma amostra de malware que classificaríamos como parte da família de malware Winnti. Descobrimos alguns arquivos que foram executados pelo seguinte comando:

Inicie Ins64.exe E370AA8DA0 Jumper64.dat

O carregador Winnti ‘Ins64.exe’ usa o valor ‘E370AA8DA0’ para descriptografar a carga do arquivo .dat usando o algoritmo de descriptografia AES-256-CTR e começa a executar.

Após executar este comando e analisar a memória, observamos uma injeção de processo em um dos processos svchost em que um determinado arquivo foi carregado a partir do seguinte caminho:

C: \ programdata \ microsoft \ windows \ caches \ ieupdate.dll

Figura 11 Captura de memória

 

 

O malware começou a abrir as portas UDP e TCP para se conectar a um servidor C2.

Porta UDP 20502

Porta TCP 20501

Figura 12 Conexões de rede para C2

 

Capturando o tráfego do malware, observamos o seguinte como exemplo:

Figura 13 Tráfego HTTP Winnti para C2

 

s dados do pacote foram personalizados e enviados por meio de uma solicitação POST com vários cabeçalhos para o C2. Na imagem acima, os números após “POST /” foram gerados aleatoriamente.

O User-Agent é um bom indicador de rede para identificar o malware Winnti, pois é usado em várias variantes:

Mozilla / 5.0 (Windows NT 6.3; WOW64) AppleWebKit / 537.36 (KHTML, como Gecko) Chrome / 50.0.2661.94 Safari / 537.36

Na verdade, o mesmo valor de agente do usuário foi descoberto na amostra Winnti na Operação Harvest e parece ser típico desta família de malware.

O valor do cookie consiste em quatro valores hexadecimais Dword que contêm informações sobre o tamanho do pacote personalizado usando um valor XOR.

Aprendemos mais sobre a estrutura de pacotes do Winnti neste link .

Aplicando o que aprendemos sobre o aperto de mão, observamos o seguinte em nossa amostra de tráfego:

Valor Dword 0 = 52 54 00 36

Valor Dword 1 = 3e ff 06 b2

Valor Dword 2 = 99 6d 78 fe

Valor Dword 3 = 08 00 45 00

Valor Dword 4 = 00 34 00 47

Pedido de handshake inicial:

Com base em nossa correlação cruzada com amostras e outros recursos OSINT, acreditamos com alta confiança que esta foi uma amostra Winnti 4.0 que se conecta a um servidor Winnti C2 confirmado.

O servidor C2 identificado foi 185.161.211.97 TCP / 80.

Cronograma de Eventos

Ao analisar os carimbos de data / hora desta investigação, como fizemos para a operação Colheita, chegamos à visão geral abaixo:

Figura 14 Caso de horário de trabalho de Pequim 2019/2020

 

Novamente, observamos que o adversário estava operando de segunda a sexta-feira durante o horário comercial no fuso horário de Pequim.

Conclusão

A Operação Colheita é uma operação de longo prazo em que um adversário mantém o acesso por vários anos para extrair dados. Os dados exfiltrados teriam sido parte de um roubo de propriedade intelectual para fins econômicos e / ou teriam fornecido informações que seriam benéficas no caso de intervenções militares. Os adversários usaram técnicas frequentemente observadas nesse tipo de ataque, mas também usaram backdoors ou variantes distintas de novas famílias de malware. Combinando todos os artefatos forenses e correlação cruzada com dados históricos e geopolíticos, temos alta confiança de que esta operação foi executada por um ator APT experiente.

Depois de mapear todos os dados, TTPs etc., descobrimos uma sobreposição muito forte com uma campanha observada em 2019/2020. Muitos dos indicadores técnicos (detalhados) e técnicas coincidem. Também colocá-lo em perspectiva, e ao longo do tempo, demonstra que o adversário está adaptando habilidades e desenvolvendo as ferramentas e técnicas que estão sendo usadas.

Em uma nota separada, observamos o uso do malware Winnti. Mencionamos deliberadamente o termo ‘malware’ em vez de grupo. O malware Winnti é conhecido por ser usado por vários atores. Em cada atividade ciberofensiva de estado-nação, haverá um departamento / unidade responsável pela criação das ferramentas / malware, etc. Acreditamos fortemente que é exatamente o que observamos aqui também. PlugX, Winnti e algumas outras ferramentas personalizadas apontam para um grupo que tinha acesso às mesmas ferramentas. Quer ponhamos o nome ‘X’ ou ‘Y’ no adversário, acreditamos fortemente que estamos lidando com um ator chinês cujos objetivos de longo prazo são a persistência nas redes de suas vítimas e a aquisição da inteligência necessária para tornar o político / estratégico ou decisões de fabricação.

Técnicas MITER ATT e CK

ID técnica	Título da Técnica	Campanha de Contexto
T1190	Explorar aplicativo voltado para o público	Adversary explorou um servidor voltado para a web com aplicativo
T1105	Transferência de ferramenta de ingresso	As ferramentas foram transferidas para um servidor comprometido com a web
T1083	Descoberta de arquivos e diretórios	Adversary navegou em vários locais para procurar os dados que procurava.
T1570	Transferência de ferramenta lateral	Ferramentas / backdoors transferidas do adversário para manter a persistência
T1569.002	Serviços do Sistema: Execução de Serviço	Adversary instalou backdoor personalizado como serviço
T1068	A exploração do escalonamento de privilégios	Adversary usou o Rotten / Bad Potato para elevar os direitos do usuário abusando de chamadas de API no sistema operacional.
T1574.002	Fluxo de execução de sequestro: carregamento lateral de DLL	Adversary usou malware PlugX, famoso por DLL-Side-Loading, usando um executável válido, uma DLL com o gancho para um arquivo de carga útil.
T1543.003	Criar ou modificar o processo do sistema: serviço do Windows	Adversary lançou backdoor e algumas ferramentas como um serviço do Windows, incluindo a adição de chaves de registro
T1546.003	Execução acionada por evento: Assinatura de evento WMI	WMI foi usado para executar comandos em sistemas remotos
T1053.005	Tarefa agendada	Adversary executou tarefas agendadas para persistência de certas amostras de malware
T1078	Contas válidas	Usando Mimikatz e despejando lsass, o adversário ganhou credenciais na rede
T1020	Exfiltração automatizada	O malware PlugX vazou dados para um C2 e recebeu comandos para coletar mais informações sobre o host comprometido da vítima.
T1030	Limites de tamanho de transferência de dados	Adversary limitou o tamanho dos arquivos rar para exfiltração
T1070.004	Remoção do indicador no host	Onde no início da campanha o adversário era descuidado, nos últimos meses de atividade eles se tornaram mais cuidadosos e passaram a retirar as evidências
T1041	Exfiltração no canal C2	Adversary usou vários domínios C2 para interagir com hosts comprometidos.
T1567	Exfiltração sobre serviço da web	As informações coletadas eram armazenadas como arquivos ‘rar’ no servidor voltado para a Internet, após o que eram baixados por um intervalo de ip específico.
T1071.004	Protocolo da camada de aplicativo: DNS	Usando o túnel DNS para o tráfego C2 do malware PlugX

Indicadores de compromisso (IOCs)

Nota: os indicadores compartilhados devem ser usados ​​em um contexto histórico e cronológico, variando de 2016 a março de 2021.

Operação Colheita:

PlugX C2:

sery (.) brushupdata (.) com

Dnssery (.) Brushupdata (.) Com

Center (.) Asmlbigip (.) Com

Ferramentas:

Mimikatz

PsExec

RottenPotato

BadPotato

Operação 2019/2020

Malware PlugX:

f50de0fae860a5fd780d953a8af07450661458646293bfd0fed81a1ff9eb4498

26e448fe1105b5dadae9b7607e3cca366c6ba8eccf5b6efe67b87c312651db01

e9033a5db456af922a82e1d44afc3e8e4a5732efde3e9461c1d8f7629aa55caf

3124fcb79da0bdf9d0d1995e37b06f7929d83c1c4b60e38c104743be71170efe

Winnti:

800238bc27ca94279c7562f1f70241ef3a37937c15d051894472e97852ebe9f4

c3c8f6befa32edd09de3018a7be7f0b7144702cb7c626f9d8d8d9a77e201d104

df951bf75770b0f597f0296a644d96fbe9a3a8c556f4d2a2479a7bad39e7ad5f

Winnti C2: 185.161.211.97

Ferramentas:

PSW64 6e983477f72c8575f8f3ff5731b74e20877b3971fa2d47683aff11cfd71b48c6

NTDSDumpEx 6db8336794a351888636cb26ebefb52aeaa4b7f90dbb3e6440c2a28e4f13ef96

NBTSCAN c9d5dc956841e000bfd8762e2f0b48b66c79b79500e894b4efa7fb9ba17e4e9e

NetSess ddeeedc8ab9ab3b90c2e36340d4674fda3b458c0afd7514735b2857f26b14c6d

Smbexec e781ce2d795c5dd6b0a5b849a414f5bd05bb99785f2ebf36edb70399205817ee

Wmiexec 14f0c4ce32821a7d25ea5e016ea26067d6615e3336c3baa854ea37a290a462a8

Mimikatz

Linha de comando RAR

TCPdump

 

Fonte: McAfee