Skip to content
KitploitKITPLOIT
FerramentasBlog
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
ModuleShifting — Variante mais furtiva das técnicas de injeção Module Stomping e Module Overloading que reduz os IoCs de memória. Implementado em Python ctypes. | Kitploit
Ferramentas/GitHubGitHub/naksyn/moduleshifting
Forensia de MemóriaRed TeamingDesenvolvimento de PayloadsExploração de Binários
GitHubnaksyn/moduleshifting

ModuleShifting

Variante mais furtiva das técnicas de injeção Module Stomping e Module Overloading que reduz os IoCs de memória. Implementado em Python ctypes.

Ver Repositório
13514há 2 anosRevisado pelo Kitploit

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

Supported Python versions Twitter

ModuleShifting

Esta ferramenta foi apresentada na palestra x33fcon 2023: "Melhorando a furtividade das Técnicas de Injeção de Memória" [Vídeo] [Post no Blog]

O que é

ModuleShifting é uma variação mais furtiva da técnica de injeção Module Stomping e Module Overloading. Atualmente é implementado em Python ctypes para que possa ser executado totalmente em memória via um interpretador Python e Pyramid, evitando assim o uso de loaders compilados.

A técnica pode ser usada com payloads PE ou shellcode, no entanto, a variação mais furtiva deve ser usada com payloads shellcode que precisam ser funcionalmente independentes do payload final que o shellcode está carregando.

ModuleShifting, quando usado com payload shellcode, realiza as seguintes operações:

  1. A dll hospedeira legítima é carregada via LoadLibrary
  2. Altera as permissões de memória de uma seção específica para RW
  3. Sobrescreve o shellcode sobre a seção alvo
  4. Adiciona padding opcional para melhor se misturar em comportamentos de falso positivo (mais informações aqui)
  5. Altera as permissões para RX
  6. Executa o shellcode via ponteiro de função - métodos de execução adicionais: callback de função ou API CreateThread
  7. Escreve o conteúdo original da dll sobre o shellcode executado - este passo evita deixar um artefato de memória malicioso no espaço de memória da imagem da dll hospedeira. O shellcode precisa ser funcionalmente independente de estágios posteriores, caso contrário a execução será interrompida.

immagine

Ao usar um payload PE, o ModuleShifting realizará a seguinte operação:

  1. A dll hospedeira legítima é carregada via LoadLibrary
  2. Altera as permissões de memória de uma seção específica para RW
  3. Copia o PE sobre o ponto alvo especificado, seção por seção
  4. Adiciona padding opcional para melhor se misturar em comportamentos de falso positivo
  5. Realiza a relocação de base
  6. Resolve as importações
  7. Finaliza a seção definindo as permissões para seus valores nativos (evita a criação de uma região de memória RWX)
  8. Execução de callbacks TLS
  9. Executa o ponto de entrada do PE

Por que é útil

ModuleShifting pode ser usado para injetar um payload sem alocar memória dinamicamente (isto é, VirtualAlloc) e, comparado ao Module Stomping e Module Overloading, é mais furtivo porque diminui a quantidade de IoCs gerados pela própria técnica de injeção.

Existem 3 diferenças principais entre Module Shifting e algumas implementações públicas de Module Stomping (uma de Bobby Cooke e WithSecure)

  1. Padding: ao escrever shellcode ou PE, você pode usar padding para melhor se misturar em comportamentos comuns de Falso Positivo (como aplicativos de terceiros ou dlls .net escrevendo x quantidade de bytes sobre sua seção .text).
  2. Execução de shellcode usando ponteiro de função. Isso ajuda a evitar a criação de uma nova thread ou chamar callbacks de função incomuns.
  3. Restauração do conteúdo original da dll sobre o shellcode executado. Esta é uma diferença chave.

As diferenças entre Module Shifting e Module Overloading são as seguintes:

  1. O PE pode ser escrito a partir de uma seção especificada em vez de começar do PE da dll hospedeira. Uma vez que a seção alvo é escolhida cuidadosamente, isso pode reduzir a quantidade de IoCs gerados (ou seja, o cabeçalho PE da dll hospedeira não é sobrescrito ou menos bytes são sobrescritos na seção .text, etc.)
  2. Padding que pode ser adicionado ao próprio payload PE para melhor se misturar em falsos positivos.

Usando um payload shellcode funcionalmente independente, como um payload AceLdr Beacon Stageless shellcode, o ModuleShifting consegue injetar localmente sem alocar memória dinamicamente e, no momento, gerando zero IoC em uma varredura do Moneta e PE-Sieve. Estou ciente de que os payloads dormentes do AceLdr podem ser capturados com outras ferramentas excelentes, como Hunt-Sleeping-Beacon, mas o foco aqui está na técnica de injeção em si, não no payload. No nosso caso, o que permite mais furtividade na injeção é a independência funcional do shellcode, para que os bytes maliciosos escritos possam ser restaurados ao seu conteúdo original, efetivamente apagando os vestígios da injeção.

Aviso Legal

Todas as informações e conteúdo são fornecidos apenas para fins educacionais. Siga as instruções por sua conta e risco. Nem o autor nem seu empregador são responsáveis por qualquer dano ou perda direta ou consequente decorrente de qualquer pessoa ou organização.

Créditos

Este trabalho foi possível graças ao conhecimento e ferramentas compartilhadas por pessoas incríveis como Aleksandra Doniec @hasherezade, Forest Orr e Kyle Avery. Usei intensamente Moneta, PeSieve, PE-Bear e AceLdr durante todo o meu processo de aprendizado e eles foram fundamentais para minha compreensão deste tópico.

Uso

ModuleShifting pode ser usado com Pyramid e um interpretador Python para executar a injeção de processo local totalmente em memória, evitando loaders compilados.

  1. Clone o repositório Pyramid:

git clone https://github.com/naksyn/Pyramid

  1. Gere um payload shellcode com seu C2 preferido e coloque-o na pasta Delivery_files do Pyramid. Consulte a seção Ressalvas para requisitos de payload.
  2. Modifique os parâmetros do script moduleshifting.py dentro da pasta Modules do Pyramid.
  3. Inicie o servidor Pyramid: python3 pyramid.py -u testuser -pass testpass -p 443 -enc chacha20 -passenc superpass -generate -server 192.168.1.2 -setcradle moduleshifting.py
  4. Execute o código cradle gerado em um interpretador Python.

Demonstração

https://github.com/naksyn/ModuleShifting/assets/59816245/67fcf888-3385-47da-b828-8a2dafeeb1e2

Ressalvas

Para executar esta técnica com sucesso, você deve usar um payload shellcode que seja capaz de carregar um payload adicional autossustentável em outra área da memória. O ModuleShifting foi testado com o payload AceLdr, que é capaz de carregar uma cópia completa do Beacon no heap, quebrando assim a dependência funcional com o shellcode inicial. Esta técnica funcionaria com qualquer payload shellcode que tenha capacidades semelhantes. Portanto, o shellcode inicial se torna inútil após a execução e não há razão para mantê-lo na memória como um IoC.

Uma dll hospedeira com espaço suficiente para o shellcode na seção alvo também deve ser escolhida, caso contrário a técnica falhará.

Oportunidades de detecção

Module Stomping e Module Shifting precisam escrever shellcode no espaço de memória de uma dll legítima. O ModuleShifting eliminará este IoC após a fase de limpeza, mas indicadores podem ser detectados por scanners com capacidades de inspeção em tempo real.

immagine

Baixar ferramenta