
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.
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]
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:

Ao usar um payload PE, o ModuleShifting realizará a seguinte operação:
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)
As diferenças entre Module Shifting e Module Overloading são as seguintes:
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.
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.
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.
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.
git clone https://github.com/naksyn/Pyramid
python3 pyramid.py -u testuser -pass testpass -p 443 -enc chacha20 -passenc superpass -generate -server 192.168.1.2 -setcradle moduleshifting.pyhttps://github.com/naksyn/ModuleShifting/assets/59816245/67fcf888-3385-47da-b828-8a2dafeeb1e2
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á.
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.
