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
InlineExecute-Assembly — Cobalt Strike BOF per esecuzione di assembly .NET in-process con bypass AMSI/ETW, AppDomain personalizzato e reindirizzamento dell'output tramite named pipe/mailslot. | Kitploit
Strumenti/GitHubGitHub/anthemtotheego/inlineexecute-assembly
Post-ExploitRed Teaming
GitHubanthemtotheego/inlineexecute-assembly

InlineExecute-Assembly

Cobalt Strike BOF per esecuzione di assembly .NET in-process con bypass AMSI/ETW, AppDomain personalizzato e reindirizzamento dell'output tramite named pipe/mailslot.

Vedi Repository
76614015 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

InlineExecute-Assembly

InlineExecute-Assembly è un Beacon Object File (BOF) proof-of-concept che consente ai professionisti della sicurezza di eseguire assembly .NET in-process, in alternativa al tradizionale modulo execute-assembly di Cobalt Strike basato su fork-and-run. InlineExecute-Assembly esegue qualsiasi assembly che abbia come punto di ingresso Main(string[] args) o Main(). Questo dovrebbe permetterti di eseguire la maggior parte degli strumenti rilasciati senza alcuna modifica preventiva.

Il BOF determina automaticamente quale Common Language Runtime (CLR) deve essere caricato nel processo per il tuo assembly (v2.0.50727 o v4.0.30319) prima dell'esecuzione e, nella maggior parte dei casi, dovrebbe terminare in modo pulito se si verificano problemi. Il BOF supporta anche diverse flag che consentono all'operatore di dettare vari comportamenti prima dell'esecuzione di .NET, tra cui la disabilitazione di AMSI tramite patch in memoria, la disabilitazione e il ripristino di ETW tramite patch in memoria, la personalizzazione del nome del dominio dell'AppDomain CLR da creare, la possibilità di creare e reindirizzare l'output della console dell'assembly a un named pipe o a un mailslot, e permette all'operatore di passare dal punto di ingresso predefinito Main(string[] args) a Main(). Maggiori dettagli sull'uso, i casi d'uso e le possibili rilevazioni sono disponibili qui sotto e su https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/.

Infine, il vantaggio di eseguire i nostri assembly .NET nello stesso processo del nostro beacon implant è che evitiamo il comportamento predefinito del modulo execute-assembly di Cobalt Strike, che crea un nuovo processo per caricare/iniettare CLR/assembly .NET. Tuttavia, esistono ancora altre considerazioni opsec, ad esempio: il processo in cui stiamo esecutando carica normalmente il CLR? L'assembly .NET che stiamo eseguendo ha firme note? Di conseguenza, lo svantaggio è che se qualcosa viene rilevato e ucciso, ad esempio da AMSI, anche il tuo beacon viene ucciso.

Riferimenti

Questo strumento non esisterebbe senza la possibilità di sfruttare alcune ottime ricerche, strumenti e codici già pubblicati da membri della comunità della sicurezza. Quindi grazie a tutti. Infine, se pensi che qualcuno sia stato omesso di seguito, fammelo sapere e provvederò ad aggiungerlo.

  • HostingCLR - qui - Logica di esecuzione CLR/assembly
  • Dotnet-Loader-Shellcode - (di @modexpblog) - qui - Ottima ricerca su tutto, incluse le interfacce COM per eseguire .NET in C -> vero MVP
  • Donut - (di @TheRealWover e @modexpblog) - qui - Header delle interfacce COM
  • Memory Patching AMSI Bypass - (di @_RastaMouse) - qui - Ricerca sul patching in memoria di AMSI
  • Metasploit-Execute-Assembly - (di @b4rtik) - qui - Patching AMSI modificato e funzione per trovare la versione di .NET
  • ExecuteAssembly - (di @med0x2e) - qui - Script aggressor modificato
  • Hiding Your .NET ETW - (di @xpn) - qui - Ottima ricerca su ETW
  • ETW BOF - (di @ajpc500) - qui - Patching ETW modificato
  • ExecuteAssembly_Mailslot - (di @N4k3dTurtl3) - qui - Uso modificato dei mailslot per il reindirizzamento della console
  • @freefirex2 - È stato così gentile da condividere alcuni buoni dettagli sul funzionamento interno dei BOF e le insidie.

Per Iniziare

  1. Copia la cartella inlineExecute-Assembly con tutto il suo contenuto su un sistema a cui prevedi di connetterti tramite l'applicazione GUI di Cobalt Strike.
  2. Carica lo script aggressor inlineExecute-Assembly.cna
  3. Esegui inlineExecute-Assembly --dotnetassembly /path/to/assembly.exe per l'esecuzione più semplice (vedi i casi d'uso sotto per esempi specifici con le flag)

Compila il Tuo

Esegui il comando qui sotto all'interno della directory src tramite il Prompt dei comandi degli strumenti nativi x64 per VS 2019

root@kitploit:~
cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx64.o

Esegui il comando qui sotto all'interno della directory src tramite il Prompt dei comandi degli strumenti nativi x86 per VS 2019

root@kitploit:~
cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx86.o

Flags

root@kitploit:~
--dotnetassembly        Directory path to your assembly **required**
--assemblyargs          Assembly arguments to pass
--appdomain             Change default name of AppDomain sent (default value is totesLegit and is set via the included aggressor script) *Domain always unloaded*
--amsi                  Attempts to disable AMSI via in memory patching (If successful AMSI will be disabled for the entire life of process)
--etw                   Attempts to disable ETW via in memory patching (If successful ETW will be disabled for the entire life of process unless reverted)
--revertetw             Attempts to disable ETW via in memory patching and then repatches it back to original state
--pipe                  Change default name of named pipe (default value is totesLegit and is set via the included aggressor script)
--mailslot              Switches to using mailslots to redirect console output. Changes default name of mailslot (If left blank, default value is totesLegit and is set via the included aggressor script)
--main                  Changes entry point to Main() (default value is Main(string[] args))

Caso d'Uso

Esegui assembly .NET

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe

Caso d'Uso

Esegui assembly .NET con argomenti

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker

Caso d'Uso

Esegui assembly .NET con argomenti e disabilita AMSI

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi

Caso d'Uso

Esegui assembly .NET con argomenti e disabilita ETW

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw

Caso d'Uso

Esegui assembly .NET con argomenti e reindirizza l'output tramite mailslot invece del named pipe predefinito

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot

Caso d'Uso

Esegui assembly .NET con argomenti e cambia il nome del named pipe predefinito impostato nello script aggressor

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit

Caso d'Uso

Esegui assembly .NET e cambia il dominio dell'app predefinito impostato nello script aggressor

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit

Caso d'Uso

Esegui assembly .NET con punto di ingresso Main() invece del predefinito Main(string[] args)

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/simpleMain.exe --main

Caso d'Uso

Vai all-in

Sintassi

root@kitploit:~
beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi --etw --appdomain forRealLegit --mailslot forRealLegit

Avvertenze

  1. Anche se ho cercato di rendere questo strumento il più stabile possibile, non ci sono garanzie che non si verifichino crash e che i beacon non muoiano. Non abbiamo il lusso aggiuntivo del fork-and-run, dove se qualcosa va storto il beacon vive. Questo è il compromesso con i BOF. Detto questo, non posso sottolineare abbastanza quanto sia importante testare i propri assembly in anticipo per assicurarsi che funzionino correttamente con lo strumento.
  2. Poiché il BOF viene eseguito in-process e prende il controllo del beacon durante l'esecuzione, questo va tenuto in considerazione prima di usarlo per assembly che richiedono molto tempo. Se scegli di eseguire qualcosa che impiegherà molto tempo per restituire risultati, il tuo beacon non sarà attivo per eseguire altri comandi finché i risultati non arrivano e l'assembly termina. Inoltre, questo non rispetta l'impostazione sleep. Ad esempio, se il tuo sleep è impostato a 10 minuti ed esegui il BOF, riceverai i risultati non appena il BOF termina.
  3. A meno che non vengano apportate modifiche a strumenti che caricano PE in memoria (ad esempio SafetyKatz), questi molto probabilmente uccideranno il tuo beacon. Molti di questi strumenti funzionano bene con execute-assembly perché sono in grado di inviare l'output della console dal processo sacrificial prima di uscire. Quando escono tramite il nostro BOF in-process, uccidono il nostro processo, che uccide il nostro beacon. Questi possono essere modificati per funzionare, ma consiglierei di eseguire questo tipo di assembly tramite execute-assembly poiché potrebbero essere caricate nel processo altre cose non OPSEC-friendly che non vengono rimosse.
  4. Se il tuo assembly usa Environment.Exit, questo dovrà essere rimosso perché ucciderà il processo e il beacon.
  5. Named pipe e mailslot devono essere unici. Se non ricevi dati indietro e il tuo beacon è ancora vivo, molto probabilmente il problema è che devi selezionare un nome diverso per il named pipe o il mailslot.

Rilevazione

Alcune strategie di rilevazione e mitigazione che potrebbero essere utilizzate:

  1. Usa PAGE_EXECUTE_READWRITE quando esegue il patching in memoria di AMSI ed ETW. Questo è stato fatto intenzionalmente e dovrebbe essere un campanello d'allarme, poiché pochissimi programmi hanno intervalli di memoria con protezione PAGE_EXECUTE_READWRITE.
  2. Il nome predefinito del named pipe creato è totesLegit. Questo è stato fatto intenzionalmente e si potrebbero usare rilevazioni basate su firme per segnalarlo.
  3. Il nome predefinito del mailslot creato è totesLegit. Questo è stato fatto intenzionalmente e si potrebbero usare rilevazioni basate su firme per segnalarlo.
  4. Il nome predefinito dell'AppDomain caricato è totesLegit. Questo è stato fatto intenzionalmente e si potrebbero usare rilevazioni basate su firme per segnalarlo.
  5. Buoni consigli per rilevare l'uso malevolo di .NET (di @bohops) qui, (di F-Secure) qui, e qui
  6. Cercare il caricamento di .NET CLR in processi sospetti, come processi non gestiti che non dovrebbero mai avere il CLR caricato.
  7. Tracciamento degli eventi qui
  8. Cercare altri IOC noti di Cobalt Strike Beacon o IOC di C2 in uscita/comunicazione.
Scarica lo strumento