Hytale Supply Chain Attack

![[hytale-diagram-banner-3x.png| Hytale Malware Attack - Execution Chain]]

Introdução

Em março de 2026, uma campanha direcionada à comunidade gamer de Hytale foi identificada por meio de análise de tráfego de rede. Os threat actors implantaram um domínio typosquatted que replicava o site oficial pixel por pixel, distribuindo um installer trojanizado disfarçado de Hytale Launcher Setup para explorar uma base de jogadores que aguardava ansiosamente o lançamento do título há anos.

O que inicialmente parecia uma operação padrão de phishing revelou, após investigação mais profunda, uma cadeia de infecção em múltiplos estágios com sofisticação incomum. A campanha encadeia dois installers, trojaniza uma biblioteca Lua carregada via PE Import Table patching direto, executa PIC shellcode a partir da seção .text sem novas alocações de memória, oculta um payload Java via steganography dentro de um arquivo de imagem do jogo e o injeta diretamente na JVM por JNI, tudo dentro de um processo confiável, sem deixar artefatos em disco.

Este relatório documenta a cadeia completa de execução, as técnicas de evasão empregadas e os indicators of compromise identificados durante a investigação.

Nota: Este relatório foi originalmente escrito para uma publicação externa que nunca respondeu. O estilo formal de escrita reflete essa intenção original.

Principais pontos

• Ataque de supply chain via typosquatting direcionado a uma comunidade gamer específica
• Arquitetura de installer duplo (NSIS + Inno Setup) replicando o fluxo legítimo de instalação
• PE Import Table patching em HytaleClient.exe para forçar o carregamento de uma biblioteca Lua trojanizada
• PIC shellcode embutido na seção .text sem alocação adicional de memória
• Steganography aplicada em uma imagem oficial do jogo para ocultar uma classe Java fortemente ofuscada
• Injeção JNI direta na JVM do processo java-original.exe
• Descoberta inicial por comportamento anômalo de rede: java-original.exe mantendo conexão TCP em estado ESTABLISHED na porta 1336

Descoberta

A investigação começou a partir de uma anomalia de tráfego de rede observada após a instalação do binário. O processo java-original.exe mantinha uma conexão TCP em estado ESTABLISHED em uma porta inesperada, comportamento que motivou uma inspeção mais profunda de toda a cadeia de instalação.

A campanha emprega um domínio fraudulento registrado via typosquatting que replica a identidade visual da infraestrutura oficial para induzir vítimas a baixar um binário malicioso chamado Hytale Launcher Setup. Esse domínio é o primeiro ponto de contato da vítima com a campanha.

![[Hytale-site.png| Typosquatted Hytale site]]

Para maximizar as taxas de infecção, os atacantes removeram barreiras de fricção presentes no site legítimo. Seções de pagamento e fluxos de login foram removidos em favor de uma promessa de download direto “100% free”, reduzindo o tempo de avaliação da vítima e mantendo o engano visual desde a primeira interação.

Vetor inicial de infecção

O vetor inicial de infecção consiste em um pacote de instalação que replica de forma muito próxima a interface e a identidade visual do installer legítimo do Hytale.

![[installer-comparison.png | Original vs malicious installer]]

O binário inicial, identificado pelo SHA256 9229e9cf6e19ec75c2bd8dd7faa373bf074e54d44880a1ba339e6e55f2b1ed77, foi construído com NSIS (Nullsoft Scriptable Install System), um framework legítimo e open-source de instalação comumente abusado por threat actors para empacotar malware.

A operação avança por uma estrutura de execução em múltiplos estágios, desenhada tanto para superar limitações de tamanho de arquivo quanto para fragmentar o contexto malicioso em componentes distintos, dificultando a análise isolada de cada etapa.

Stage 1 - Interface e configuração (NSIS). O binário inicial de 1.6 GB gerencia a interface gráfica e implanta os executáveis do launcher em %AppData%\Roaming. O NSIS é escolhido nesta etapa especificamente para replicar os assets originais (banners, ícones), reduzindo a suspeita do usuário. Porém, o NSIS é tecnicamente limitado a pacotes abaixo de ~2 GB.

Stage 2 - Deploy de assets (Inno Setup). Depois que o primeiro estágio termina, a execução passa para HytaleInstaller.exe (1.2 GB). Esse componente usa Inno Setup para implantar um arquivo Assets.zip de 3.3 GB, contornando a limitação de tamanho do NSIS.

![[inno-setup-stage2.png | Inno Setup second-stage installer]]

Ao final, o installer cria um atalho na área de trabalho e inicia automaticamente Hytale F2P Launcher.exe. Essa arquitetura de installer duplo é uma abordagem deliberada para manter a interface fraudulenta enquanto gerencia o deploy de grandes volumes de dados no sistema que será comprometido em seguida.

A fachada F2P do Hytale (SanHost)

O artefato malicioso usa o projeto open-source Hytale F2P-EVO como fachada técnica. Originalmente hospedado no GitHub (amiayweb/Hytale-F2P) com mais de 500 stars, o projeto recebeu um DMCA Takedown da Hypixel Studios em fevereiro de 2026, resultando na remoção do repositório principal e de todos os 60+ forks sob alegações de pirataria e violação de copyright.

![[dmca-takedown-notice.png | DMCA takedown notice]]

Para contornar a ação legal, o projeto foi migrado para uma infraestrutura privada na SanHost (sanhost.net), mantendo seus próprios repositórios em git.sanhost.net. O repositório ainda estava publicamente acessível no momento desta análise.

Ao embutir esse software funcional e legítimo, os atacantes adicionam uma camada de plausibilidade técnica ao artefato. Quando os usuários observam que o jogo e o launcher realmente funcionam, tendem a descartar alertas de segurança potenciais, permitindo que a cadeia de ataque opere em background sem impedimentos.

Import Directory modificada

Depois que o fluxo de instalação termina, um atalho para o Hytale Launcher é criado na área de trabalho. Ao executar, a primeira anomalia fica visível imediatamente: o botão “Play” já está disponível sem nenhum download adicional. Esse comportamento indica que os assets do jogo foram pré-implantados durante o setup, motivando inspeção direta do diretório \Client em busca de modificações não documentadas.

![[f2p-launcher-play-button.png | F2P Launcher with Play button available]]

Após clicar em Play, o jogo inicia e roda normalmente, reforçando a percepção de instalação legítima.

![[hytale-game-running.png | Hytale game running]]

A investigação do diretório \Client revelou o executável HytaleClient.exe. Embora o binário exiba assinatura digital emitida por Hypixel Studios Canada Inc com SHA256 e countersignature de timestamp da SSL.com, o Windows marca a assinatura como inválida.

![[invalid-digital-signature.png | Invalid digital signature on HytaleClient.exe]]

Analysis Note: O projeto F2P-EVO original também invalida a assinatura como parte de suas modificações de bypass de autenticação. No entanto, a versão distribuída por esta campanha introduz artefatos adicionais ausentes no repositório oficial da SanHost, confirmando que as modificações vão além do escopo do fork legítimo.

Diferente da estrutura encontrada tanto no launcher legítimo quanto no fork original da SanHost, duas bibliotecas dinâmicas suspeitas foram identificadas no diretório raiz do client, especificamente sqlite3.dll e luah54.dll.

A presença delas é notável por causa do sistema nativo de proteção do Hytale. O jogo implementa verificação de integridade que, ao detectar discrepâncias em bibliotecas dinâmicas ou tentativas de DLL Proxying, encerra a execução com o erro “Identity token signature verification failed”.

![[integrity-verification-error.png | Integrity verification error]]

Para burlar essa barreira, os atacantes foram além de DLL Search Order Hijacking. Eles aplicaram PE Import Table patching diretamente em HytaleClient.exe, modificando fisicamente a estrutura do binário para declarar luah54.dll como dependência legítima conhecida pelo PE loader do Windows.

![[import-table-comparison.png | Import Directory Table comparison]]

O mecanismo explorado aqui é o modelo de confiança do PE loader. Ao verificar a integridade de dependências, o sistema de proteção do Hytale consulta as entradas declaradas na Import Directory Table do executável. Como luah54.dll foi inserida diretamente nessa estrutura, ela é tratada como uma dependência legítima declarada pelo próprio binário, carregada pelo PE loader antes que qualquer checagem de integridade em nível de aplicação seja executada. O código malicioso entra no processo no mesmo nível de confiança de qualquer dependência oficial.

Com o vetor de entrada estabelecido, a análise passa para o conteúdo da biblioteca injetada.

Biblioteca trojanizada - Orquestração de código nativo

A análise de luah54.dll revelou uma abordagem sofisticada de ofuscação comportamental. O binário expõe 156 exports e 116 imports, contagens consistentes com um build completo da biblioteca oficial Lua compilada a partir do código-fonte da lua.org.

Diferente de DLLs maliciosas típicas que apenas imitam o nome de uma biblioteca legítima, esta versão preserva todas as funções, símbolos e estruturas de uma biblioteca Lua real, tornando a detecção por análise estática de imports praticamente impossível.

A detecção no VirusTotal no momento da análise reforça essa avaliação: luah54.dll foi sinalizada por 0/72 engines.

![[luah54-virustotal.png | VirusTotal detection for luah54.dll (0/72)]]

Evidências do próximo estágio da cadeia foram encontradas por string search dentro da própria luah54.dll.

![[luah54-string-references.png | String references in luah54.dll]]

A busca por sqlite3 revela duas entradas relevantes, a referência direta sqlite3.dll e o path completo hardcoded para o payload. Esse path é o elo que conecta os dois estágios da cadeia, o endereço exato de onde luah54.dll vai carregar o próximo componente malicioso para o processo-alvo.

Dentro de DllMain, ao processar o evento DLL_PROCESS_ATTACH, a função dllmain_dispatch redireciona a execução para sub_180014200. Essa função inicia a rotina stager em uma thread separada via _beginthread.

![[dllmain-to-beginthread.png | DllMain to _beginthread execution flow]]

Quando executada, a thread invoca a subrotina maliciosa sub_180014230.

![[stager-path-resolution.png | sub_180014230 path resolution]]

Essa função obtém o path de %APPDATA%, constrói o path completo para sqlite3.dll usando o path hardcoded identificado antes e copia a string java-original.exe como nome do processo-alvo. A resolução de LoadLibraryA é feita dinamicamente via GetProcAddress em KERNEL32.DLL, evitando que o nome da função apareça na Import Address Table estática da DLL.

Dentro de sub_180014230, um loop while(true) monitora continuamente o sistema em busca do processo java-original.exe.

![[dll-injection-loop.png | Process monitoring and DLL injection loop]]

Quando o processo-alvo é localizado, o artefato executa DLL injection. O código aloca memória no address space de java-original.exe, escreve o path do payload e usa CreateRemoteThread para invocar LoadLibraryA, resultando no carregamento de sqlite3.dll no address space de java-original.exe.

PIC shellcode na seção .text

Uma análise mais profunda de sqlite3.dll revelou um fluxo crítico de execução quase idêntico dentro de seu DllMain. O diagrama abaixo ilustra a call chain que leva à execução final do stager.

![[dllmain-to-createthread.png | DllMain to CreateThread call chain]]

O fluxo converge em sub_180106840, que usa CreateThread para criar uma nova thread de execução. O detalhe técnico crítico está em seu entry point, sub_180001000, que corresponde exatamente ao endereço inicial da seção .text do binário (0x180001000).

![[pic-shellcode-text-section.png | PIC shellcode at .text section start]]

Essa abordagem é estratégica. Ao apontar a thread diretamente para código já presente na seção .text, o artefato executa Position-Independent Code (PIC) shellcode sem necessidade de novas alocações de memória, sem usar APIs como VirtualAllocEx e eliminando a criação de regiões de memória PRIVATE/RWX sem backing, que são o principal alvo de memory scanners modernos e soluções EDR.

Essa distinção é significativa quando comparada ao Reflective DLL Injection (RDI) de Stephen Fewer, amplamente adotado há mais de uma década. O RDI necessariamente cria uma nova região de memória PRIVATE/MAPPED com permissões excessivas, característica monitorada ativamente por praticamente todos os EDRs modernos. O método usado aqui executa shellcode dentro do address space já mapeado e com backing em sqlite3.dll no disco, tornando a região indistinguível de código legítimo para scanners baseados em atributos de memória.

A detecção no VirusTotal também reflete esse perfil de evasão: sqlite3.dll foi sinalizada por 1/72 engines, com um único veredito genérico da Cynet.

![[sqlite3-virustotal.png | VirusTotal detection for sqlite3.dll (1/72)]]

Injeção JNI e steganography

Dando continuidade à análise do PIC shellcode, foi confirmado que o artefato não usa Import Address Table estática. Toda a resolução de APIs críticas é feita dinamicamente em runtime, comportamento esperado para Position-Independent Code.

![[dynamic-api-resolution.png | Dynamic API resolution engine]]

A rotina sub_180001024 funciona como engine de resolução de símbolos, mapeando funções críticas de kernel32.dll e de bibliotecas Java. Entre as APIs resolvidas, destacam-se: VirtualAlloc e VirtualFree para manipulação de memória, LoadLibraryA, GetProcAddress e FreeLibrary para carregamento de módulos, além de GetEnvironmentVariableW e JNI_GetCreatedJavaVMs para interação com Java.

A presença de JNI_GetCreatedJavaVMs confirma o objetivo final do artefato, que é localizar e infiltrar instâncias ativas da Java Virtual Machine dentro do processo hospedeiro. Nessa mesma rotina, o shellcode também referencia o path completo hardcoded do arquivo de imagem usado para steganography:

sanasol\f2p-evo\data\games\15faf9c0-7369-49c9-bc52-7dffb78de983\Client\Data\Game\Interface\MainMenu\5e7a961d5e334000189a2a78_6.png

Mais adiante no shellcode, um dos aspectos mais sofisticados desta amostra foi identificado. A rotina sub_1800025db usa steganography para ocultar o estágio final, carregando gdiplus.dll para processar o arquivo de imagem referenciado.

![[gdiplus-steganography.png | GDI+ resolution for steganography]]

A rotina resolve e usa as seguintes funções GDI+: GdiplusStartup, GdiplusShutdown, GdipCreateBitmapFromFile, GdipGetImageWidth, GdipGetImageHeight e GdipBitmapGetPixel.

O arquivo processado não é um container genérico criado pelos atacantes. Ele é 5e7a961d5e334000189a2a78_6.png, artwork oficial de Hytale usado na interface do menu principal do jogo.

![[steganography-carrier.png | Steganography carrier image]]

Essa técnica de usar imagem como container impede que o payload seja detectado por assinaturas baseadas em disco, já que os dados maliciosos ficam codificados na estrutura de cores dos pixels de um PNG, indistinguíveis de conteúdo visual legítimo.

O monitoramento do fluxo de carregamento de DLL no processo java-original.exe via Process Monitor confirmou a sequência esperada de carregamento.

![[procmon-dll-loading.png | DLL loading sequence in Process Monitor]]

O processo java-original.exe carrega primeiro sqlite3.dll, seguido imediatamente por GdiPlus.dll. Ao examinar a call stack do evento de carregamento:

![[loadlibrary-call-stack.png | LoadLibraryA call stack]]

A call stack confirma que sqlite3.dll invocou LoadLibraryA para carregar GdiPlus.dll, exatamente como previsto pela análise estática do shellcode.

Extração de memória via interceptação do ciclo de vida do GDI+

Para extrair o payload via steganography, foi implementada uma estratégia de interceptação dinâmica baseada no ciclo de vida do objeto GDI+. Ao monitorar chamadas de gdiplus.dll, foi determinado que o momento de maior integridade dos dados ocorre imediatamente antes da liberação dos recursos gráficos por GdipDisposeImage.

O primeiro passo foi confirmar o carregamento das bibliotecas necessárias no processo, validando o contexto de execução.

![[windbg-loaded-libraries.png | WinDbg loaded libraries]]

Em seguida, foi definido um breakpoint na função responsável por liberar a imagem.

![[gdip-dispose-breakpoint.png | GdipDisposeImage breakpoint]]

A call stack no breakpoint confirmou que a execução estava no fluxo esperado, com GdipDisposeImage sendo chamada a partir de sqlite3+0x309d.

![[gdip-dispose-call-stack.png | GdipDisposeImage call stack]]

Com o breakpoint acionado, a inspeção de registradores revelou que RDX apontava para 0x0000019f7e5f0000, endereço de memória onde o payload já estava completamente montado.

![[payload-register-state.png | Register state with payload address]]

O dump resultante confirmou 340 KB de Java bytecode em uma região de memória RW (read-write).

![[java-bytecode-dump.png | Assembled Java bytecode dump]]

Ao posicionar o breakpoint em GdipDisposeImage imediatamente após a conclusão do loop de processamento de pixels, foi possível aguardar a finalização da rotina de extração e realizar o memory dump no momento exato em que o Java bytecode estava totalmente montado.

Essa manobra foi essencial para neutralizar a rotina de autodestruição identificada no código do malware, que executa um secure wipe dos bytes em memória logo após o uso, projetada para impedir recuperação de artefatos.

Vida útil do payload e implicações forenses

O que torna essa operação efetiva contra análise forense é a curta vida útil do payload em memória de dados bruta. Assim que o bytecode é entregue à JVM, o contexto de execução transita por três estágios.

Abstração da JVM. Quando a classe é registrada para execução, a JVM mapeia o bytecode bruto para estruturas internas de runtime. Nesse ponto, o buffer original de extração deixa de ser necessário para o fluxo normal de controle.

Execução adaptativa (Interpreter e JIT). A JVM pode executar a classe por interpretação e compilar progressivamente hot paths para código nativo. Isso desacopla ainda mais o comportamento em runtime da sequência original de bytes extraída.

Evasão pós-execução. Em paralelo, o loader executa secure wipe do buffer de extração e de artefatos sensíveis de path/string.

Como resultado, o malware permanece ativo dentro da JVM enquanto a visibilidade do analista sobre o artefato original de bytecode é significativamente reduzida. A classe não fica literalmente invisível, mas a janela de recuperação se torna muito estreita e altamente dependente de timing, com o payload pristine ainda preservado apenas dentro da imagem carrier de steganography nos assets do jogo.

Sem o dump feito no intervalo preciso entre a montagem do buffer e a integração na JVM, a recuperação do artefato teria sido quase impossível.

Análise da classe Java extraída

Após a extração bem-sucedida do arquivo .class da memória, a análise estática via decompilation revelou um cenário de ofuscação agressiva. O artefato emprega técnicas avançadas para impedir legibilidade do código e derrotar análise de control flow.

![[skidfuscator-obfuscated-class.png | Skidfuscator-obfuscated Java class]]

A presença de uma constante nothing_to_see_here contendo ASCII art (uma representação de “Rick Astley”) dentro do bloco estático é uma assinatura característica do Skidfuscator, uma engine de ofuscação Java de alta complexidade que, até o momento desta escrita, não possui deobfuscator público.

Diferente de ofuscadores simples que apenas renomeiam variáveis, o Skidfuscator é projetado com foco em resiliência contra reverse engineering. Suas defesas incluem control flow não linear por blocos de lógica fragmentados com aritmética opaca, e identificadores homoglyph com caracteres visualmente ambíguos (I, l, 1) para dificultar análise manual.

![[skidfuscator-ascii-art.png | Skidfuscator ASCII art signature]]

A detecção dessa proteção confirma que o desenvolvedor do malware investiu em derrotar análises convencionais, exigindo técnicas de análise dinâmica ou emulação para compreender o comportamento real da classe.

Reconstrução do artefato

Extrair dados brutos da memória exige restaurar a integridade do arquivo .class para permitir monitoramento dinâmico. Esse processo apresenta dois obstáculos principais: ofuscação de bytecode e problemas de alinhamento de memória.

O primeiro obstáculo é a ofuscação de método duplicado. A execução padrão do arquivo dumpado falha com java.lang.ClassFormatError: Duplicate method name. Essa técnica viola deliberadamente as especificações da JVM ao inserir métodos com nomes e assinaturas idênticos, bloqueando verificação e decompilation convencional.

![[classformat-error-duplicate.png | ClassFormatError from duplicate methods]]

No entanto, launchers Java de jogos frequentemente são iniciados com flags -Xverify:none ou -noverify para contornar verificação de bytecode que entraria em conflito com modificações legítimas de mods e patches. Se a JVM do processo original foi iniciada com essa configuração, ela aceita o bytecode ofuscado sem restrições. Isso explica por que a classe executa corretamente no processo-alvo e torna o uso dessa flag indispensável para reproduzir a execução em ambiente controlado.

O segundo obstáculo é a presença de trailing bytes. Diferente de arquivos em disco, buffers de memória frequentemente contêm bytes nulos além do fim da estrutura real do arquivo. Como a JVM exige o tamanho binário exato para carregar uma classe, qualquer dado extra causa Extra bytes at the end of class file, mesmo com verificação desabilitada.

![[trailing-null-bytes-removal.png | Trailing null bytes removal]]

A solução envolve remoção manual dos trailing null bytes identificados por análise hexadecimal, restaurando o alinhamento correto do arquivo .class.

Após o ajuste de alinhamento e a supressão de verificação, o payload foi validado e executado com sucesso.

![[payload-execution-success.png | Successful payload execution]]

Análise em sandbox e comunicação C2

A execução controlada da classe Java maliciosa em ambiente de sandbox permitiu observar o comportamento completo do payload, confirmando e expandindo as hipóteses levantadas durante a análise estática.

A cadeia completa de instalação não foi executada diretamente dentro do ANY.RUN. Os pacotes originais de setup tinham vários gigabytes, os estágios posteriores dependiam de caminhos específicos em disco tanto para a DLL quanto para o payload em PNG, e o loader nativo esperava que o processo Java alvo tivesse o nome java-original.exe. O runtime Java disponibilizado pelo sandbox também era limitado ao Java 8, o que não era adequado para executar de forma confiável o estágio Java recuperado.

Para reproduzir o estágio final em condições controladas, a análise utilizou um harness de execução mínimo contendo um runtime OpenJDK compatível e a classe extraída no layout esperado: latest\bin\lIlIllIlIlI.class e latest\bin\java-original.exe. O ambiente de teste iniciou o payload com latest\bin\java-original.exe -noverify -cp latest\bin lIlIllIlIlI. Essa configuração foi utilizada estritamente para observar o comportamento em runtime do estágio Java e a comunicação C2. Ela não representa o fluxo original de entrega ou instalação.

O primeiro dado relevante é o score atribuído pela sandbox ANY.RUN ao processo java-original.exe, 10 de 100, sem veredito. Esse número não representa falha do ambiente de análise. Em um cenário controlado como este, mesmo uma execução com sinais potencialmente suspeitos pode não receber classificação maliciosa imediata.

![[anyrun-score.png | ANY.RUN score 10/100]]

Imediatamente após a inicialização, o processo registra três artefatos em disco, todos relacionados à infraestrutura de persistência e input hooking.

![[malicious-file-artifacts.png | Malicious file system artifacts]]

O arquivo jnh40 é extraído para C:\Users\admin\.plugins\libraries, um diretório oculto criado pelo próprio malware. O arquivo JNativeHook-2.1.0.x86_64.dll é depositado em %TEMP%. Ambos são componentes da biblioteca open-source JNativeHook, que fornece capacidades de global keyboard e mouse hooking em nível de sistema, independentemente do foco de janela.

![[jnativehook-globalscreen.png | GlobalScreen event listeners]]

A análise da biblioteca jnh40 confirma o package org.jnativehook com a classe GlobalScreen, que registra listeners globais de NativeKeyEvent e NativeMouseEvent. Essa é a implementação de keylogging e monitoramento de mouse da campanha, onde cada tecla e clique executado pelo usuário, em qualquer aplicação, é capturado pelo global hook registrado na JVM do jogo.

Com o hook estabelecido, o processo inicia comunicação com a infraestrutura de command and control. O primeiro pacote transmitido para o C2 é o clássico beacon de registro de RAT, seguindo um protocolo estruturado de identificação da vítima.

![[c2-registration-beacon.png | C2 registration beacon]]

O beacon transmite o username da máquina comprometida, sistema operacional, nome e PID do processo hospedeiro, além de configurações de idioma e região. Após o registro da vítima, o client envia a confirmação de carregamento do módulo de hooking.

![[c2-plugin-confirmation.png | Plugin load confirmation]]

A mensagem confirma que o plugin JNativeHook foi inicializado com sucesso. O hash de6cf300c801226d4b19e4fdc258975e corresponde ao MD5 do módulo jnh40 extraído para C:\Users\admin\.plugins\libraries, funcionando como verificação de integridade do componente carregado. A presença desse mecanismo de verificação indica uma infraestrutura C2 com controle ativo sobre módulos implantados nas vítimas.

A análise de tráfego de rede revela as duas conexões estabelecidas pelo processo.

![[c2-tcp-connections.png | C2 TCP connections]]

A primeira conexão, para 172.66.171.73:443, corresponde ao domínio pastebin.com via Cloudflare, provavelmente usada para recuperação de configuração ou stage de módulos adicionais. Como a conexão está criptografada em HTTPS, apenas o destino foi observável; a URL específica do Pastebin e seu conteúdo não puderam ser determinados a partir do tráfego capturado. A segunda conexão, para 212.64.210.140 na porta 1336, está alocada ao ASN SUNUCUN, um provedor de hospedagem turco.

Essa é a conexão C2 primária e constitui evidência de infraestrutura da campanha por meio de hospedagem na Turquia; isoladamente, esse dado não permite atribuição conclusiva a threat actors baseados na Turquia.

Conclusão

Esta campanha demonstra um exemplo raro de engenharia de evasão holística. Cada técnica empregada existe para eliminar uma camada específica de detecção, culminando em execução Java totalmente fileless dentro de um processo de jogo confiável, onde distinguir código malicioso de execução legítima se torna significativamente mais difícil para memory scanners, EDRs e tooling forense.

O PE Import Table patching neutraliza a verificação de integridade em nível de aplicação. A biblioteca Lua trojanizada fornece um contexto legítimo de execução para o stager. O PIC shellcode executando da seção .text evita os artefatos de alocação de memória que EDRs modernos monitoram. A steganography dentro de um asset oficial do jogo evita detecção por assinaturas em disco. A injeção JNI em uma JVM já em execução elimina artefatos de criação de processo. O wipe de bytecode pós-execução destrói a janela de evidência forense.

Nenhuma dessas técnicas é nova individualmente. A sofisticação aqui está na composição. Uma sequência cuidadosamente em camadas na qual cada técnica existe especificamente para cobrir a lacuna de detecção deixada pela anterior.

À medida que as defesas evoluem, campanhas como esta deixam claro que a detecção precisará acompanhar o ritmo, embora como fazer isso sem gerar falso positivo excessivo permaneça um problema em aberto.

Mapeamento MITRE ATT&CK

Indicadores de Comprometimento

Ferramentas utilizadas