Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
ModuleShifting — Variante più furtiva delle tecniche di injection Module Stomping e Module Overloading che riduce le IoCs di memoria. Implementato in Python ctypes | Kitploit
Strumenti/GitHubGitHub/naksyn/moduleshifting
Memory ForensicsRed TeamingSviluppo PayloadBinary Exploitation
GitHubnaksyn/moduleshifting

ModuleShifting

Variante più furtiva delle tecniche di injection Module Stomping e Module Overloading che riduce le IoCs di memoria. Implementato in Python ctypes

Vedi Repository
135142 anni faRevisionato da Kitploit

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Supported Python versions Twitter

ModuleShifting

Questo strumento è stato presentato al 2023 x33fcon talk: "Migliorare la furtività delle tecniche di iniezione della memoria" [Video] [Blogpost]

Cos'è

ModuleShifting è una variante più furtiva della tecnica di iniezione Module Stomping e Module Overloading. È implementata in Python ctypes in modo da poter essere eseguita interamente in memoria tramite un interprete Python e Pyramid, evitando così l'uso di loader compilati.

La tecnica può essere utilizzata con payload PE o shellcode, tuttavia la variante più furtiva è da usare con payload shellcode che devono essere funzionalmente indipendenti dal payload finale che lo shellcode sta caricando.

ModuleShifting, quando utilizzato con payload shellcode, esegue le seguenti operazioni:

  1. La DLL host legittima viene caricata tramite LoadLibrary
  2. Modifica i permessi di memoria di una sezione specifica a RW
  3. Sovrascrive lo shellcode sulla sezione di destinazione
  4. Aggiunge padding opzionale per mimetizzarsi meglio nel comportamento dei falsi positivi (maggiori informazioni qui)
  5. Modifica i permessi a RX
  6. Esegue lo shellcode tramite puntatore a funzione - metodi di esecuzione aggiuntivi: callback di funzione o API CreateThread
  7. Scrive il contenuto originale della DLL sullo shellcode eseguito - questo passaggio evita di lasciare un artefatto di memoria dannoso nello spazio di memoria immagine della DLL host. Lo shellcode deve essere funzionalmente indipendente dagli stadi successivi, altrimenti l'esecuzione si interrompe.

immagine

Quando si utilizza un payload PE, ModuleShifting esegue le seguenti operazioni:

  1. La DLL host legittima viene caricata tramite LoadLibrary
  2. Modifica i permessi di memoria di una sezione specifica a RW
  3. Copia il PE sul punto di destinazione specificato, sezione per sezione
  4. Aggiunge padding opzionale per mimetizzarsi meglio nel comportamento dei falsi positivi
  5. Esegue il base relocation
  6. Risolve gli import
  7. Finalizza la sezione impostando i permessi ai loro valori nativi (evita la creazione di una regione di memoria RWX)
  8. Esecuzione delle callback TLS
  9. Esecuzione dell'entrypoint PE

Perché è utile

ModuleShifting può essere utilizzato per iniettare un payload senza allocare memoria dinamicamente (es. VirtualAlloc) e rispetto a Module Stomping e Module Overloading è più furtivo perché riduce la quantità di IoC generati dalla tecnica di iniezione stessa.

Ci sono 3 differenze principali tra Module Shifting e alcune implementazioni pubbliche di Module Stomping (una di Bobby Cooke e WithSecure)

  1. Padding: quando si scrive shellcode o PE, è possibile utilizzare il padding per mimetizzarsi meglio nel comune comportamento dei falsi positivi (come applicazioni di terze parti o DLL .net che scrivono x byte sulla loro sezione .text).
  2. Esecuzione dello shellcode tramite puntatore a funzione. Questo aiuta a evitare la creazione di un nuovo thread o la chiamata a callback di funzioni inusuali.
  3. Ripristino del contenuto originale della DLL sullo shellcode eseguito. Questa è una differenza fondamentale.

Le differenze tra Module Shifting e Module Overloading sono le seguenti:

  1. Il PE può essere scritto a partire da una sezione specifica invece che dall'inizio del PE della DLL host. Una volta scelta attentamente la sezione di destinazione, questo può ridurre la quantità di IoC generati (es. l'header PE della DLL host non viene sovrascritto o vengono sovrascritti meno byte sulla sezione .text, ecc.)
  2. Padding che può essere aggiunto al payload PE stesso per mimetizzarsi meglio nei falsi positivi.

Utilizzando un payload shellcode funzionalmente indipendente come un payload shellcode AceLdr Beacon Stageless, ModuleShifting è in grado di iniettare localmente senza allocare memoria dinamicamente e al momento genera zero IoC in una scansione con Moneta e PE-Sieve. Sono consapevole che i payload dormienti di AceLdr possono essere rilevati con altri ottimi strumenti come Hunt-Sleeping-Beacon, ma l'attenzione qui è sulla tecnica di iniezione stessa, non sul payload. Nel nostro caso, ciò che consente una maggiore furtività nell'iniezione è l'indipendenza funzionale dello shellcode, in modo che i byte dannosi scritti possano essere ripristinati al loro contenuto originale, cancellando efficacemente le tracce dell'iniezione.

Disclaimer

Tutte le informazioni e i contenuti sono forniti solo a scopo educativo. Segui le istruzioni a tuo rischio. Né l'autore né il suo datore di lavoro sono responsabili per eventuali danni o perdite diretti o consequenziali derivanti da qualsiasi persona o organizzazione.

Crediti

Questo lavoro è stato reso possibile grazie alla conoscenza e agli strumenti condivisi da persone incredibili come Aleksandra Doniec @hasherezade, Forest Orr e Kyle Avery. Ho utilizzato pesantemente Moneta, PeSieve, PE-Bear e AceLdr durante tutto il mio processo di apprendimento e sono stati fondamentali per la mia comprensione di questo argomento.

Utilizzo

ModuleShifting può essere utilizzato con Pyramid e un interprete Python per eseguire l'iniezione nel processo locale completamente in memoria, evitando loader compilati.

  1. Clona il repository di Pyramid:

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

  1. Genera un payload shellcode con il tuo C2 preferito e inseriscilo nella cartella Delivery_files di Pyramid. Vedi la sezione Avvertenze per i requisiti del payload.
  2. Modifica i parametri dello script moduleshifting.py all'interno della cartella Modules di Pyramid.
  3. Avvia il server Pyramid: python3 pyramid.py -u testuser -pass testpass -p 443 -enc chacha20 -passenc superpass -generate -server 192.168.1.2 -setcradle moduleshifting.py
  4. Esegui il codice cradle generato su un interprete Python.

Demo

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

Avvertenze

Per eseguire con successo questa tecnica, dovresti utilizzare un payload shellcode in grado di caricare un payload aggiuntivo autosufficiente in un'altra area di memoria. ModuleShifting è stato testato con il payload AceLdr, che è in grado di caricare una copia completa di Beacon nell'heap, rompendo così la dipendenza funzionale dallo shellcode iniziale. Questa tecnica funzionerebbe con qualsiasi payload shellcode con capacità simili. Quindi lo shellcode iniziale diventa inutile una volta eseguito e non c'è motivo di tenerlo in memoria come IoC.

Bisogna anche scegliere una DLL host con spazio sufficiente per lo shellcode nella sezione di destinazione, altrimenti la tecnica fallirà.

Opportunità di rilevamento

Module Stomping e Module Shifting devono scrivere shellcode nello spazio di memoria di una DLL legittima. ModuleShifting eliminerà questo IoC dopo la fase di pulizia, ma gli indicatori potrebbero essere individuati da scanner con capacità di ispezione in tempo reale.

immagine

Scarica lo strumento